| RE: [eclipse.org-planning-council] Re: issues |
|
Well, someday we can all write a book
about the trials and tribulations of open source development. The fact of the
matter is that none of us have a contractual obligation to meet any specified
deadlines. Open source development is successful because of the good will of
the participants. It is our role as open source leaders to ensure that good
will flows and that we manage the risks when we hit bumps in the road. Being
nasty about missed deadlines goes against the grain of this culture, and in
fact hurts more than it helps as it has the potential to harming the community. I’m sure we’ve helped Bjorn enough
understand this. Dropping projects out of Callisto will kill the entire effort
and probably for a long time. Helping each other succeed will make us want to
come back to the table again next time. From: My last comments,
somebody else can have the last word, I need to get back to tracking my
Callisto deliverables… Re voluntary, we all
recognize Callisto (as well as our contribution to Eclipse) is voluntary.
We’re not looking to quit Callisto in the face of the challenges,
we’re looking to make Callisto work which means some flexibility since
we’re figuring this out as we go (I’m sure Callisto 2 will be a
smoother ride). Re Projects being dropped
from Callisto if they fall behind, we set that consequence in Aug’05
before we defined (1) the schedule and (2) any real requirements for
Callisto. As such, I’d have a hard time holding a strict line for
Projects that might miss some interim deliverable due to a late/ambiguous
requirement, but who have good intentions (and likelihood) of aligning
(we’re not dropping the Eclipse Platform because their M5a (we could
debate whether or not M5 sufficed, but let’s not, that would ruin my
argument and needlessly distract more attention) came out a week late are we?
Or any projects that were dependent on M5a that subsequently missed their Feb
24 deliverables? No, we’re doing the right thing despite the Aug
edict). Re “API freeze was set as M5 back in August”, indeed, but in August no date was set for M5, or any
other interim 2006 deliverables. We took a leap of faith in Aug signing
up for Callisto despite no timeline and no requirements. Despite a few
expected glitches here are there resulting from miscommunication or
over-burden, I believe we’re doing the right things to successfully move
Callisto Projects forward. Thanks, -- PS despite TPTP being
aligned since M3, if we do miss our M5 Mar 3 deliverable by a couple days, will
you please at least slow down the train before you toss me off J From:
Re late requirements, we were asked last year to
sign up to the Callisto train with very few known requirements. This is true,
but it's also true that participation in Callisto is entirely voluntary on the
part of each project. Of course if the Platform or JDT or EMF were to chose not
to participate, it would certainly be more difficult for the downstream
projects to participate. For projects like BIRT and TPTP and WTP (the leaf
projects), if you feel that the requirements are overly onerous or that your
situation is not being taken into account by the majority of the Callisto
project management team (this mailing list), then you are welcome to withdraw. Subsequently new requirements have popped up (as
one would expect considering the effort/challenge we’re confronted with)
and expectations were then conveyed that if projects don’t support
requirement X by (some near-term) date Y, they’re not on the Callisto train
(or at minimum, they’re not good Callisto citizens). I apologize if
I mis-conveyed the consensus of the Callisto team. I understood the
requirements for Callisto from day one, when we first discussed this at the
Planning Council meeting in August (see the
minutes), that this dire consequence (being dropped if you fall behind) was
the chosen one. If that is not what the Callisto team wants, then we (not me)
can change that. I will add that issue to Friday's conference call agenda. We expect new requirements arising from Callisto
and we’ll all do our best to accommodate such in a timely fashion, but we
are all managing projects to plans put in place a while ago and cannot simply
turn on a dime to redirect our efforts to meet some newly emerged
requirement. In these cases, where majority rules adopt new requirements,
some consideration should be given to projects intending to adopt, but needing
some flexibility in requirement/timing. I think this
is an excellent point and I will update the Callisto page to include a
statement along those lines.
-
API freeze date set at
the Dec 15 PC mtg. We (TPTP) were denigrated for not committing to this
new requirement on the spot ... The API freeze
was set as M5 back in August (see minutes
of meeting; TPTP was represented). Again, I thought I was representing the will of the Callisto
team. Please remember that Callisto is not my project, nor is it the Foundation's
project. Callisto was brought forth as an idea by the project teams (see the
minutes of the May Planning
Council). I am willing to push and coordinate and annoy and please people
to help make it happen, but it's happening must be the will and the consensus
of the teams involved. (I am also happy, if I've pissed off too many people, to
step aside.) (And I'm happy to accept criticsm of my communication style.) If
the teams involved, the teams that have signed up, collectively agree that
ICU4J is part of the requirements, then it is. If the teams collectively
agree that it is not, then it is not. It's not "Bjorn says this or
Bjorn says that" - it's "the ten leaders (Kevin, Tyler, Wenfend,
John, Dave, Steve, Doug, Ed, Rich, and Tim) who say this or that". |