+1 for keeping the common update site
I agree that many bugs have been fixed
that were identified by assembling a common update site that probably wouldn't
be reported otherwise. Issues with multiple versions of third party
libraries, signing, packing and site digests have fixed as as result of
this rudimentary integration testing. There are also UI issues that
have been addressed when the community tests the milestones. Many
eyes make better software, isn't that what open source is about?
It think it would be a disservice to
the eclipse community to force end users and integrators to once again
hunt for the corrects bits to work together. Who wants to
go back to 2005?
Isn't it too late in the Ganymede cycle
to contemplate removing the common update site when this is a deliverable
that the community expects? Also, it would be unfortunate for those projects
who gain additional community exposure in the update site but don't have
the resources to create packages to be excluded from Ganymede.
David M Williams <david_williams@xxxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
04/30/2008 04:42 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
[cross-project-issues-dev] Some observations
on Ganymede update site topic
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
(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
cross-project-issues-dev mailing list