[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Juan A. Suarez Romero]

On Thu, 2018-03-22 at 00:28 +0000, Emil Velikov wrote:
> Hi all,
> 
> Having gone through the thread a few times, I believe it can be
> summarised as follows:
>  * Greater transparency is needed.
>  * Subsystem/team maintainers.
>  * Unfit and late nominations.
>  * Developers/everyone should be more involved.
>  * Greater automation must be explored.
> 
> 
> NOTES:
>  * Some of the details are not listed in the thread, but have been
>    raised in one form or another.
>  * The details focuses more on the goals, than the actual means.
>  * Above said, some details may have been missed - I'm mere human.
> 
> 
> In detail:
>  * make the patch queue, release date and blockers accessible at any
>    point in time:
>     * queued patches can be accessed, via a branch - say wip/17.3,
>       wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
>       normally reverts are recommended.
> 
>     * rejected patches must be listed alongside the reason why and
>       author+reviewer must be informed (email & IRC?) ASAP.
>        * we already document and track those in .cherry-ignore. can we
>          reuse that?
> 
>     * patches with trivial conflicts can be merged to the wip branch
>       after another release manager, or patch author/reviewer has
>       confirmed the changes.

I would change this to follow a more similar to current one: patches with
trivial conflicts can be merged to the wip branch; author/reviewer will be
notified asap about the new commit, that can be reviewed and, if required,
requested to be modified/removed.


This way, as trivial conflicts happen quite a few times, and indeed they are
"trivial", we can enqueue them as we do not. The difference is that we warn the
author quite soon, instead of waiting for the pre-announcement.

> 
>     * patches that require backports will be rejected. usual rejection
>       procedure applies (described above).
> 
>     * if there is delay due to extra testing time or otherwise, the
>       release manager must list the blocking issues and ETA must be
>       provided. ETA must be updated before it's reached. it may be
>       worth having the ETA and rejections in a single place - inside
>       the wip/ branch, html page, elsewhere.
> 
>     * the current metabug with release blockers must be made more
>       obvious.
> 
>     * release manager can contact Phoronix and/or similar media to
>       publicise expected delays, blockers or seek request for testing.
> 
> 
>  * teams are encouraged to have one or multiple maintainers. some of
>    the goals of having such people include:
>     * individuals that have greater interaction with the team and
>       knowledge about the team plans. rough examples include:
>        * backport/bug is needed, yet person is not available - on a
>          leave (sick, sabbatical, other) or busy with other things.
>        * team has higher priority with details not publicly available.
> 
>     * can approve unfit or late nominations - see next section.
>     * to ensure cover and minimise stress it's encouraged to have
>       multiple maintainers per team and they are rotated regularly.
>     * list of maintainers must be documented
> 
> 
>  * unfit and late nominations:
>     * any rejections that are unfit based on the existing criteria can
>       be merged as long as:
>        * subsystem specific patches are approved by the team
>          maintainer(s).
>        * patches that cover multiple subsystems are approved by 50%+1
>          of the maintainers of the affected subsystems.
> 
>     * late nominations can be made after the pre-release announcement.
>       they must be approved by the subsystem maintainers up-to X hours
>       before the actual release. approval specifics are identical to the
>       ones listed in 'unfit' section just above.
> 
> 
>  * developers/everyone should be more involved:
>     * with the patch queue accessible at any point, everyone is
>       encouraged to keep an eye open and report issues.
> 
>     * developers should be more active in providing backports and
>       updating the status of release blocking bugs.
> 
>     * release managers and team maintainers must check with developer
>       (via email, IRC, other) if no action has been made for X days.
> 
>     * everyone is encouraged to provide a piglit/dEQP/etc testing
>       summary (via email, attachment, html page., etc). if they do,
>       please ensure that summary consistently available, regardless if
>       there's any regressions or not. if extra time is needed reply to
>       the list informing release managers
> 
>     * in case of regressions bisection must be provided.
> 
> 
>  * testing - pre and post merge, automation:
> 
>    NOTE: implementation specifics is up-to each team, with goals of:
>    a) results must be accessible reasonably easy
>    b) high level documentation of the setup and contact points are
>       documented
> 
>     * with over 120 developers contributing to mesa, ambiguous patch
>       nominations will always exist.
> 
>     * the obvious ones can be automated, others will be applied manually.
> 
>     * release manager should deploy automation ensuring that all common
>       combinations build correctly. if particular combination is missing
>       interested parties should provide basic information/assistance for
>       setting one up.
> 
>     * release manager will push the wip branch, after ensuring that
>       patches follow the criteria and passes build testing
> 
>     * pre: automated runtime testing can be utilised at a later stage
>       with gitlab. it's does not seem feasible atm.
> 
>     * post: teams can setup piglit/dEQP/etc testing, summary and/or
>       bisection. it should be documented if the testing is triggered on
>       push, polled every so often or otherwise.
> 
> 
> I believe that we all agree on the above. If so the next step is to
> update the documentation and each of us to grab a piece.
> 
> If you have feedback on any point, be that positive or negative, please
> reply only with the hunk you have in mind.
> 
> Thanks
> Emil
>