[cross-project-issues-dev] Re: [eclipse.org-planning-council] Some observations on Ganymede update site topic
I know Nick is still working on helping some groups with signed jars, so this voting-folks-off-the-island issue hits close to home. Likely they'll all be done by M7 and certainly they'll all be done in time for the release. We did recently have a few components that removed themselves because they couldn't meet their build commitments, so definitely encouraging folks to withdraw is a good thing. But the more general issue we'd need to address is what happens when a prerequisite to other projects is voted off the island? Does it take all of the train behind it along for a ride off the rails? If not, does that mean leaf nodes and internal nodes in the dependency tree will get different consideration?
How about if we start by making a list of who's violating which rules, find out what the offenders intend to do to rectify the issues, and then talk about what to do with the intransigent cases when public humiliation proves ineffective... I wonder who would do that work? Hey, didn't you bring the issue up? :-P
905-413-3265 (t/l 313)
David M Williams <david_williams@xxxxxxxxxx>
David M Williams <david_williams@xxxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx
04/30/2008 04:42 AM
Please respond to
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 :)
eclipse.org-planning-council mailing list
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.