[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements
Mark Janes
mark.a.janes at intel.com
Wed Apr 4 17:07:50 UTC 2018
Emil Velikov <emil.l.velikov at gmail.com> writes:
> 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.
I created a bot that applies commits from master to wip stable branches
and tests in CI. It runs several times a day and identifies patches
that do not cherry-pick cleanly. Branches are here:
https://github.com/janesma/mesa/tree/wip/17.3
https://github.com/janesma/mesa/tree/wip/18.0
I've sent a couple of mails to developers when their recent patches
don't apply. So far it handles about 85% of the commits containing
stable tags without intervention.
> * 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.
>
> * 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
More information about the mesa-dev
mailing list