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

[Andres Gomez]

On Wed, 2018-03-21 at 20:43 +, Emil Velikov wrote:

> 
> All in all the idea sounds sane. As a summary/overall:
>  - Maintainer: open meta bug, send usual release plan + mention that
> feature should be added to the tracker
>  - Developers: add bugs to tracker, or
>  - Developers: list via other means (email/IRC) of the features
> they're aiming for -> Maintainer: add those to the tracker
>  - Maintainer: follow-up reminders closer to the branch point
>  - Maintainer: one week before branchpoint check with developers if
> features are still on track - drop otherwise
> And as always:
>  - Developers: can propose minor adjustments (need a definition, say 1
> week?) to the schedule up-to the 3 days before the branchpoint.
> 
> Or in a sentence: There's no actual changes, things are better
> documented and more explicit for everyone to see.
> 
> I believe that describes it nicely, right?

Yes, good summary.

> Andres care to do the honours and add that to the existing documentation?
> Might be worth splitting it out to separate page, since the existing
> one is getting bit cluttered.

Right! I'll get to it and send a patch for review soon-ish.

-- 
Br,

Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 14 March 2018 at 20:13, Andres Gomez  wrote:
> On Wed, 2018-03-14 at 16:02 +, Emil Velikov wrote:
>
> [...]
>>
>> Just double-checking:
>> I would suspect you're not suggesting removing the existing email/poke 
>> scheme?
>
> Partially. The "announce" mail for the pre-branching period will still
> happen, pointing to the "Metabug" in which to add the WIP features that
> developers intend to land before the deadline.
>
> If some of the developers just reply by mail/IRC/you-name-it, then it
> will be the release manager task to add the blocking bugs with the WIP
> features, as a way of documenting them.
>
Ack makes sense.

>> 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
>
> I don't think much interaction/documentation is needed. Just mention
> the WIP feature and update its status eventually ... and only for the
> ones developer X wants to have at branchpoint Y before that happens.
> The rest of the work of developer X doesn't need to be in Bugzilla.
>
The gist sounds fine.

>>  - Do I open another bug, or list my feature in the metabug - seeming
>> an ongoing theme with metabugs
>
> I think it should be a new blocking bug but I'm open to just document
> it in the Metabug.
>
I'm also inclined to have each feature as separate bug, all listed in
the metabug.

>>  - Do I add the bug, reply to the email or both
>
> Preferably, just add the bug.
>
> Once the bug is created and all the parties are in Cc for the bug, I
> understand there is no need for any other way of communication. I'm
> still open to reconsidering, though.
>
All in all the idea sounds sane. As a summary/overall:
 - Maintainer: open meta bug, send usual release plan + mention that
feature should be added to the tracker
 - Developers: add bugs to tracker, or
 - Developers: list via other means (email/IRC) of the features
they're aiming for -> Maintainer: add those to the tracker
 - Maintainer: follow-up reminders closer to the branch point
 - Maintainer: one week before branchpoint check with developers if
features are still on track - drop otherwise
And as always:
 - Developers: can propose minor adjustments (need a definition, say 1
week?) to the schedule up-to the 3 days before the branchpoint.

Or in a sentence: There's no actual changes, things are better
documented and more explicit for everyone to see.

I believe that describes it nicely, right?

Andres care to do the honours and add that to the existing documentation?
Might be worth splitting it out to separate page, since the existing
one is getting bit cluttered.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andres Gomez]

On Wed, 2018-03-14 at 16:02 +, Emil Velikov wrote:

[...]
> 
> Just double-checking:
> I would suspect you're not suggesting removing the existing email/poke scheme?

Partially. The "announce" mail for the pre-branching period will still
happen, pointing to the "Metabug" in which to add the WIP features that
developers intend to land before the deadline.

If some of the developers just reply by mail/IRC/you-name-it, then it
will be the release manager task to add the blocking bugs with the WIP
features, as a way of documenting them.

> 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

I don't think much interaction/documentation is needed. Just mention
the WIP feature and update its status eventually ... and only for the
ones developer X wants to have at branchpoint Y before that happens.
The rest of the work of developer X doesn't need to be in Bugzilla.

>  - Do I open another bug, or list my feature in the metabug - seeming
> an ongoing theme with metabugs

I think it should be a new blocking bug but I'm open to just document
it in the Metabug.

>  - Do I add the bug, reply to the email or both

Preferably, just add the bug.

Once the bug is created and all the parties are in Cc for the bug, I
understand there is no need for any other way of communication. I'm
still open to reconsidering, though.

-- 
Br,

Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 14 March 2018 at 11:20, Andres Gomez  wrote:
> Hi,
>
> On Mon, 2018-03-12 at 18:02 +, Emil Velikov wrote:
>> Hi Andres,
>>
>> On 12 March 2018 at 15:57, Andres Gomez  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andres Gomez]

Hi,

On Mon, 2018-03-12 at 18:02 +, Emil Velikov wrote:
> Hi Andres,
> 
> On 12 March 2018 at 15:57, Andres Gomez  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

Hi Andres,

On 12 March 2018 at 15:57, Andres Gomez  wrote:
> On Mon, 2018-03-12 at 16:45 +0100, Juan A. Suarez Romero wrote:
>> >
>> On Mon, 2018-03-12 at 17:17 +0200, Andres Gomez wrote:
>
> [...]
>
I'm fully on board with your initial suggestion.


