Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Simultaneous Release Brainstorming
> * What would be the planning ?
> A proposed planning could be:
>  - M1 Friday Week 2
>  - M2 Friday Week 4
>  - M3 Friday Week 6
>  - M4 Friday Week 8
>  - RC1 Friday Week 9
>  - RC2 Friday Week 10
>  - Quiet week Week 11, it is assumed all code is done by the end of RC2.
>  - GA Wednesday Week 12

How about something simpler, with fewer delivery / alignment / integration checkpoints?

- C1 end of week 3 (checkpoint / integration build)
- M1 end of week 6
- C2 end of week 9 (second checkpoint)
 (RCs as needed)
- RCn end of week 12
- quiet period & GA release end of week 13

So for projects that want to do weekly RCs, they can (between week 9 and 12) and for those who don't, their GA contribution will be RC1 in week 12.

The reason I propose this 3-week sprint cadence instead of the mixed 2- and 3- week plan suggested on the PC call today is that in my experience, developers and managers have a tendency to lose track of when upcoming release dates occur... but by making them land consistently every 3 weeks, you have time for sprint planning, execution, and release/review, and things become more predictable. And 3 weeks is a good length of time to see progress since a previous milestone, so users are more likely to install the update than a 2-week update. I would bet if you do biweekly releases, users will update about once a month (skipping every other release). 

WDYT? 

To address the concern about there being insufficient time for testing between RCx (week 12) and GA (week 13), we need to ensure that more of the manual tests done today are automated and can therefore be run on every CI and simrel integration. Admittedly easier said that done, but that ought to be a prioritized goal for the new simrel, since with greater speed we NEED greater testing. I'm willing to pitch in to help with that, once I'm done breaking WTP, DTP, and RSE. :)

Nick

On Mon, Jan 22, 2018 at 5:48 AM, Martin Lippert <mlippert@xxxxxxxxx> wrote:
Hey!

I really like this change for the simultaneous release. Shipping releases more frequently and adapting the process towards that goal is a huge step forward, I think.
Thanks for pushing this forward, Mélanie, much appreciated.

The details sound good to me, but since I am not actively doing any of the steps below at the moment, my feedback is of limited value here, I think.

But from the adopters point of view:
It sounds to me like there will be no distinction between major and bugfix release anymore, right? (similar to what Platform is doing)
So do we expect users to update seamlessly to every new version? (if they have automatic updates enabled)
This would be a difference from previous behavior, where users typically didn’t got upgraded from Neon to Oxygen, for example.
And to be clear: I would be all in favor of these seamless automatic updates… :-)

Cheers,
-Martin





> Am 12.12.2017 um 19:17 schrieb mbats <melanie.bats@xxxxxxx>:
>
> Hi,
>
> During the last PC call, the attendees have decided to propose for the future of the SimRel that :
> * A new release will occur every 12 weeks.
> * All the work will be done only on one stream.
> * Only one repository will be used that will be continuously updated. A stable "latest" url will be used to allow the user to update continuously.
> * Specific urls will be available to reference any release.
> * The opt-in process will evolve, mostly projects would be assumed "in" and someone will take care of cleaning the outdated projects from time to time.
> * It would be possible to add, update and remove API on any release.
> Before deletion an announcement of the intention would be done a long time before (1 year or 2 year) in order that the depending projects have time to upgrade to the new API.
> * A nightly SimRel build should be running.
>
> If you have any problem with this decision, please make your voice heard on this list. If no comment is done before the next call in January, I will consider this as accepted by the all PC members.
>
> There is still some remaining questions, I would like to get your opinion on :
>
> * What would be the planning ?
> A proposed planning could be:
> - M1 Friday Week 2
> - M2 Friday Week 4
> - M3 Friday Week 6
> - M4 Friday Week 8
> - RC1 Friday Week 9
> - RC2 Friday Week 10
> - Quiet week Week 11, it is assumed all code is done by the end of RC2.
> - GA Wednesday Week 12
>
> * How do we organize the verification & tests in order to evolve from a by hand homologation to a more automatic one ?
> How do we implement integration testing ? Do we automatically create something which contains everything starting it and see how it is going on ? who would be responsible for that ?
>
> * How do we name the releases ? What do we do about code names?
> It exists at least 3 different possibilities:
> - Using a year/month pattern : YYYY-MM
> - Using codename pattern : CodeName.X
> - Using a mix of the two previous patterns : YYYY-MM CodeName.X
>
> Please give your opinion by replying to this thread. If you see other items we should discuss do not hesitate to add them the remaining questions list!
>
> Thanks all for your participation,
> --
> Mélanie Bats
> CTO
> +33 7 87 69 42 84
> +33 5 34 57 16 29
> @melaniebats
>
> *Obeo*
> 25 Boulevard Victor Hugo - Colomiers - France
> http://www.obeo.fr
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> 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.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@eclipse.org
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

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.



--

Nick Boldt

Senior Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt / http://nick.divbyzero.com



“The Only Thing That Is Constant Is Change” - Heraclitus

Back to the top