[eclipse.org-planning-council] Some observations on Ganymede update site

[David M Williams <david_williams@xxxxxxxxxx>]

I'm probably least able to judge the
relative trade-offs of to have a single update site or not (since it seems
so obvious to me it's beneficial, I must be missing the amount of cost
associated with it -- though I know first hand it is a LOT of work -- besides,
we all know, as soon as someone says "yes I want it", then Bjorn
will say "ok then, you do it" :)  
 ... but, I can't resist a few
observations ... 

And, to start, I certainly think there's
arguments to be made both for and against it ... the exact tipping point
is what's hard to judge. And Bjorn has convinced me we are closer to that
point than I would have ever guessed off hand, so it's been a good, constructive
discussion -- I appreciate it being brought up. 

But ... is this the right list or audience
to be asking? Seems someone should ask the end-users and adopters, if they
are proposing a "last minute" change to our plan (e.g. on one
or a few of the newsgroups? perhaps with a bug open for comments? While
this alone wouldn't be definitive, seems it should be asked. If, as planning
council member, we are being asked to represent our best guess of what
end-users and adopters want, I'd have to say "yes, they want it".
 (but ... not _me_ ... I don't want to take over the work!  :)


Also, I think there is merit, in just
basic human nature (or, is it software project management :), to get a
heterogeneous group to do _anything_, they should have a common, concrete
deliverable ... I think that has been one of the reasons the "simultaneous"
part has been a success. I remember the problem before was not that we
would not deliver something on (nearly) the same date, and we started this
was not just that people had to go to multiple places to get things, but
because even if they did somehow manage to get everything, it still would
not work together due to very basic, but subtle problems. And so then it
was a not only a matter of going to different places, but you also had
to get the exact right level of "fix pack" to install together
... and it was not always "the most recent" version of everything
that worked together ... but, often something like the 3.1.1 version of
the platform, the 1.5.4 version of WTP, unless you used TPTP, and then
you'd have to stay on the 1.5.3 version of WTP but if you used BIRT then
you had to use the XX version of TPTP which required the 1.5.1 version
of WTP but then you couldn't get the fixes in 1.5.4 of WTP (just as a fictional
example).
And, this is not too much of a problem
for adopters ... not the greatest situation, but they usually know what
to get and what the trade-offs were ... but, a complete show stopper for
casual Eclipse end-users. 

Also, I can easily think of two recent,
important bugs that have been found (and fixed!) because of the common
deliverable. One was the issue that only appeared when slightly different
qualifiers in Batik bundles where in the same stack ... and that led to
a fix in equinox's (and OSGi's spec!) handling of jointly using 'require
bundle' and 'import package'. If homogeneous packages had been the deliverable,
I'm not sure anyone would have ever noticed this issue, until it was too
late to fix this release. The other was the recent issue with the site
optimizer's pack function not working correctly on heterogeneous directories
of signed jar files. As long as the directories of jars were not signed
or if they were homogeneous (that is, everyone in the directory used the
same 'options' when conditioning) then the problem did not appear. It's
only when you mix projects that happened to have picked different options
that the problem surfaced. Both of these, especially the latter, could
be perceived as part of the extra hassle of trying to have a common update
site ... but, I think finding the issues (and fixing them in time for the
release) is part of the benefit. And, true, these _might_ have been found
even in the have-a-few-packages approach ... but, that's not obvious to
me (since it's more likely, then, there would be homogeneity in the bundles
being packed or homogeneity in the Batik bundle qualifiers). I am sure
there are other such bugs, but those are two I can think of right off.


On the issue of the common update site
just duplicates what's on other update sites ... this isn't true for WTP,
exactly. The common update site is a subset of what's on WTP, and this
was supposed to be the way it was for lots of projects ... people could
easily get the "main stuff" from the common site, and then go
to the project sites to get extra stuff and out-of-cycle maintenance. Besides
some out of cycle fixes, we in WTP have the "SDK" code and documents
only on our project site, not Ganymede, and we also have some incubating
projects on our project site, but not in Ganymede. Sounds like maybe for
others there's not much difference? 

Perhaps most important, as with Eclipse
in general, if not every open source project, you get out of it what you
put in to it. And, I'll be the first to admit I've been disappointed about
the amount of work put in to it the common site effort (but ... I can say
I have the same disappointment about the "packages" approach
... and here I am mostly blaming myself, knowing me nor my project has
done what I originally thought we could). 

So ... just observations. No definitive
answers :( 
If I had to vote right now, I'd say
let's keep the common update site for Ganymede. If I had to volunteer to
help with it, I guess I'd say I would help, some. 
(Oh, wait ... _ I  already  do
help _  at least some :)  How about all you other "yes we
should keep it" people ... how are you helping? :)

Perhaps another topic we can all rant
on for a while is who should we vote off the island? M7 is coming up. Has
everyone done all the "must do" items? Last I looked there were
still a lot of unsigned jars .... I propose those projects be removed
immediately (or voluntarily remove themselves) since signed jars was a
'must do' item, and if you haven't done it by now ... well ... you're late!
Will someone volunteer to tabulate other "must do" item compliance?
I assume we could expect a report from each PMC on the projects they manage?
Or, put another way, if a project was found to be lacking, and that PMC
was not aware and not already working to remove or rectify that project,
then that PMC should get the nasty "blame" note, from you-know-who
(i.e. he who can not be named  :) 

One final note ... I've always thought
the "simultaneous release" (common site or not) needed a "full
time" leader ... well, half time, at least ... so perhaps without
that, we'll never have satisfactory solutions. It'd be a little like having
EclipseCon without a Program Director (sure, you have the committee, but
I think the head of the committee is no casual effort! ... just guessing
... I'm not volunteering for that either! :)  So, I really do appreciate
and am sensitive to the cost-benefit trade-off argument, and am just not
sure how to judge the point where the cost gets to be too much for the
benefit. And, in that respect, I give Bjorn's judgement a lot of weight
... if _he_ doesn't see the benefit of the work he is doing, then why not?
who would, if not him? 

Sorry to have rambled on in such a long
note ... writing too late at night :) 

Sincerely,