Re: [gentoo-dev] Bugzilla package list editing

[Mart Raudsepp]

Ü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_f@g.o> 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