[Mesa-dev] [RFC] Mesa release improvements - Feature and Stable releases

[Emil Velikov]

On 14 March 2018 at 11:20, Andres Gomez <agomez at igalia.com> wrote:
> Hi,
>
> On Mon, 2018-03-12 at 18:02 +0000, Emil Velikov wrote:
>> Hi Andres,
>>
>> On 12 March 2018 at 15:57, Andres Gomez <agomez at igalia.com> wrote:
>> >
>
> [...]
>
>> >
>> > 18.1 example:
>> >
>> >    1. Create a Metabug for the 18.1 branch point.
>> >    2. Announce the Metabug in mesa-dev and give 1 week (?) for developers
>> >       to complete their features. Advice to block the Metabug with other
>> >       feature bugs.
>> >    3. Developers create bugs with the WIP features they want to include in
>> >       18.1 and block the Metabug.
>> >    4. After 1 week, check the status
>> >        * If there are no blockers, close the Metabug and create the 18.1
>> >       branch point.
>> >        * If there are blockers; coordinate with the developers of the
>> >       blockers and decide whether to give a bit more of margin if the
>> >       feature is almost complete or just remove the blocking bugs
>> >       leaving the WIP features out, close the Metabug and create the
>> >       18.1 branch point.
>> >    5. Release 18.1-0-rc1.
>> >    6. Create a Metabug to track the status of the final 18.1.0 release.
>> >    7. Block this Metabug with regressions found from 18.1.0-rcX.
>> >    8. Once we reach stability, close the Metabug and announce the final
>> >       release of 18.1.0.
>> >
>>
>> I might sound a bit negative, yet I'm not sure what this brings us.
>> Can you please elaborate?
>>
>> The original goal is to have the time based releases, as opposed to
>> feature ones.
>> That was reiterated by developers not too long ago.
>
> Ugh!
>
> I had very similar comments from Juan, so I may have explained myself
> very badly ...
>
Guessing that I might have read more than what was said :-\

>> So far, there has been an announcement email 2-4 weeks before the
>> branch point, aiming to:
>>  - remind, and
>>  - seek feedback about required features
>>
>> The email was also followed by weekly ping/reminder.
>>
>> IIRC suggestions and requests that are made in timely fashion* have
>> always been accepted.
>> If we're adopt the above approach, this will:
>>  - lead to noticeable delays in the branch point, which combined with
>>  - the current delays getting the blocking bugs fixed. equals
>>  - even greater delays and less time based releases
>>
>> Furthermore I'm a bit worried that this might have negative impact on
>> developers:
>> I don't know any instances, yet some developers may put extra pressure
>> on themselves trying to get 'too many' features merged. Leading to
>> stress, burn out and others.
>>
>>
>> Perhaps we can somehow utilise your suggestion while ensuring that my
>> grim 'predictions' do not come true?
>
> My suggestion is not to change the paradigm (time based vs feature
> based releases) but rather to have better visibility of how the time
> based feature releases are done.
>
> In other words, I'm not expecting to delay the time of the branchpoint.
> I still believe we can have tiny flexibility for features that are just
> about to land. I also believe this is the current way we are working,
> isn't it?
>
> The proposal only intends to have a central point (a Metabug) in which
> to track the status of the branch point rather than just in several
> mails and in multiple pings which may happen by different ways (mail,
> IRC, ... ?).
>
> And the same for tracking the final release.
>
> WDYT? Is this too complicated or time consuming for the release manager
> at the given time? Do you think it would be useful?
>
Just double-checking:
I would suspect you're not suggesting removing the existing email/poke scheme?

Providing another means to devs to track/handle things is good IMHO.
Whether developers will like it is up-to them. Everyone, your input is
appreciated!


I'm slightly worried that it might cause extra confusion.
Some crude examples follow:
 - I don't use bugzilla/etc to track my feature work - most teams
 - Do I open another bug, or list my feature in the metabug - seeming
an ongoing theme with metabugs
 - Do I add the bug, reply to the email or both


-Emil