>> > My proposal would be, similarly to what Intel does to track [1] the
>> > stabilization for a release, 1 week (?) prior to the branching time to
>> > create a metabug in bugzilla (or GitLab in the future ?), to announce
>> > this metabug in mesa-dev and to let any developer who wants to see
>> > their feature into the coming release to open a blocking bug for this
>> > metabug explaining such feature and its progress. This way we can track
>> > the progress and the process will be more transparent. We can still be
>> > flexible to include the blocking features but the coordination will
>> > happen over these bugs.
>> >
>>
>> So, when the branch point is created? After the metabug is closed? or 1 week
>> after the metabug is created?
>>
>>
>> Not sure if this provide any difference on what we are doing now: create the
>> branchpoint, open a metabug with the desire features, and cherry-pick all the
>> patches that solves the metabug.
>>
>
> 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.

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?


Thanks
Emil

* 3+days/a week before the branch point
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andres Gomez]

On Mon, 2018-03-12 at 16:45 +0100, Juan A. Suarez Romero wrote:
> > 
> On Mon, 2018-03-12 at 17:17 +0200, Andres Gomez wrote:

[...]

> > My proposal would be, similarly to what Intel does to track [1] the
> > stabilization for a release, 1 week (?) prior to the branching time to
> > create a metabug in bugzilla (or GitLab in the future ?), to announce
> > this metabug in mesa-dev and to let any developer who wants to see
> > their feature into the coming release to open a blocking bug for this
> > metabug explaining such feature and its progress. This way we can track
> > the progress and the process will be more transparent. We can still be
> > flexible to include the blocking features but the coordination will
> > happen over these bugs.
> > 
> 
> So, when the branch point is created? After the metabug is closed? or 1 week
> after the metabug is created?
> 
> 
> Not sure if this provide any difference on what we are doing now: create the
> branchpoint, open a metabug with the desire features, and cherry-pick all the
> patches that solves the metabug.
> 

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 hope this clarifies.

-- 
Br,

Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Juan A. Suarez Romero]

On Mon, 2018-03-12 at 17:17 +0200, Andres Gomez wrote:
> Hi,
> 
> Juan and I have been talking lately that it is clear that reaching the
> final version of a feature releases is often getting hard.
> 
> Therefore, we would like to propose that no stable release will be
> carried on by the same release team member while on duty doing a
> feature release. This will help to avoid collateral problems like
> delays on bugfixing releases, for example.
> 
> In other words, we propose that Emil will be taking care of focusing on
> the feature releases while Juan and I will be the ones doing the bugfix
> releases, by now.
> 

I agree. This is something that we try to do, but it is good that we explicitly
state it. 

This would unload Emil for working in two releases at the same time, giving him
more time to work on other tasks, if required.

> --
> 
> Additionally, I'd welcome greater visibility/transparency on the
> process leading to the selection of a branch point for a feature
> release [0].
> 
> Right now this is loosely explained process by which the release team
> member doing the branch announces their intention and gets feedback
> from developers who would like to still complete some feature before
> the creation of the branch.
> 
> My proposal would be, similarly to what Intel does to track [1] the
> stabilization for a release, 1 week (?) prior to the branching time to
> create a metabug in bugzilla (or GitLab in the future ?), to announce
> this metabug in mesa-dev and to let any developer who wants to see
> their feature into the coming release to open a blocking bug for this
> metabug explaining such feature and its progress. This way we can track
> the progress and the process will be more transparent. We can still be
> flexible to include the blocking features but the coordination will
> happen over these bugs.
> 

So, when the branch point is created? After the metabug is closed? or 1 week
after the metabug is created?


Not sure if this provide any difference on what we are doing now: create the
branchpoint, open a metabug with the desire features, and cherry-pick all the
patches that solves the metabug.


> Likewise, once the branch point is created, I would create another
> metabug to track the progress of eventual regressions until the final
> release version.
> 


> 
> [0] https://www.mesa3d.org/releasing.html#branch
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=104757
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andres Gomez]

Hi,

Juan and I have been talking lately that it is clear that reaching the
final version of a feature releases is often getting hard.

Therefore, we would like to propose that no stable release will be
carried on by the same release team member while on duty doing a
feature release. This will help to avoid collateral problems like
delays on bugfixing releases, for example.

In other words, we propose that Emil will be taking care of focusing on
the feature releases while Juan and I will be the ones doing the bugfix
releases, by now.

--

Additionally, I'd welcome greater visibility/transparency on the
process leading to the selection of a branch point for a feature
release [0].

Right now this is loosely explained process by which the release team
member doing the branch announces their intention and gets feedback
from developers who would like to still complete some feature before
the creation of the branch.

My proposal would be, similarly to what Intel does to track [1] the
stabilization for a release, 1 week (?) prior to the branching time to
create a metabug in bugzilla (or GitLab in the future ?), to announce
this metabug in mesa-dev and to let any developer who wants to see
their feature into the coming release to open a blocking bug for this
metabug explaining such feature and its progress. This way we can track
the progress and the process will be more transparent. We can still be
flexible to include the blocking features but the coordination will
happen over these bugs.

Likewise, once the branch point is created, I would create another
metabug to track the progress of eventual regressions until the final
release version.


[0] https://www.mesa3d.org/releasing.html#branch
[1] https://bugs.freedesktop.org/show_bug.cgi?id=104757
-- 
Br,

Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev