| We all pay attention to you David! And you're right, you did ask. Thanks for that.
We want this to be one of the main community consumption points. N-1 feels a bit abrupt still. Community teams adopting milestones is a great asset. Forcing them to churn too frequently may conflict with their internal release flow. Having said that, the space issue is real. Perhaps three milestone (N, N-1 and N-2) retention would work. That gives at least 3 months availability for any given milestone.
Jeff On 2010-11-12, at 1:15 PM, David M Williams wrote: It is so good to know someone is paying attention! :)
I did ask ... so I can add them back ... but 1) in the past, we've sometimes had to remove when people made "big changes" (e.g. remove a feature) from from one milestone to the next (such as see bug 314165) and while I do not know of any such problems, I sort of had an intuition some projects were making big changes.
And 2) there have been pleas from webmasters to conserve space when possible (especially "mirrored" space) so ... I was thinking if there was no strong reason to keep them, we could save the space. (each of these milestones take about 1 G ... not earth tilting heavy ... but, ...
I don't think we can count on keeping them all around for the whole release, as those rock steady platform projects do, so would a good compromise be to plan on trying N and N-1? At least until some concrete problem is found by doing that? I'll assume the N and N-1 plan unless others voice a yea or nay.
Thanks,
<graycol.gif>Jeff McAffer ---11/12/2010 12:54:30 PM---Great! This will be very useful. I do wonder why M1 and M2 are being removed though. For example,
From: Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: 11/12/2010 12:54 PM
Subject: Re: [cross-project-issues-dev] Thanks for M3, on to M4!
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Great! This will be very useful.
I do wonder why M1 and M2 are being removed though. For example, anyone who has a target platform defined against the Indigo repo will be broken and forced to update.
The simultaneous release repos should follow a retention policy similar to that of the projects. OK, I've not done extensive analysis but, for example, the Eclipse and Equinox project retention policy [0] has milestone repos staying around until the release. This is good because in the real world the release repo (e.g., after SR1, SR2) will have multiple versions of things so having that throughout the development cycle mimics reality and enables workflow exploration, ...
Jeff
[0] http://wiki.eclipse.org/Eclipse_Project_Update_Sites
On 2010-11-12, at 11:28 AM, David M Williams wrote:
I've promoted the M3 staging bits to /releases/indigo and I believe EPP packages will be ready later today or Monday. I have disconnected the M1 and M2 parts of that common, composite repository, and will delete them early next week, unless someone speaks up soon and says they need them for testing, comparisons, or something.
On to M4! I have re-enabled the aggregation build. Now is the time to start those "experiments" with categories, etc. I recommend making changes like that with the b3 aggregator editor (since usually several files need to be updated when changing categories) but if you need help, just open a bug on cross-project component and I'd be glad to help. But in any case, be sure to be responsive to keeping the build green ... your break is most likely holding up someone else and preventing them from testing or getting work completed (at least me, if no one else :) .
Remember that M4 is a "short" cycle, with +0 being on 12/10 and +completelyDone just one week later on 10/17, instead of the leisurely 2 week window we have been enjoying. For more details, see the Indigo Release Plan. Be sure to contribute "warm-up" builds, especially if making changes to package structure or versioning.
M4 is also the magic milestone by which new-to-train projects need to declare their intent and get themselves into the aggregation build. (Not-new-to-train projects should already be in the builds, and all are, except one).
The first step to being in Indigo (for old and new projects) is always to mark your project's metadata at Foundation Portal, specifying 'Indigo=1' for the "simultaneousrelease" flag. I've pasted the current list of "marked" projects below. Old or new, be sure it's accurate by M4.
The Portal Tracking software is ready to receive your project's tracking input and status, but I'm sure there will be some tweaks to fix/improve some parts of it in the weeks ahead. The overview reports, or grid summaries, for Indigo are not yet ready and will take a week or two to get running accurately, I'm guessing. We'll target to be perfect by M4. :)
Feel free to ask questions here on cross-project list if anything is unclear, or you need help.
Thanks everyone,
= = = = =
From my quick check, here is the current list of (the high quality, highly responsive, on-track) projects that have indicated their intent to be in Indigo
There are 32, so far ... by the end of Helios, there were 84, at this low level of counting (though many are tracked at a higher level).
dsdp.sequoyah
eclipse
eclipse.platform
modeling.emf.cdo
modeling.emf.emf
modeling.emft.eef
modeling.emft.egf
modeling.emft.emf-facet
modeling.gmp.graphiti
modeling.m2m.atl
modeling.m2t.acceleo
modeling.mdt.modisco
modeling.mdt.ocl
modeling.mdt.papyrus
modeling.mdt.uml2
rt.equinox
rt.rap
rt.riena
soa.sca
technology.actf
technology.egit
technology.jgit
technology.m2e
technology.packaging
technology.packaging.mpc
technology.scout
technology.sketch
tools.mylyn
tools.objectteams
webtools
webtools.jsdt
webtools.sourceediting
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
