> was this decision mentioned on this list ? I wasn't aware of it and > also can't find > an announcement in the cross list's archive. > > This means we'll ship EGit 3.1 not with Kepler SR1 but from our own > updates site > since 1 month before SR1 already passed.
I'm not sure what to say. Sorry for not communicating better? Or, I assume Planning Council reps communicate with the projects they represent? Or, when did you think the deadline was? Or, should I say, remember we had to delay Juno SR2 by one week, for the first time ever, due to some last minute problems due to a project with late feature contributions, no rampdown plan, no incremental participation in release candidates, etc? That's why the rule was put in place. It is important we are on time, and it is important our quality improves each SR; no new problems introduced. That "rule" is the best concrete thing we could come up with to help ensure that. It was not a spur of the moment decision, but discussed over several meetings, with plenty of opportunity for Planning Council reps to solicit feedback and give advice. If interested, some history in https://bugs.eclipse.org/bugs/show_bug.cgi?id=401639 http://wiki.eclipse.org/Planning_Council/February_22_2013 http://wiki.eclipse.org/Planning_Council/March_06_2013#Juno_SR2 http://wiki.eclipse.org/Planning_Council/March_24_2013 All that said, I should (again) remind everyone there is an "exception process" http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Planning_Council_Exception_Process If you were missing the deadline by a day or two, I'm sure there'd be no problem getting an exception, but if you are planning on releasing and contributing right before RC4 then pretty sure you would not get one. There is no shame at all in releasing from your own project's repository on your own schedule, if that better suits your team. Its often a better approach for some. But, to participate in Simultaneous Release requires something more ... we have to be well "coordinated" with each other, to meet the expectations of users and adopters. So, I have decided ... I will just say, my personal apologies for not communicating this new rule better, and in a more timely fashion. I understand how you might have made different plans if you had known about it earlier. I hope its not too much extra work for you to adjust your plans, one way or another. Thanks for your contributions to Eclipse. From: Matthias Sohn <[email protected]> To: Cross project issues <[email protected]>, Cc: EGit developer discussion <[email protected]>, JGit Developers list <[email protected]> Date: 08/14/2013 02:49 PM Subject: Re: [cross-project-issues-dev] Question on Kepler SR1 release review Sent by: [email protected] On Wed, Aug 14, 2013 at 5:39 PM, David M Williams < [email protected]> wrote: Its "new" as of last April. was this decision mentioned on this list ? I wasn't aware of it and also can't find an announcement in the cross list's archive. This means we'll ship EGit 3.1 not with Kepler SR1 but from our own updates site since 1 month before SR1 already passed. And, by all means ... fix bugs and then submit a maintenance release for final version (which would not need a "new release"). "Released", in this context, means the formal Eclipse process of having been through the required release review which is always required of new releases. -- Matthias _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
