The primary intent behind a plan is to give potential contributors some
sense of how they can contribute.
I have no trouble putting you down for 2.2.1 for now with an expectation
that--should you receive contributions that warrant the creation of a
new release--you'll create a new release record (say 2.3.0) at a later date.
The actual name of your release and whether or not you create a new
release record is not nearly as important as making sure that you get
proper practice participating in the release and that your bits don't
break the aggregation. So declaring a new release before M4 isn't as
important to me as making sure that you know what bits you'll actually
be contributing early enough in the cycle to do adequate testing.
I hope that this makes sense.
Wayne
On 07/30/2014 01:04 PM, Mickael Istria wrote:
On 07/30/2014 06:47 PM, Wayne Beaton wrote:
Can I assume that you mean Mars? ;-)
Sure, you can assume that ;)
I've started assembling the list of projects/releases that will join
Mars [0]. I'll put you down for 2.2.1 for now
Thanks.
if you do decide to include a different release with Mars, then let
us know on this list (before the M4 deadline) and I'll update the record.
More generally... participating projects should create a record (if
one does not already exist) for the release that they intend to
contribute in the PMI and then inform the community via this list.
Remember that project plans need to be specified by M4. A minimal
plan that includes a description [1] of the release and a list of
issues [2] (which we can generate automatically) shouldn't be too
onerous, I hope. It would be good if you can capture a theme or two
for your plan.
SWTBot doesn't really have a plan. People come and contribute what
they want, and we release when we feel it's worth it. So I'm already
thinking about how to hack this contribution process without planning
a release. M4 is in December. Between December and June, there can be
something like 3 or 4 releases (or 0) that cannot be planned before M4.
In the case of SWTBot, we're not much interested about the
Simultaneous Release planning, which for a small project such as
SWTBot could prevent from frequent releases if necessary. What
interest us is more to be included in Mars site and EPP package and
making sure we work well with other projects of this same Mars site.
Can the Release Train (or in that case the aggregator only) process
handle the possibility of an unexpected release after M4 ?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
<http://www.eclipse.org>
Learn about Eclipse Projects <http://www.eclipse.org/projects>
EclipseCon Europe 2014 <https://www.eclipsecon.org/europe2014>
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
