Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Simultaneous ReleaseBrainstorming

I would assume we'd still keep the Friday +0, Monday +1, +2, +3, Thursday EPP cycle, but that didn't specifically come up on the call. 
+1

Would everyone agree?
+1

I would replace M1 with just M as we only have one milestone.

Dani



From:        Nick Boldt <nboldt@xxxxxxxxxx>
To:        Eclipse Planning Council private list <eclipse.org-planning-council@xxxxxxxxxxx>
Date:        08.02.2018 21:13
Subject:        Re: [eclipse.org-planning-council] Simultaneous Release        Brainstorming
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx




I would assume we'd still keep the Friday +0, Monday +1, +2, +3, Thursday EPP cycle, but that didn't specifically come up on the call. 

Would everyone agree?

If I see a few more +1s on my 3/6/9/12/13 plan, I can draft some actual dates to see where in the calendar those might land, and determine if it aligns nicely with the PTO/AFK times where we don't want to schedule important releases, like end Dec/early Jan, March Break, or first week July.

Depending on how things line up, we might have to go back to Ed/Melanie's idea of doing a 12-week cycle with 1-2 week buffers in between to shunt things away from holiday outages. I prefer the mathematically cleaner approach to 4 x 13 = 52, but I'm a realist when it comes to cat-herding humans. :)

Cheers,

 

On Thu, Feb 8, 2018 at 4:18 AM, Martin Lippert <mlippert@xxxxxxxxx> wrote:

Hey!

Sounds good to me.

I remember from the current schedule that there is a one-week shift between the platform builds and the packages.
Will this be changed? From the schedule it looks like everything happens at once.

Cheers,
-Martin





> Am 07.02.2018 um 19:18 schrieb Nick Boldt <
nboldt@xxxxxxxxxx>:
>
> > * 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@xxxxxxxxxxx
> >
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@xxxxxxxxxxxto request removal.
>
> _______________________________________________
> eclipse.org-planning-council mailing list
>
eclipse.org-planning-council@xxxxxxxxxxx
>
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@xxxxxxxxxxxto request removal.
>
>
>
> --
> Nick Boldt
> Senior Software Engineer, RHCSA
> Productization Lead :: JBoss Tools & Dev Studio
> IM: @nickboldt / @nboldt /
http://nick.divbyzero.com
>

> TRIED. TESTED. TRUSTED.
> @ @redhatnews      Red Hat
>
>
> “The Only Thing That Is Constant Is Change” - Heraclitus

> _______________________________________________
> eclipse.org-planning-council mailing list
>
eclipse.org-planning-council@xxxxxxxxxxx
>
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@xxxxxxxxxxxto request removal.

_______________________________________________
eclipse.org-planning-council mailing list

eclipse.org-planning-council@xxxxxxxxxxx
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@xxxxxxxxxxxto request removal.



--

Nick Boldt

Senior Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

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


TRIED. TESTED. TRUSTED.

@ @redhatnews     Red Hat


“The Only Thing That Is Constant Is Change” - Heraclitus
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=xbBVV9c3X_6XyH2875BDFIggCtUmzsdNWxVVW3KyQNE&s=W4UBgLH6lm-W3KglDrF0XdOOkf0Cd_Ds9-H973UQFdo&e=

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.




Back to the top