[gentoo-dev] Re: Making systemd more accessible to "normal" users

[Duncan]

Daniel Campbell posted on Mon, 20 May 2013 22:03:02 -0500 as excerpted:

> [100-200 systemd unit files is] missing the point.
> If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.
> 
> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing.

But the point you're missing is that INSTALL_MASK is NOT a hack.  It's a 
specifically designed part of the whole gentoo support of choice system 
you mention, designed precisely to allow users a supported method of 
vetoing specific files on their system, should they wish to do so.

Which is what the council decision effectively said as well.  Gentoo 
already has tools designed to allow users to veto specific files should 
they choose to do so, so putting individual files under control of a USE 
flag is an over-engineered hassle, both to the users who find they have 
to remerge an entire package, often rebuilding from source, just to get a 
trivial sized file that would have otherwise been there, and that wasn't 
doing any harm in any case, and to the devs who end up maintaining these 
USE flags for trivial files, when there's already a perfectly usable 
solution specifically designed to give users who want to veto specific 
files on their systems the ability to do so.

You're at once claiming that gentoo's about choice, and disparaging one 
of the tools specifically designed to aid in giving you that choice.  
Just use the tool for the precise purpose it's designed for, and quit 
worrying about it.


FWIW, all this said as a user who's still very much personally in the 
openrc camp, and in fact chooses to use /another/ such tool, 
package.keywords, to keyword-unmask openrc- **, so I can run the live-
git version and follow commits and git logs individually, the better to 
trace problems down to the source as soon as they appear. =:^)

