[OpenDaylight TSC] [release] modify carbon release plan to only allow fixes for blocking bugs during RCs?

Jamo Luhrsen jluhrsen at gmail.com
Fri Dec 16 23:49:57 UTC 2016



On 12/15/2016 01:39 PM, Colin Dixon wrote:
> Given that we voted to make RC0 the boundary where only blocking bugs could be fixed and this is both different from the
> beginning of Carbon and previous releases, we should probably do our best to disseminate it. Even maybe getting people to
> acknowledge it in milestone readouts.

I think this milestone ack is probably close to essential, just so everyone can know that the
information has been received and digested by each project.

JamO

> --Colin
> 
> 
> On Thu, Dec 15, 2016 at 10:18 AM, Colin Dixon <colin at colindixon.com <mailto:colin at colindixon.com>> wrote:
> 
>     So, I think there's a lot of good discussion here. It sounds like we have 2-3 key proposals
> 
>     1.) We should make "only blocking bug fixes allowed" happen at least by RCX for offset X that is offset 0 at RC0, offset
>     1 at RC1 and offset 2 at RC2. This seems like a no-brainer and we should just vote on it today.
> 
>     2.) Perhaps we make "only blocking bug fixes allowed" happen at RC1 and remove RC0.
> 
>     3.) Make "only blocking bug fixes allowed" happen at RC0 and make it a real RC.
> 
>     4.) We really desperately need to figure out how to get more discipline at M3/M4/M5.
> 
>     --Colin
> 
> 
>     On Tue, Dec 13, 2016 at 11:13 AM, Luis Gomez <ecelgp at gmail.com <mailto:ecelgp at gmail.com>> wrote:
> 
>         I think there are 2 separated issues (note this is orthogonal to the original discussion of making RCs real RCs):
> 
>         1) Projects not adhering to milestones: An can tell more but I think most of the projects do well and when do not
>         they usually send ETA for accomplishment. On the other hand, there is always some project (normally leaf) that
>         consistently miss milestones and require lot of notifications from release management, mostly because of lack of
>         active committers. This is treated in a separate thread [1] but I think TSC should drop these project from the SR.
> 
>         2) Projects start to test late: we always ask projects to start some testing at M3 when features are in the
>         distribution, but normally the real test is effectively happening between M5 and RCs (sometimes during RCs). The
>         reason for this could be: 1) devs are busy finalizing features and that is prioritized over the testing, and 2) the
>         RC process forces projects to report the results of the RC test in an spread sheet. For the first we will need PTLs
>         to rebalance the effort from development to testing though the release cycle, for the second we could ask projects to
>         fill some test template on autorelease distribution before first RC comes. 
> 
>         [1] https://lists.opendaylight.org/pipermail/tsc/2016-November/006368.html
>         <https://lists.opendaylight.org/pipermail/tsc/2016-November/006368.html>
> 
>>         On Dec 12, 2016, at 5:05 PM, Anil Vishnoi <vishnoianil at gmail.com <mailto:vishnoianil at gmail.com>> wrote:
>>
>>
>>
>>         On Mon, Dec 12, 2016 at 1:25 PM, Robert Varga <nite at hq.sk <mailto:nite at hq.sk>> wrote:
>>
>>             On 12/09/2016 11:42 PM, Anil Vishnoi wrote:
>>             > So as per the release plan M5 time period is basically to start the
>>             > testing of all the features that is being developed by M4 time frame,
>>             > because it says M5 should be only bug fixes.
>>
>>             I cannot seem to stress this enough: M3 is the Feature Freeze milestone.
>>             That means no new features after M3 deadline.
>>
>>             M4 is for shaking out API issues and working with downstreams to ensure
>>             that the APIs match expectations -- which for Offset-2 projects really
>>             means external interfaces, which I would assume includes testing.
>>
>>             M5 is for making the implementation solid -- be it bugfixes, or
>>             *internal* refactorings.
>>
>>>>         I thought i said the same thing isn't it ;). In my personal opinion, feature implementation is not done tills it's
>>         relevant API's are not done.​ 
>>          
>>
>>
>>             This is a matter of gradual development ramp-down and happens on any
>>             reasonably-QA'd project.
>>
>>             If we cannot make these three work and projects abide by them, I simply
>>             do not see how any RC-time rules will make up for lack of proper release
>>             management at project level during previous ~3 months.
>>
>>
>>             If that really is the case, then we can just ditch M3 and M4 and give
>>             ourselves two more months of "RCs" without impacting the release date.
>>>>
>>>>         ​Ideally
>>         ​projects should adhere to these guidelines, and if project adhere to it, nothing better then that, it's a happy
>>         and ideal world, but 
>>         my experience is otherway around. 
>>         So looks like we need some way to enforce it ? what should we do if project don't adhere to the release plan? As as
>>         TSC are we okay to drop the project from release if project don't strictly follow release milestone? In my personal
>>         opinion that's bit hard to do (not saying it can't be done), because there are lot of variable we have in the whole
>>         process of being "community" driven projects. What I have seen in general is folks start the testing after M5/RC0
>>         comes out, and in that case it's obvious that you will get lot of blocker bugs and some of them probably will
>>         require lot of refactoring and need to merge huge size patches at the last moment, and that also doesn't seem like
>>         professionally-executed project either :(. 
>>
>>         And i think as a first step atleast we need to draw that line and RC1 seems to be good option. If we think that's
>>         not going to work, then TSC should start monitoring all the 70+ projects' progress and enforce each milestone ( i
>>         don't think ,milestone status mails will help here, we need to look at what code is actually going in the repo for
>>         that :) ).
>>
>>>>
>>             It would probably work about as well as Boron did, without the pretense
>>             of a professionally-executed project :(
>>
>>             Regards,
>>             Robert
>>
>>
>>
>>
>>         -- 
>>         Thanks
>>         Anil
> 
> 
>         _______________________________________________
>         release mailing list
>         release at lists.opendaylight.org <mailto:release at lists.opendaylight.org>
>         https://lists.opendaylight.org/mailman/listinfo/release <https://lists.opendaylight.org/mailman/listinfo/release>
> 
> 
> 
> 
> 
> _______________________________________________
> TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
> 


More information about the TSC mailing list