Ühel kenal päeval, K, 10.05.2017 kell 13:17, kirjutas Michael Jones: > From a non-gentoo developer who seriously looked at joining the > community over the last few years as a new developer, this entire > conversation thread is absurd, and is a wonderful example of why I > decided to not bother.
I agree that it's absurd to even have to have such a thread. But here we are. > If you don't want people to edit the field such that it's usable with > the official package manager of the distribution, then change the > formatting rules for the field! The formatting rules are in place and well documented. https://wiki.gentoo.org/wiki/Stable_request It is clearly not meant for being passed directly to the package manager, when the action will just error due to no relevant keywords yet (you know, what the bug is about), and because it can optionally list a restriction of arches for which a given line is meant for. There is also a fully working parser that generates a proper chunk of text out of it for a given arch (doing all the filtering to list only the packages meant for that arch, guaranteeing = prefix while keeping it on the bug more readable, etc) at https://github.com/kensington/bugbot/blob/master/getatoms.py which everyone else uses to great success, except one single person who insists the format is something else than it is and spams us all with changed that have to get reviewed or reverted by the maintainer (while that change is not meant to happen in the first place after architectures are CCed without going through maintainer) instead of simply adjusting his own alternative scripts. > If you don't want people editing a field, then change the software > such that groups who aren't allowed to edit the field aren't even > capable of editing it! It is getting wrongly edited by a person who is a developer and maintains packages of their own and theoretically should be able to edit it for his own maintained packages STABLEREQ and KEYWORDREQ bugs, and as a developer has editbugs privileges on bugzilla. > Either officially document the expected formatting and permissions, > or put automated enforcement rules into place. Throwing accusations > of wrongdoing around simply because the action in question generates > an email is, again, absurd. The formatting is well documented. The permissions are just like they have always been, and I'm pretty sure this is covered by even the recruitment quizzes. We are not in a position to have the time to teach bugzilla about what developer maintains what, and what bug is about what package, to be able to restrict this on a case by case basis. Having to do that just because a single person doesn't play along is an absurd requirement. > On Wed, May 10, 2017 at 10:45 AM, Kristian Fiskerstrand > <k...@gentoo.org> wrote: > > On 05/10/2017 05:33 PM, David Seifert wrote: > > > On Wed, 2017-05-10 at 18:22 +0300, Mart Raudsepp wrote: > > > He doesn't stop: https://bugs.gentoo.org/show_bug.cgi?id=617694 > > > Please drop editbugs privileges for some time. Everyone agrees > > that > > > this maintainer-specific metadata is not to be touched. > > > > > > > I've actually spent some time looking into this and haven't > > actually > > found any authoritative documentation that makes it maintainer- > > specific, > > so I welcome some references to documentation that it is. I'm sorry that you can't find something written down that is extremely common sense, and has always been like this. Do you remember a non-maintainer going and attaching a new stabilization list to a stabilization bug? Do you remember a non- maintainer overriding a stabilization list given in a bug comment in a way that architecture teams would actually consider this as what is to be used, when manual finding of the correct list was needed from comments? This is nothing different, it's just easier to find and parse via scripts. Stabilization and keywording lists are the responsibility of the relevant maintainers, not that of a single architecture. An architecture team member may do something extra on their own responsibility, but not change the list for all the other architectures. Or force a re-review by the maintainers because you have a different idea than everyone else (including the feature author) what is correct format to have in it, or think some extra package is needed without consulting the relevant maintainers and just add it to an already ongoing stabilization bug (which gets handled by scripts by others without noticing this change was done without authorization). Something being easier (downloading previous attachment, changing it and re-attaching is harder) doesn't mean the rules suddenly changed. > > There is the bug wrangler project page, but that is project- > > specific and > > not global. https://wiki.gentoo.org/wiki/Stable_request has been mentioned before and discussed enough. I also wrote this thread before as a reminder, which everyone agreed to, except the one person that is stubborn and has different ideas. Because of that, someone ELSE has to do the work to stop one persons misguided stubbornness to break the workflow for everyone else. Sorry, but that is not OK. This new field and so on is an actual effort towards a better workflow. The thing the working group you are leading was supposed to analyze and come up with. This field is getting abused by a developer. I first kindly asked to stop it, but it hasn't, so I ask for some sort of action towards avoiding this field meant to help being made useless due to unauthorized edits. > > Although it is certainly a good practice that maintainer acks > > stabilizations; other projects routinely files stabilization > > requests, > > in particular the security project. And the security project doesn't change the stabilization list after it has been ACKed by maintainer via CC'ing architecture teams, unlike what we are talking about here. They usually don't even fill the stabilization package list. It is not a good practice to get an ACK for stabilization. It is a soft requirement, unless maintainer timeout happens. https://devmanual.gentoo.org/ebuild-maintenance/index.html#stabilizing-ebuilds "The maintainer of the package should always be contacted just in case there are reasons not to do so.", etc
