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

[Andres Gomez]

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 ...

> 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?

-- 
Br,

Andres