In fact, I use many such tools, package.keywords and package.umask as 
well as layman overlays to run testing and live-git versions of various 
packages, the portage/profile subdir to negate all packages that would 
otherwise appear in my @system so it's entirely empty (helps portage make 
better use of its parallel build capacities, among other things),
/etc/portage/sets/* and /var/lib/portage/world_sets support to categorize 
all packages formerly listed in world into sets, so my world file is 
empty as well, and yes, INSTALL_MASK and PKG_INSTALL_MASK, to veto most 
*.la files among other things, along with individual /etc/portage/env/* 
files to setup individual package exceptions to that general *.la veto, 
where necessary.

If these tools, all part of the gentoo's about choice value you mention, 
are hacks, then gentoo itself is a hack, and if you don't like it, you 
better find yourself a distribution that relies less on such "hacks".  
No, these are NOT "hacks", they're specific features specifically 
engineered to make specific bits of that "gentoo's about choice" thing 
work, in fact giving individual site/installation admins that very choice.

Us the tools for what they're designed for, and the problem disappears.
Both openrc users wishing to veto system support files and systemd users 
wishing to veto openrc files get to do just that, using a tool precisely 
designed to allow them to veto such files should they decide the want 
to.  So where's the problem?  It's gone!  Vanished due to use of a tool 
exactly as it was intended to be used! =:^)

(All that said, if Zac saw fit to add a nounits feature to the already 
existing nodoc/noinfo/noman features, I doubt anyone would object.  Like 
them, the feature would be simplified but redundant method of doing what 
INSTALL_MASK already makes possible, but simplified /is/ perhaps the key 
word here.  Has anyone so strongly objecting to using INSTALL_MASK as it 
was intended to be used proposed such a patch?  You'd have to ask Zac if 
he'd consider taking it, but given the precedent set by the other no* 
features, there's certainly hope.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users

[Canek Peláez Valdés]

On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell  wrote:
> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge  wrote:
>>> J. Roeleveld wrote:
 I don't see how this will avoid the issue of a limited amount of
 inodes.
 That is what I usually run out of before the disk is full when
 storing lots of smaller files.
>>>
>>> I guess the number of unit files is on the order of hundreds
>>
>> (Sorry, sent email before it was ready).
>>
>> Laptop running full GNOME:
>>
>> # find /usr/lib/systemd/system -type f | wc
>> 154 1547012
>>
>> Server running Apache+MySQL+Mailman+Squid+Other services:
>>
>> # find /usr/lib/systemd/system -type f | wc
>> 121 1215560
>>
>> And as you said, you can always use INSTALL_MASK. If 154 files are
>> going to deplete your inodes, I think your problem lies somewhere
>> else.
>>
>> Regards.
>> --
>> Canek Peláez Valdés
>> Posgrado en Ciencia e Ingeniería de la Computación
>> Universidad Nacional Autónoma de México
>>
>
> That's missing the point. If you don't run systemd, having unit files is
> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
> like a hack instead of something more robust. Why include systemd unit
> files (by default, with no systemd USE flag, thanks to the council...)
> on a system that's not using it? 154 files isn't negligible unless
> you're flippant with your system and don't care about bloat. Unused
> software sitting around *is* a waste of disk-space.

Unit files are not software; they are data.

And I believe you are the one missing the point. I don't run OpenRC; I
don't need no files in /etc/init.d. But you don't see me (nor any
other systemd user) complaining about pointless scripts in
/etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
life.

Non-systemd users should do the same for files under /usr/lib/systemd,
if they really are that worried about systemd "infecting" their
systems. Complaining about a council-decided policy (and, I believe,
backed up by the developers that matter, including the OpenRC
maintainers) is just beating on a dead horse.

Get over it.

> Some people (like myself) came to Gentoo to avoid putting systemd on
> their systems and to make use of the great choice that Gentoo allows.
> This push to make systemd a "first level citizen" or whatever reeks of
> marketing.

If Gentoo is about choice, then systemd is one of those choices. And
systemd will become a first class citizen inside Gentoo, like it or
not. Support for it has been getting better and better, and more and
more Gentoo users are running with systemd.

If  some fundamentalists users don't want even one file in their
systems with "systemd" on their paths, they can install eudev/mdev,
put the necessary directories in INSTALL_MASK, and do the extra work.
If some other fundamentalists users (like myself) don't want even one
OpenRC related file on our systems, we can create an overlay to remove
the dependency of baselayout on OpenRC, put /etc/init.d in
INSTALL_MASK, and do the extra work.

Neither case covers the average systemd/OpenRC user, who doesn't care
about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
just want to run her machine with the init system of her choice. If
Gentoo is really about choice.

> If there is desire among users for unit files, they can
> contact upstream or maintain their own set of unit files. It's not like
> they're hard to write.

So, Gentoo is about choice, but only for the choices you agree with. Great.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users

[Daniel Campbell]

On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge  wrote:
>> J. Roeleveld wrote:
>>> I don't see how this will avoid the issue of a limited amount of
>>> inodes.
>>> That is what I usually run out of before the disk is full when
>>> storing lots of smaller files.
>>
>> I guess the number of unit files is on the order of hundreds
> 
> (Sorry, sent email before it was ready).
> 
> Laptop running full GNOME:
> 
> # find /usr/lib/systemd/system -type f | wc
> 154 1547012
> 
> Server running Apache+MySQL+Mailman+Squid+Other services:
> 
> # find /usr/lib/systemd/system -type f | wc
> 121 1215560
> 
> And as you said, you can always use INSTALL_MASK. If 154 files are
> going to deplete your inodes, I think your problem lies somewhere
> else.
> 
> Regards.
> --
> Canek Peláez Valdés
> Posgrado en Ciencia e Ingeniería de la Computación
> Universidad Nacional Autónoma de México
> 

That's missing the point. If you don't run systemd, having unit files is
pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
like a hack instead of something more robust. Why include systemd unit
files (by default, with no systemd USE flag, thanks to the council...)
on a system that's not using it? 154 files isn't negligible unless
you're flippant with your system and don't care about bloat. Unused
software sitting around *is* a waste of disk-space.

Some people (like myself) came to Gentoo to avoid putting systemd on
their systems and to make use of the great choice that Gentoo allows.
This push to make systemd a "first level citizen" or whatever reeks of
marketing. If there is desire among users for unit files, they can
contact upstream or maintain their own set of unit files. It's not like
they're hard to write.

[gentoo-dev] Re: robo-stable bugs

[Duncan]

Rich Freeman posted on Mon, 20 May 2013 13:15:09 -0400 as excerpted:

>> Severity and Priority on the Gentoo Bugzilla have always been weird to
>> me; I would love to hear from someone who is actually using either of
>> those to sort their bugs and using them happily, because the
>> inconsistency applied by different people is making a mess of them.
> 
> I suspect we could just get by with one field.
> 
> Typically at work the severity reflects impact of a bug (the effects it
> has on customers), and the priority reflects management direction on
> what developers should be working on.  Our fields are a bit of a
> mish-mash of both, and of course maintainers can generally ignore or
> work on bugs in any order with little impact on their salary.  It does
> make sense to distinguish between a bug holding up the next gcc release
> (scheduled a week in the future) and adding a desktop entry to a package
> that otherwise works just fine.

As a user, I've understood:

* Severity is something the user/filer can use.

* Priority is strictly for maintainers/teams if they want to use it, NOT 
the user/filer (unless it's a maintainer filed bug).

Thus there's reason to have two separate fields, one that's specifically 
reserved for the maintainer, one for the user, that a maintainer can 
choose to ignore if they decide to.

Even so, if there's no known-approved reason to set severity, a user 
should just leave it alone.  That means users unfamiliar with gentoo's 
bugzilla should just leave it alone.

Here, I only use severity in a few cases, generally the exception rather 
than the rule.  

* If it's an enhancement I mark it as such, and expect maintainer bug 
priority ranked less urgent as a result.  The *.desktop file example 
someone mentioned goes here, as do, arguably, changes such as the md 
initscript improvements I filed some years ago (tho those could equally 
arguably be left as normal by the user and let the maintainer decide, I'd 
certainly not argue a maintainer changing that to/from enhancement).

* If the bug has system-wide or arch-class-wide (all ~arch, for instance) 
implications, I'll sometimes up severity accordingly, with a note in the 
text explaining my reasoning.  Toolchain or base-system bugs that prevent 
normal boot or system upgrade arguably fit here, especially if they're on 
a recently (say a day) unmasked or announced to be unmasked package with 
arch-class-wide implications, where an immediate remask might be 
appropriate until the situation can be resolved.

* Also, arugably many security bugs could get severity-upgraded, altho 
with security handled separately on gentoo, I'd discourage that unless 
again it's something like toolchain or base-system, thus fitting the 
above system-wide condition.


Based on the above, I'd suggest that:

* The priority field should be restricted to devs (if it's not already), 
and that devs who misuse the field on packages they don't maintain be 
treated accordingly.

* The severity field is arguably a candidate for "first gentoo 
privilege", restricted for ordinary users, but with a moderately liberal 
"on-request" policy, for users who have demonstrated consistent 
responsible bug filing, on gentoo bugzy at least, but also those who can 
point to bugs filed elsewhere in the community, package upstream and peer-
distro maintainers, etc.

Of course the "first gentoo privilege" is requisite on the appropriate 
infrastructure being in place to handle it, and would arguably be 
settable by anyone with higher gentoo bugzilla privs.  If implemented, 
constructing an initial whitelist might be in order.  A note in gentoo 
bugzy suggesting that users can request "severity privilege" in any filed 
bug, should they believe they can handle it responsibly, could be 
appropriate as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] robo-stable bugs

[Tom Wijsman]

On Mon, 20 May 2013 18:00:49 +
"Robin H. Johnson"  wrote:

> http://www.gossamer-threads.com/lists/gentoo/dev/173889?do=post_view_threaded
> The thread does mention that atoms should be first, as well.
> It also makes sorting and viewing much easier (all related atoms are
> together).

Thanks.

> > > Also, your script does not set the STABLEREQ keyword. People are
> > > having to hunt down your robo-stabilisation requests and add it
> > > themselves. You should just do it yourself or turn your script
> > > off.
> > Maintainer(s) and arch team member(s) blamed me for setting this. :(
> I think the keyword should be there.
> 
> If anybody else things the keyword should NOT be there, I'd like to
> hear from them here.

From what I heard, this keyword is used to see whether a stabilization
request bug is an actual stabilization request. Adding the keyword
without CC-ing arches clutters the bug list that tracks all stabilazion
request bugs since there would then be bugs that the arches can not
take any action on.

Of course arches use the CC feature for tracking these, but there are
persons tracking the entire list too to pay attention to bugs that have
been forgotten about; or persons whom have access to multiple arches
and are in multiple arch teams may also prefer to use the full list
instead of depending on the individual CC mails.

But that's just my limited view on this, the relevant maintainers and
arch team members that request this can probably shed a better light on
the need for STABLEREQ to only be placed by the maintainer and not by
the reporter or bug wrangler.

> Additionally, there used to be an old webapp where you could select by
> dev/herd and see how many days every package with that dev/herd had
> been in ~arch for all given arches. Something like that easily usable
> would be handy again, as a stop-gap to automatic stabilization.

We have `iamlate` for this in app-portage/gentoolkit-dev.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] robo-stable bugs

[Tom Wijsman]

On Mon, 20 May 2013 13:15:09 -0400
Rich Freeman  wrote:

> Tend to agree, but rather than focusing on figuring out who messed
> up/etc, let's just move forward.

The link would be handy to refer to when we need to educate future
people; but anyhow, someone else responded something relevant just now.

Regarding who, it's not a single person; the majority of bugs that
_aren't_ automatically filed show this problem, multiple people do so.

Nobody did bad, there's just a lack of communication *from both sides*.

> Short of making an automated bug reporting policy I'm not sure how to
> better document things.  I agree that it is easy to miss stuff in list
> archives.  Bottom line is people shouldn't take this stuff personally
> - just improve and move on.

Yeah, imho, bots and scripts that run mass actions against anything in
the Gentoo infrastructure should be reviewed or be made according to
such policy. I haven't seen a review of the last mass actions being,
and I don't think they are implemented according to certain standards.

Some thoughts:

- Rate limiting.

- Skim the list the script applies to for exceptions.

- Run a small enough subset as a test before running the entire thing.

> >
> > Severity and Priority on the Gentoo Bugzilla have always been weird
> > to me; I would love to hear from someone who is actually using
> > either of those to sort their bugs and using them happily, because
> > the inconsistency applied by different people is making a mess of
> > them.
> 
> I suspect we could just get by with one field.

Probably, how would such field work? One field being just priority?

> But, since we're not getting paid it really is more of a
> communication/organization tool.  At work when we mark bugs high we
> expect them to get fixed, since the devs are paid to work on what we
> want them to work on, and if that means leaving the blocker alone
> while making the splash screen look prettier that's management's
> prerogative.

Yeah, and here at Gentoo the version bumps are attractive; until there
are no more version bumps to do, then we often just pick a random bug
where we should probably pick one of the more important ones.

> If we do want to have two fields, then the one should be more of a
> factual statement (is it an improvement, something that makes the
> package unusable for some users, a regression, something that makes
> the package unusable for all users, removal of a blocker, etc -
> roughly in increasing severity), and the other a true priority (H/M/L
> - which is at the discretion of the maintainer, but perhaps set
> initially based on guidelines in order to help them out).

Yes, bringing more meaning into them is what would be nice to see.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] robo-stable bugs

[Robin H. Johnson]

On Mon, May 20, 2013 at 05:29:43PM +0200, Tom Wijsman wrote:
> > " stabilisation request"
> This is missing a reference URL or at least the ML thread subject; last
> time I asked, I didn't got either and wasn't able to find this in a
> reasonable amount of time. I find some irrelevant policy discussions
> but nothing that indicates the order in the summary.
http://www.gossamer-threads.com/lists/gentoo/dev/173889?do=post_view_threaded
The thread does mention that atoms should be first, as well.
It also makes sorting and viewing much easier (all related atoms are
together).

> Severity and Priority on the Gentoo Bugzilla have always been weird to
> me; I would love to hear from someone who is actually using either of
> those to sort their bugs and using them happily, because the
> inconsistency applied by different people is making a mess of them.
It would be nice if these could be better documented.

'enhancement' gets the most use from me for oldnet/openrc feature
requests.

> > Also, your script does not set the STABLEREQ keyword. People are
> > having to hunt down your robo-stabilisation requests and add it
> > themselves. You should just do it yourself or turn your script off.
> Maintainer(s) and arch team member(s) blamed me for setting this. :(
I think the keyword should be there.

If anybody else things the keyword should NOT be there, I'd like to hear
from them here.

Additionally, there used to be an old webapp where you could select by
dev/herd and see how many days every package with that dev/herd had been
in ~arch for all given arches. Something like that easily usable would
be handy again, as a stop-gap to automatic stabilization.


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] robo-stable bugs

[Rich Freeman]

On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman  wrote:
> This is missing a reference URL or at least the ML thread subject; last
> time I asked, I didn't got either and wasn't able to find this in a
> reasonable amount of time. I find some irrelevant policy discussions
> but nothing that indicates the order in the summary.

Tend to agree, but rather than focusing on figuring out who messed
up/etc, let's just move forward.  The proposed placement of PVs at the
start of the subject line makes logical sense, so we might as well do
it.

Short of making an automated bug reporting policy I'm not sure how to
better document things.  I agree that it is easy to miss stuff in list
archives.  Bottom line is people shouldn't take this stuff personally
- just improve and move on.

>
> Severity and Priority on the Gentoo Bugzilla have always been weird to
> me; I would love to hear from someone who is actually using either of
> those to sort their bugs and using them happily, because the
> inconsistency applied by different people is making a mess of them.

I suspect we could just get by with one field.

Typically at work the severity reflects impact of a bug (the effects
it has on customers), and the priority reflects management direction
on what developers should be working on.  Our fields are a bit of a
mish-mash of both, and of course maintainers can generally ignore or
work on bugs in any order with little impact on their salary.  It does
make sense to distinguish between a bug holding up the next gcc
release (scheduled a week in the future) and adding a desktop entry to
a package that otherwise works just fine.

But, since we're not getting paid it really is more of a
communication/organization tool.  At work when we mark bugs high we
expect them to get fixed, since the devs are paid to work on what we
want them to work on, and if that means leaving the blocker alone
while making the splash screen look prettier that's management's
prerogative.

If we do want to have two fields, then the one should be more of a
factual statement (is it an improvement, something that makes the
package unusable for some users, a regression, something that makes
the package unusable for all users, removal of a blocker, etc -
roughly in increasing severity), and the other a true priority (H/M/L
- which is at the discretion of the maintainer, but perhaps set
initially based on guidelines in order to help them out).

Rich

Re: [gentoo-dev] robo-stable bugs

[Paweł Hajdan, Jr.]

On 5/20/13 5:10 AM, Gilles Dartiguelongue wrote:
> That would explain why you're still filling gnome stabilization bugs
> while we replied many times we don't want them in their current form ?

If you're still getting bugs from my script it's a bug in my script,
sorry about that. Could you post the most recent example of such a bug?

The script applies exclusion list into account since

(Feb 2013) and gnome is part of the exclusion list since

(Aug 2012).

> This generally needs to go first so sorting by summary shows your
> packages in order and you have a chance to see this part of the summary
> in bugzilla (with version optionally), the rest of the summary line is
> imho less important when working through the web interface.

This makes sense. I'll post an update when I make this simple change to
the script.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] robo-stable bugs

[Tom Wijsman]

On Sun, 19 May 2013 15:40:27 +0200
Jeroen Roovers  wrote:

> Private messages and public comments through bugzilla are so far
> ignored, it seems, so let's try a venue where it's sure to cause a
> flamewar instead. My apologies for the inconvenience.

Since you are the BW lead, I have followed your suggestion and done so 
since; but as I stated last time, there's no indication for others to
follow this as far I can see. Maybe there is, then please show us.

> On Sat, 18 May 2013 21:08:53 +
> bugzilla-dae...@gentoo.org wrote:
> 
> > DO NOT REPLY TO THIS EMAIL. Also, do not reply via email to the
> > person whose email is mentioned below. To comment on this bug,
> > please visit: https://bugs.gentoo.org/show_bug.cgi?id=470392
> > 
> > Bug ID: 470392
> >Summary: Please stabilize =dev-libs/libconfig-1.4.9-r1
> 
> We agreed a little while ago that bug Summaries should start with an
> atom, if possible, and explain the action later. Also, robotically
> filing thousands of bugs and making them say "please" every time isn't
> going to endear anyone to your cause. So do something like this:
> 
> " stabilisation request"
> 

This is missing a reference URL or at least the ML thread subject; last
time I asked, I didn't got either and wasn't able to find this in a
reasonable amount of time. I find some irrelevant policy discussions
but nothing that indicates the order in the summary.

There are some developers that tend to point to history this way, they
don't take into account how though it can be to search these threads if
you don't use the wrong keywords to find the wrong subject.

In 5 years from now, I don't think anyone is going to find "robo-stable
bugs" searching for "please stabilize", "bug summary order" or any other
thing along those lines.

I could read the whole history, but that keeps me from contributing.

> >URL:
> > http://packages.gentoo.org/package/dev-libs/libconfig? arches=linux
> 
> Is this URL useful to include, or did you just want to abuse every
> last feature found in pybugz? Wouldn't maintainers already know where
> to find this kind of information? Who do you think is your audience?

+1

> >   Severity: enhancement
> 
> Is a stabilisation an enhancement per se? If all stabilisations are
> enhancements, then why isn't Severity set to Normal instead? (What is
> an enhanced severity to begin with, Mozilla?)
> 
> >   Priority: Normal
> 
> This is where you probably wanted to set something similar to
> Enhancement above, but again you probably shouldn't. Normal
> stabilisation bugs are normal, not less than normal.

Severity and Priority on the Gentoo Bugzilla have always been weird to
me; I would love to hear from someone who is actually using either of
those to sort their bugs and using them happily, because the
inconsistency applied by different people is making a mess of them.

The only case where I see them as useful is when people raise them to
a higher priority for bugs that are really more important than the
average bug, it makes them stand out in their list.

We should standardize these in a way we don't have to memorize what
they mean for every different type of bug, as that's the only way it is
really going to make these fields make much more sense than something
we tend to normalize and forget about. Why are bugs that block users
from being able to use the package given a "normal" priority?

> > Is it OK to stabilize =dev-libs/libconfig-1.4.9-r1 ?
> > 
> > If so, please CC all arches which have stable keywords
> > 
> > for older versions of this package and add STABLEREQ keyword
> > 
> > to the bug.
> 
> My e-mail editor is messing up the line endings here, but your
> messages already include double newlines - on bugzilla web pages as
> well as in the e-mail it sends, so this is your broken pybugz script
> again, I reckon?

That's so we can print the bug mail and write notes in between. =)

> Also, your script does not set the STABLEREQ keyword. People are
> having to hunt down your robo-stabilisation requests and add it
> themselves. You should just do it yourself or turn your script off.

Maintainer(s) and arch team member(s) blamed me for setting this. :(

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

Re: [gentoo-dev] robo-stable bugs

[Gilles Dartiguelongue]

Le dimanche 19 mai 2013 à 17:00 -0700, "Paweł Hajdan, Jr." a écrit :
> On 5/19/13 6:40 AM, Jeroen Roovers wrote:
> > Private messages and public comments through bugzilla are so far 
> > ignored, it seems, so let's try a venue where it's sure to cause a 
> > flamewar instead. My apologies for the inconvenience.
> 
> Hey Jeroen, apologies if I have ignored any of your feedback.
> 
> I'm indeed behind on bugmail (5000 unread emails, how about that?).

That would explain why you're still filling gnome stabilization bugs
while we replied many times we don't want them in their current form ?

> 
> I do read mailing list traffic and direct e-mail though.
> 
> > We agreed a little while ago that bug Summaries should start with an 
> > atom, if possible, and explain the action later.
> 
> Could you refer me to the part where "we agreed" and why? I'm actually
> happy to make changes that are useful for people, but without a good
> rationale and an _actual_ consensus someone else will inevitably come
> and says he likes the old way better.
> 

This was discussed on the mailing list a couple of times. Last big
thread related to this was automatic bug assignment iirc.

This generally needs to go first so sorting by summary shows your
packages in order and you have a chance to see this part of the summary
in bugzilla (with version optionally), the rest of the summary line is
imho less important when working through the web interface.

> Remember this is supposed to _help_ Gentoo. You can opt out of the bugs
> (there is a package name and maintainer name regex in the script). You
> don't need to "hunt them down" - if you do nothing another script will
> just CC arches after 30 days.

I'll repeat gnome team position here:

We do not want automated stabilization requests.

We handle so many packages that having individual bug reports is driving
arch teams and us crazy.

We have our own set of scripts to do batch stabilization bug reports.
They were designed with arch teams so that it does not generate too much
load on them.

-- 
Gilles Dartiguelongue 
Gentoo