Emil Velikov <emil.l.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
