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

FYI, the Eclipse TLP applies an API and feature freeze with RC1. This aligns with the rule that the release review must be submitted by RC1.

> * All the work will be done only on one stream.
I think this should be left to the projects. It's not important for the release train.

We still need to be nail how the legal team can handle the load of CQs and how we deal with the release reviews, Maybe they can be simplified?

Dani



From:        mbats <melanie.bats@xxxxxxx>
To:        eclipse.org-planning-council@xxxxxxxxxxx
Date:        12.12.2017 19:18
Subject:        Re: [eclipse.org-planning-council] Simultaneous Release        Brainstorming
Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx




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
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.obeo.fr&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=G_AfyzGyed-yeTcXekbOewSA5ZdVE6L82OTqGSeUTEI&s=ccy_xG5voJXKjvgogMH1tDoy9ZgMRIyaf0fnk0CkDI4&e=
_______________________________________________
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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=G_AfyzGyed-yeTcXekbOewSA5ZdVE6L82OTqGSeUTEI&s=CUIhcjbLEmwsveS-5CzETUihEBcPv5n3qFmCm9m2j2Y&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