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

[Emil Velikov]

On 14 March 2018 at 20:13, Andres Gomez <agomez at igalia.com> wrote:
> On Wed, 2018-03-14 at 16:02 +0000, 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