[gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

Hi all,

From what I've read on the list recently, there's a lot of demand for
non-maintainer updates to ebuilds. Esp. with the upcoming Git migration,
I predict there will be a much larger influx of changes from users.

Some developers (eg myself) have a general policy [2] that we send out
to the list occasionally welcome everybody to touch our packages (so
long as they own their breakages). A few packages discouraged touching
due to fragility, but mostly we were a very open society.

Back in the days of "The Old Ones", this was a general practice for all
developers, but somewhere along the line, some developers seem to have
grown territorial of their ebuilds.

Debian has their own NMU process:
http://wiki.debian.org/NonMaintainerUpload
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
With a long whitelist of devs/teams that welcome it:
http://wiki.debian.org/LowThresholdNmu

So I'd like to hear input on how developers & users (esp
proxy-maintainers) on maybe writing a NMU GLEP.

I'm open to all input, but here's some initial questions I'd like to
hear your answers to:
- How should developers, herds & teams communicate how welcome they are
  to NMU changes on their packages?
  - to humans?
  - to automated scripts?
  - where? metadata.xml?
- What sorts of changes (see Debian NMU):
  - Are welcome?
  - Are prohibited?
  - Are somewhere between the two?
  - Does this need to be controlled per-package?
  - What about upstream-rejected changes?
- How do we encourage responsible ownership of changes that cause
  breakage? [1]

1. I've been leading infra for a few years now, and I've got a few
ground rules, maybe we can run with parts of those:
- If you break something, own up ASAP; there will be no punishment, just
  help in getting it fixed.
- You're responsible for many people's systems/access/privacy, don't
  abuse it.
(Ciaranm: since you were talking about lack of honesty of corporate
cultures in response to my previous mail, here's your chance again).

2. This isn't entirely selfless, I want to have to tell people less that
they can go and touch most of my packages WITHOUT asking me or waiting
for me to reply to a bug.

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Alexis Ballier]

Hi,

> I'm open to all input, but here's some initial questions I'd like to
> hear your answers to:
> - How should developers, herds & teams communicate how welcome they
> are to NMU changes on their packages?

The way I've been doing this is:
- packages I maintain through herd -> go ahead and be responsible.
- if I add myself explicitly in metadata.xml this means I prefer at
  least reviewing every change that gets in (with some exceptions for
  trivial changes, like e.g. qt moving category)

[...]
> - How do we encourage responsible ownership of changes that cause
>   breakage? [1]

That's something I'd like to get enlightened on. The, probably too
emotional, algorithm that doesn't scale I've been applying has been:

1. ask the committer to fix the problem
2. wait
3. if no fix comes in a timely manner, fix it myself, be clear that I've
  not liked it at all. Be a bit less polite in future steps 1. with
  said developer.

Alexis.

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

On Fri, Jun 21, 2013 at 03:04:11PM -0400, Alexis Ballier wrote:
> > - How should developers, herds & teams communicate how welcome they
> > are to NMU changes on their packages?
> The way I've been doing this is:
> - packages I maintain through herd -> go ahead and be responsible.
> - if I add myself explicitly in metadata.xml this means I prefer at
>   least reviewing every change that gets in (with some exceptions for
>   trivial changes, like e.g. qt moving category)
That's fine for packages in a herd, but doesn't scale, and doesn't
handle packages without a herd.

> > - How do we encourage responsible ownership of changes that cause
> >   breakage? [1]
> That's something I'd like to get enlightened on. The, probably too
> emotional, algorithm that doesn't scale I've been applying has been:
Your portion is also if you are the one that found it. You might not be
the person that finds it.

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Alexis Ballier]

On Fri, 21 Jun 2013 19:07:48 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> > > - How do we encourage responsible ownership of changes that cause
> > >   breakage? [1]
> > That's something I'd like to get enlightened on. The, probably too
> > emotional, algorithm that doesn't scale I've been applying has been:
> Your portion is also if you are the one that found it. You might not
> be the person that finds it.

in that case it'll get reported and I'll know it anyway

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Michael Weber]

On 06/21/2013 08:50 PM, Robin H. Johnson wrote:
[NMU]

Abstract: Be verbose about your preferences.

== TL;DR ==

I'm missing this kind of information since the beginning.
After 2 (?) years, i've learned some policies, like herd:desktop-* is
free for all, don't touch herd:base-system and so on. But I did not keep
records of every fella granting me full access.


As a maintainer and slacker (as flameeyes pointed out), I singularily
maintain my share of packages [1] with a rich variety of affection.

Less/singular affection (like the miredo/sbin/ip mishap, a package i
proxied for a friend), I work on rand maintainer-needed@g.o packages,
don't take maint and try to watch bugzie for follow ups.
-> just go ahead and do what you think is right

Total, regular affection, (cwm, ncdc, ncdu, mupdf (+derivates), llpp,
netsurf, jumanji) and basically my inital commits.
-> give me at least two days to review changes.

Either way, go ahead, BUT I __really__ like being informed about an NMU
carried out, nothing sucks more than doing the update and see
repoman+cvs reject the update (yeah, work on an fresh checkout blah blah).

As an impatient person with an urge to fix things, I often commit on
random stuff, after asking or timeout. I'd like to propose three
positions to post information about NMU-policy, preferred way of
communication, affection to bulk-mail|reports|...|euscan update|KEQWORDREQ

- Every dev as person, like an devaway.
- Every herd, somwhere in herds.xml
- Every Package-category (for project-categories like vim/kde/gnome/)
(it'd be usefull to fetch and provide this info as equery meta output).

(Yes, I've broken and will break things, my sincerest apologies, I
really try hard. Thanks for ssuominen being a encouraging example.)

At some point I'm really scared about reactions in the past and avoid
certain areas, persons and really basic|widespread stuff like zsh (bug
19924, [2]).

my 2 cents.

[1] http://euscan.iksaif.net/maintainers/48/
[2] https://bugs.gentoo.org/show_bug.cgi?id=19924

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Michael Weber]

On 06/21/2013 10:31 PM, Michael Weber wrote:
> On 06/21/2013 08:50 PM, Robin H. Johnson wrote:
> [NMU]

Forgot to mention, ChangeLog

metadata.xml is nice to have, but often dated.

ChangeLog carries a good source of information
 - frequency of commits by maintainer
 - history of non-maint-commits (real ones, not the pack/slot-move ones).

Should be checked by bug wranglers, to cross-check for errors resulting
from non-maint commits (slackers will not reassign to the person
responsible) and other eager people to exchange thoughts and maybe
forming a herd.

[as proxy-maint and general gateway for user patches, I've grown a
certain confidence to throw things into the wild - and standing the
consequences. QA: I've really learned to appreciate you slapping me.]

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1526 bytes --]

On Friday 21 June 2013 14:50:54 Robin H. Johnson wrote:
> From what I've read on the list recently, there's a lot of demand for
> non-maintainer updates to ebuilds. Esp. with the upcoming Git migration,
> I predict there will be a much larger influx of changes from users.

seems like we're somewhat approaching it the wrong way around.  our tooling 
sucks -- bugzilla is not the proper medium for gating ebuild contributions.  
something like gerrit would make things flow a lot more smoothly imo.  i've 
been doing more workflow along the lines of:
 - dev/user posts patch to bugzilla
 - click "edit attachment as comment"
 - do patch review like a standard mailing list
 - dev/user posts updated patch
 - for a dev, i'll usually finish with "feel free to commit".  for a user, i'll 
commit it at some point (same for devs if i happen to be digging around).

if i do the commit, it's a pita:
 - ssh to a system that has commit access (assuming i'm in a location where 
this is possible, otherwise it'll have to wait)
 - open up the bug in a browser
 - find & download the attached patch
 - apply it and sort out any conflicts
 - run `repoman commit`
 - update the bug

with gerrit and git, this process could be turned into me clicking "submit" in 
the web interface (gerrit also has a ssh command line interface for doing 
things).  would be easy to add a `repoman upload` that'd take care of making 
the commit, regenerating things (Manifest/etc...), and then uploading it to 
gerrit.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

On Fri, Jun 21, 2013 at 07:40:03PM -0400, Mike Frysinger wrote:
> On Friday 21 June 2013 14:50:54 Robin H. Johnson wrote:
> > From what I've read on the list recently, there's a lot of demand for
> > non-maintainer updates to ebuilds. Esp. with the upcoming Git migration,
> > I predict there will be a much larger influx of changes from users.
> seems like we're somewhat approaching it the wrong way around. 
[Snip giant suggestions re gerrit/review-systems]

I'm not going into review systems here at all, I'm simply trying to have
a policy of what changes are welcomed/blocked WITHOUT interaction from
the listed maintainer(s) of a given package/herd.

If they have to ask me to review a trivial patch, I've already failed
them. I don't want ANY gatekeeping, I want them to go and commit it
already.

Then extending THAT to Gerrit, who is responsible/allowed to hit that
web interface submit button? I don't want it to have to be me either for
most of my packages. If some developer reviews a trivial change (either
by another dev or a user) and thinks it's ok, then it should probably go
in the tree. Why does it need to involve me at all, other than I'm the
listed maintainer for the package.

If it's some major patch or a big feature addition, then it probably
needs more serious eyeballs (eg complex patches to qmail [very fragile],
unix socket patch to openssh [rejected upstream]).

I think both NMU & Gerrit need to happen (as well as 'git pull' of
changes from users).

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1316 bytes --]

On Friday 21 June 2013 20:06:31 Robin H. Johnson wrote:
> On Fri, Jun 21, 2013 at 07:40:03PM -0400, Mike Frysinger wrote:
> > On Friday 21 June 2013 14:50:54 Robin H. Johnson wrote:
> > > From what I've read on the list recently, there's a lot of demand for
> > > non-maintainer updates to ebuilds. Esp. with the upcoming Git
> > > migration, I predict there will be a much larger influx of changes
> > > from users.
> > 
> > seems like we're somewhat approaching it the wrong way around.
> 
> [Snip giant suggestions re gerrit/review-systems]
> 
> I'm not going into review systems here at all, I'm simply trying to have
> a policy of what changes are welcomed/blocked WITHOUT interaction from
> the listed maintainer(s) of a given package/herd.

add a new field to metadata.xml that declares the state.  make it an enum:
	ANYTHING_GOES	(the default)
	REQUIRES_HERD
	REQUIRES_MAINTAINER

> If they have to ask me to review a trivial patch, I've already failed
> them. I don't want ANY gatekeeping, I want them to go and commit it
> already.
> 
> Then extending THAT to Gerrit, who is responsible/allowed to hit that
> web interface submit button?

have gerrit check metadata.xml and see if the policy declared in there lines 
up with the gerrit approvals attained.  blam, done.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
> > I'm not going into review systems here at all, I'm simply trying to have
> > a policy of what changes are welcomed/blocked WITHOUT interaction from
> > the listed maintainer(s) of a given package/herd.
> add a new field to metadata.xml that declares the state.  make it an enum:
> 	ANYTHING_GOES	(the default)
> 	REQUIRES_HERD
> 	REQUIRES_MAINTAINER
I wish it was that easy.

Despite being ANYTHING_GOES on most of my packages, I don't want people
to add giant features like qmail patchbombs; so we need to figure out
something like the Debian NMU listing of what's acceptable.

Does this need to be coded in the metadata?
Does a version bump count as an acceptable trivial change?

> > If they have to ask me to review a trivial patch, I've already failed
> > them. I don't want ANY gatekeeping, I want them to go and commit it
> > already.
> > 
> > Then extending THAT to Gerrit, who is responsible/allowed to hit that
> > web interface submit button?
> have gerrit check metadata.xml and see if the policy declared in there lines 
> up with the gerrit approvals attained.  blam, done.
That's why we need the policies on who/what first.

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1059 bytes --]

On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
> On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
> > > I'm not going into review systems here at all, I'm simply trying to
> > > have a policy of what changes are welcomed/blocked WITHOUT interaction
> > > from the listed maintainer(s) of a given package/herd.
> > 
> > add a new field to metadata.xml that declares the state.  make it an enum:
> > 	ANYTHING_GOES	(the default)
> > 	REQUIRES_HERD
> > 	REQUIRES_MAINTAINER
> 
> I wish it was that easy.
> 
> Despite being ANYTHING_GOES on most of my packages, I don't want people
> to add giant features like qmail patchbombs; so we need to figure out
> something like the Debian NMU listing of what's acceptable.

the maintainers intent has to be machine codable

> Does this need to be coded in the metadata?

yes.  we already have maintainer info in there, and putting it anywhere else 
is doomed to failure.

> Does a version bump count as an acceptable trivial change?

that's up to the maintainer
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Fri, 21 Jun 2013 15:04:11 -0400
Alexis Ballier <aballier@gentoo.org> wrote:

> > I'm open to all input, but here's some initial questions I'd like to
> > hear your answers to:
> > - How should developers, herds & teams communicate how welcome they
> > are to NMU changes on their packages?
> 
> The way I've been doing this is:
> - packages I maintain through herd -> go ahead and be responsible.

sys-kernel/gentoo-sources only lists the kernel herd; while I don't
think anyone else is unwelcome, I don't see NMU changes as something
that would happen to it. Since the ebuild could be called optimal,
changes to it would likely make it perform in an unexpected way.

More general, I think there are some packages here that have this kind
of nature; for another instance, the java packages require some
additional knowledge for which Gentoo Developers have to go go through
a quiz. I believe users and proxy maintainers not to be aware of this,
therefore again the changes might sometimes be problematic. 

> - if I add myself explicitly in metadata.xml this means I prefer at
>   least reviewing every change that gets in (with some exceptions for
>   trivial changes, like e.g. qt moving category)

I think this should apply to a herd as well, unless otherwise noted.

> [...]
> > - How do we encourage responsible ownership of changes that cause
> >   breakage? [1]

Since it is listed in the ChangeLog, I think it implies the ownership.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Fri, 21 Jun 2013 22:41:51 +0200
Michael Weber <xmw@gentoo.org> wrote:

> Should be checked by bug wranglers, to cross-check for errors
> resulting from non-maint commits (slackers will not reassign to the
> person responsible) and other eager people to exchange thoughts and
> maybe forming a herd.

If we are going to have to look at the commit patch level, I'm going to
be afraid that bugs will pile up as a result; we could opt to script
showing the last commit messages that happened by non-maintainers
in the last year or so, that would still allows us to deal with it.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
> > On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
> > > > I'm not going into review systems here at all, I'm simply trying to
> > > > have a policy of what changes are welcomed/blocked WITHOUT interaction
> > > > from the listed maintainer(s) of a given package/herd.
> > > 
> > > add a new field to metadata.xml that declares the state.  make it an enum:
> > > 	ANYTHING_GOES	(the default)
> > > 	REQUIRES_HERD
> > > 	REQUIRES_MAINTAINER
> > 
> > I wish it was that easy.
> > 
> > Despite being ANYTHING_GOES on most of my packages, I don't want people
> > to add giant features like qmail patchbombs; so we need to figure out
> > something like the Debian NMU listing of what's acceptable.
> the maintainers intent has to be machine codable
So we have the following facets of NMU permissions:
Who
What

> > Does a version bump count as an acceptable trivial change?
> that's up to the maintainer
This needs to be in the above data:

So we have:
Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}

So most of my packages might be coded with:
<nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
<nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />

- If you're a developer, you can do trivial fixes, add minor features,
  bump the version.
- If you're in the herd, you can add major features.

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/21/2013 09:42 PM, Robin H. Johnson wrote:
> On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
>> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
>>> On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger
>>> wrote:
>>>>> I'm not going into review systems here at all, I'm simply
>>>>> trying to have a policy of what changes are
>>>>> welcomed/blocked WITHOUT interaction from the listed
>>>>> maintainer(s) of a given package/herd.
>>>> 
>>>> add a new field to metadata.xml that declares the state.
>>>> make it an enum: ANYTHING_GOES	(the default) REQUIRES_HERD 
>>>> REQUIRES_MAINTAINER
>>> 
>>> I wish it was that easy.
>>> 
>>> Despite being ANYTHING_GOES on most of my packages, I don't
>>> want people to add giant features like qmail patchbombs; so we
>>> need to figure out something like the Debian NMU listing of
>>> what's acceptable.
>> the maintainers intent has to be machine codable
> So we have the following facets of NMU permissions: Who What
> 
>>> Does a version bump count as an acceptable trivial change?
>> that's up to the maintainer
> This needs to be in the above data:
> 
> So we have: Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD,
> REQUIRES_MAINTAINER} What = {NONE, TRIVIAL, MINOR_FEATURES,
> VERSION_BUMP, MAJOR_FEATURES}
> 
> So most of my packages might be coded with: <nmu-policy
> who="REQUIRES_DEV" what="VERSION_BUMP" /> <nmu-policy
> who="REQUIRES_HERD" what="MAJOR_FEATURES" />
> 
> - If you're a developer, you can do trivial fixes, add minor
> features, bump the version. - If you're in the herd, you can add
> major features.
> 
This is actually pretty sane... I like this idea.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRxRn3AAoJEKXdFCfdEflKS5AP/08vkwpc7k5IxEXKShRNUs2b
1a4WOaFLwWzC3tU1X162qogct/KAUIPCmfe1RlgZs9f8hLDzEUQ9wP50gE46ypP0
lLQj0Kg634G/uDbQFMMjiwaT0YJgxaufoLIMNDlxxxKGLKYAevvcmcHtAYLfpHr7
lakPlf9SEW002HFN3Yo7cO9eO9X6v0qLnaYxMALdm08G+KkadZ/0wlb/GeQGA6Kl
RhRDXX8dPSv54O0PTnmEcq3FgOrT1GtxJ590jLB88eRN/MLspdcXJSZ3nPO/Byw2
RATTpBTMMiOXTLv374TBQ73ggnYXk/TPw4BAHSdW31eaZMDiKOFA/4BxAybZ9UpA
CWfGY+XJaJHZqSXoD/Ngz3dphv9U8BkzK0e6PnPl1Y0v70Ayv0XDmSIstYxfRGdl
6OyUyg8ANvh3vGxJdMGsSAdt2rsMrOas8Yvt4eqb2mOLfJE+oosUiklN7wfAH0+n
JTIJ0TJ9HTUA6Mu6ezIr5i5JJmey1byBN7OIpD6NgQUcfdJzXrK3ap/p6BEt12hb
jVPtVGqilz7raGRtb+GnoVXIUtxYmgbIqv1vx0vZTJbAJI0v6JweBU9oQAViaN9I
mf79M5YciP/ILfFJqc/oWYVabUtvknU3AUzVGf60h6K09IS8JbnIW4rpwaHDFYPE
zNm2wZEkT2Q49NDo6Hx0
=2mTJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Ulrich Mueller]

>>>>> On Sat, 22 Jun 2013, Robin H Johnson wrote:

> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}

> So most of my packages might be coded with:
> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />

> - If you're a developer, you can do trivial fixes, add minor features,
>   bump the version.
> - If you're in the herd, you can add major features.

Shouldn't this be REQUIRES_TEAM instead? A "herd" used to be a
collection of packages, whereas the devs maintaining them were called
a team. Or don't we care about this distinction any more?

http://www.merriam-webster.com/dictionary/herd
a number of animals of one kind kept together under human control

Ulrich

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[hasufell]

On 06/22/2013 03:42 AM, Robin H. Johnson wrote:
> On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
>> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
>>> On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
>>>>> I'm not going into review systems here at all, I'm simply trying to
>>>>> have a policy of what changes are welcomed/blocked WITHOUT interaction
>>>>> from the listed maintainer(s) of a given package/herd.
>>>>
>>>> add a new field to metadata.xml that declares the state.  make it an enum:
>>>> 	ANYTHING_GOES	(the default)
>>>> 	REQUIRES_HERD
>>>> 	REQUIRES_MAINTAINER
>>>
>>> I wish it was that easy.
>>>
>>> Despite being ANYTHING_GOES on most of my packages, I don't want people
>>> to add giant features like qmail patchbombs; so we need to figure out
>>> something like the Debian NMU listing of what's acceptable.
>> the maintainers intent has to be machine codable
> So we have the following facets of NMU permissions:
> Who
> What
> 
>>> Does a version bump count as an acceptable trivial change?
>> that's up to the maintainer
> This needs to be in the above data:
> 
> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
> 
> So most of my packages might be coded with:
> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />
> 
> - If you're a developer, you can do trivial fixes, add minor features,
>   bump the version.
> - If you're in the herd, you can add major features.
> 

Sounds cool.

I don't think we need a GLEP or council vote on that.

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[hasufell]

On 06/22/2013 11:00 AM, Ulrich Mueller wrote:
> http://www.merriam-webster.com/dictionary/herd
> a number of animals of one kind kept together under human control
> 

On that very link:
a group of people usually having a common bond

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Markos Chandras]

On 22 June 2013 02:42, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
>> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
>> > On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
>> > > > I'm not going into review systems here at all, I'm simply trying to
>> > > > have a policy of what changes are welcomed/blocked WITHOUT interaction
>> > > > from the listed maintainer(s) of a given package/herd.
>> > >
>> > > add a new field to metadata.xml that declares the state.  make it an enum:
>> > >   ANYTHING_GOES   (the default)
>> > >   REQUIRES_HERD
>> > >   REQUIRES_MAINTAINER
>> >
>> > I wish it was that easy.
>> >
>> > Despite being ANYTHING_GOES on most of my packages, I don't want people
>> > to add giant features like qmail patchbombs; so we need to figure out
>> > something like the Debian NMU listing of what's acceptable.
>> the maintainers intent has to be machine codable
> So we have the following facets of NMU permissions:
> Who
> What
>
>> > Does a version bump count as an acceptable trivial change?
>> that's up to the maintainer
> This needs to be in the above data:
>
> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
>
> So most of my packages might be coded with:
> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />
>
> - If you're a developer, you can do trivial fixes, add minor features,
>   bump the version.
> - If you're in the herd, you can add major features.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@gentoo.org
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>

This sounds pretty reasonable to me.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[gentoo-dev] Herds (was: Soliciting input for a non-maintainer update (NMU) GLEP)

[Ulrich Mueller]

>>>>> On Sat, 22 Jun 2013, hasufell  wrote:

>> http://www.merriam-webster.com/dictionary/herd
>> a number of animals of one kind kept together under human control

> On that very link:
> a group of people usually having a common bond

That's a figurative meaning derived from the first one, but it doesn't
make sense here. The metaphor is that the herd consists of a set of
packages that are shepherded by their maintainers.

Ulrich

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Ulrich Mueller]

>>>>> I wrote:

>>>>> On Sat, 22 Jun 2013, Robin H Johnson wrote:
>> So we have:
>> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
>> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}

>> So most of my packages might be coded with:
>> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
>> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />

>> - If you're a developer, you can do trivial fixes, add minor features,
>>   bump the version.
>> - If you're in the herd, you can add major features.

> Shouldn't this be REQUIRES_TEAM instead? A "herd" used to be a
> collection of packages, whereas the devs maintaining them were
> called a team. Or don't we care about this distinction any more?

Getting back on topic: Apart from this minor issue, I think that your
proposal is quite reasonable.

Ulrich

Re: [gentoo-dev] Herds

[hasufell]

On 06/22/2013 11:38 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 22 Jun 2013, hasufell  wrote:
> 
>>> http://www.merriam-webster.com/dictionary/herd
>>> a number of animals of one kind kept together under human control
> 
>> On that very link:
>> a group of people usually having a common bond
> 
> That's a figurative meaning derived from the first one, but it doesn't
> make sense here. The metaphor is that the herd consists of a set of
> packages that are shepherded by their maintainers.
> 

It makes perfect sense here, because it describes a group of people (the
herd members) who have a common bond (expertise in that area).

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Pacho Ramos]

El sáb, 22-06-2013 a las 00:06 +0000, Robin H. Johnson escribió:
[...]
> I'm not going into review systems here at all, I'm simply trying to have
> a policy of what changes are welcomed/blocked WITHOUT interaction from
> the listed maintainer(s) of a given package/herd.
[...]

In my case I would like to be always notified a change has been
committed (even forwarding gentoo-commits message to me), that will help
me to keep track of the committed changes, and learn more if they
corrected a bug caused by me ;)

Regarding what other can commit or not... I think a general good policy
would be to:
1. If package is not hardly broken -> report a bug to maintainer with a
1 week timeout. If he/she doesn't reply, go ahead.
2. If package is nonfunctional -> go ahead and fix it as soon as
possible!
 

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Sat, 22 Jun 2013 01:42:13 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD,
> REQUIRES_MAINTAINER} What = {NONE, TRIVIAL, MINOR_FEATURES,
> VERSION_BUMP, MAJOR_FEATURES}

Why is there a NONE in What? Shouldn't it be NONE by default or do we
want NONE to mean that we explicitly don't want it? That is, how does
NONE differ from when the policy is missing?
 
> So most of my packages might be coded with:
> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />
> 
> - If you're a developer, you can do trivial fixes, add minor features,
>   bump the version.
> - If you're in the herd, you can add major features.

Is there always a strict order in the What entries? For instance, what
if someone wants people to do version bumps but not do minor features?
How would you specify that in this syntax?

Thank you in advance for clarifying.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Michael Weber]

On 06/22/2013 11:01 AM, hasufell wrote:
> On 06/22/2013 03:42 AM, Robin H. Johnson wrote:
>> On Fri, Jun 21, 2013 at 09:06:30PM -0400, Mike Frysinger wrote:
>>> On Friday 21 June 2013 20:26:03 Robin H. Johnson wrote:
>>>> On Fri, Jun 21, 2013 at 08:17:38PM -0400, Mike Frysinger wrote:
>>>>>> I'm not going into review systems here at all, I'm simply trying to
>>>>>> have a policy of what changes are welcomed/blocked WITHOUT interaction
>>>>>> from the listed maintainer(s) of a given package/herd.
>>>>>
>>>>> add a new field to metadata.xml that declares the state.  make it an enum:
>>>>> 	ANYTHING_GOES	(the default)
should reflect the circle of entities to do the change ... ANYBODY? Just
to not confuse it with an type of change.
>>>>> 	REQUIRES_HERD
>>>>> 	REQUIRES_MAINTAINER
>>>>
>> So we have:
>> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
>> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
>>
>> So most of my packages might be coded with:
>> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
>> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />
>>
>> - If you're a developer, you can do trivial fixes, add minor features,
>>   bump the version.
>> - If you're in the herd, you can add major features.
>>
> 
> Sounds cool.
> 
> I don't think we need a GLEP or council vote on that.
ack.

But in every single metadata? Can I get a script for my 160 personal
edits, pls?

And what's a sane default?
Let's take a amount to time (~2month) for responsive people to mark
their preferences and default to EVERTHING_GOES/ANYBODY.

And we lost the timeout dimension. An "Feel free to bump my stuff"
override in devaway works for single maintained packages, how to
interpret these data for teams and multiple maints? AWOL people...

Bottom line: I think we need more of a culture of mutual trust than a
ton of metadata.

- Respect the right of an maintainer to take a few days until responding
(except QA, security, major skrew ups),
- Honor the effort other people put into packages you don't care to much.
- Take a look at the package/ebuild complexity to estimate the
maintainers affection.
- Ask for an second opinion aka peer-review.

(And yes I've failed at every single point at least once).

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Rich Freeman]

On Sat, Jun 22, 2013 at 6:20 AM, Michael Weber <xmw@gentoo.org> wrote:
> Bottom line: I think we need more of a culture of mutual trust than a
> ton of metadata.
>

I have to agree with this.  The culture should be that we're doing
this work FOR GENTOO.  Sure, we're getting benefits out of it as well
so it should be a win/win, but we're all in this together.

I do think there is some metadata that would be useful.  Rather than
capturing a "keep out" flag, perhaps it would make more sense to
capture more "factual" information, like a comment for humans to read,
and maybe a status for scripts.  This shouldn't be about who is and
isn't allowed to touch things, but rather WHY somebody might think
twice about touching things.

For example, many system packages should get the white glove treatment
because they're, well, system packages.  I'd like to think that even
the greenest of recruits would appreciate that glibc isn't the best
package in the world to experiment on, but a script might not catch
that.

Useful and informative comments to humans might be useful as well.
For example, I might mark my package as "do-not-stabilize" for the
scripts and add a comment "game client interfaces with external game
server that changes API without warning and requires instant updates."

Anybody running scripts on the tree should be careful from the start -
perhaps we should even require pre-announcement on -dev.  Manual
changes are less of a risk, especially if there is warning.

All that said, I'm not opposed to there being some kind of flag.
However, I think we need to set the expectation that this is about
helping us all to collaborate better, and not about putting up
razorwire.

Rich

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Rich Freeman]

On Sat, Jun 22, 2013 at 5:00 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Shouldn't this be REQUIRES_TEAM instead? A "herd" used to be a
> collection of packages, whereas the devs maintaining them were called
> a team. Or don't we care about this distinction any more?

Certainly when I was recruited this distinction was made.  In recent
years it seems to have gone away.  I'm not going to nitpick on terms
because the present system mostly works.

The original definitions was that groups of packages are herds, and
groups of people are projects.  The fact that nobody seems to actually
formalize their projects (create page, elect leads, etc) probably
contributes to conflating the two.  Plus, it really isn't that much of
a value-add to clone the namespace/etc.  Willikins thinks of people as
part of herds as well.

Rich

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Sat, 22 Jun 2013 12:20:22 +0200
Michael Weber <xmw@gentoo.org> wrote:

> But in every single metadata? Can I get a script for my 160 personal
> edits, pls?

You can find your metadata files with 

`grep -r --include 'metadata.xml' \>xmw@gentoo.org\< /usr/portage -l`

See "Inserting Content using sed" [1] on how to insert content after a
specific line, if you pass the above grep output through xargs you
should be able to easily adjust all the files. If you intent to do
more careful, then feel free to state so

 [1]: http://devmanual.gentoo.org/tools-reference/sed/

> And what's a sane default?

Asked this is my sub thread. Let's see before drawing conclusions.

> Let's take a amount to time (~2month) for responsive people to mark
> their preferences and default to EVERTHING_GOES/ANYBODY.

It may be reasonable for this to go before the council to avoid us from
taking a rushed decision that results in inconsistent metadata across
the tree; whatever happens, a big share of people should agree on the
matter and this should be properly and unambiguously documented.

> And we lost the timeout dimension. An "Feel free to bump my stuff"
> override in devaway works for single maintained packages, how to
> interpret these data for teams and multiple maints? AWOL people...

If there are multiple maintainers, there would be no need for random
developers to take care of the package; the rules in the file would
therefore still apply. Note the "my stuff" part of this, which means
this is not really about the packages of teams and multiple maints.

> Bottom line: I think we need more of a culture of mutual trust than a
> ton of metadata.

Yes, I think of this approach to be somewhat like to my optional files
metadata approach; though it introduces less metadata, and tries to
deal with a slightly different matter, but we should still be careful.

> - Respect the right of an maintainer to take a few days until
> responding (except QA, security, major skrew ups)

I assume you meant committing instead of responding, this is already
covered by the dev manual (do not commit unless you never got response).

> - Take a look at the package/ebuild complexity to estimate the
> maintainers affection.

Add eclasses to that, they can contain some tricky magic which might
not be directly clear from the ebuild.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Soliciting input for a non-maintainer update (NMU) GLEP

[Michael Palimaka]

On 22/06/2013 11:42, Robin H. Johnson wrote:
> This needs to be in the above data:
>
> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
>
> So most of my packages might be coded with:
> <nmu-policy who="REQUIRES_DEV" what="VERSION_BUMP" />
> <nmu-policy who="REQUIRES_HERD" what="MAJOR_FEATURES" />
>
> - If you're a developer, you can do trivial fixes, add minor features,
>    bump the version.
> - If you're in the herd, you can add major features.
>

It might be useful to have the capability for a free-form 
comment/instructions too. For example, we do all of our development in 
an overlay, and on occasion we lose changes that someone else has made 
in the tree because they don't know they need to be applied in two places.

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[hasufell]

On 06/22/2013 03:42 AM, Robin H. Johnson wrote:
> 
> So we have:
> Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
> 

While looking at it... what means TRIVIAL? Trivial change, trivial bug?

In my understanding it should cover fixing build-time issues which can
be pretty non-trivial, no?

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Robin H. Johnson]

On Sat, Jun 22, 2013 at 05:13:01PM +0200, hasufell wrote:
> On 06/22/2013 03:42 AM, Robin H. Johnson wrote:
> > 
> > So we have:
> > Who = {ANYTHING_GOES, REQUIRES_DEV, REQUIRES_HERD, REQUIRES_MAINTAINER}
> > What = {NONE, TRIVIAL, MINOR_FEATURES, VERSION_BUMP, MAJOR_FEATURES}
> While looking at it... what means TRIVIAL? Trivial change, trivial bug?
> 
> In my understanding it should cover fixing build-time issues which can
> be pretty non-trivial, no?
The Debian NMU pages I linked in the original posting give good examples
about trivial, but yes, this needs to be defined in the GLEP.

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

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 518 bytes --]

On Saturday 22 June 2013 06:20:22 Michael Weber wrote:
> But in every single metadata? Can I get a script for my 160 personal
> edits, pls?

that's why the default is "do it".  if you don't trust other people to do it, 
then yes, you get pain in having to maintain all your metadata.xml files with 
your preferences.

if your concern is that a package requires special care (make sure you do XYZ 
before bumping), then that's a different issue.  a comment at the top of the 
ebuild seems sufficient.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/22/2013 06:11 AM, Pacho Ramos wrote:
> El sáb, 22-06-2013 a las 00:06 +0000, Robin H. Johnson escribió:
> [...]
>> I'm not going into review systems here at all, I'm simply trying to have
>> a policy of what changes are welcomed/blocked WITHOUT interaction from
>> the listed maintainer(s) of a given package/herd.
> [...]
> 
> In my case I would like to be always notified a change has been
> committed (even forwarding gentoo-commits message to me), that will help
> me to keep track of the committed changes, and learn more if they
> corrected a bug caused by me ;)

I have myself on the gentoo-commits ML and then I filter out so that
just changes to my packages make it to me.  You could further filter so
that just changes to your packages where you are not the commiter make
it to you...  There is ample information in the headers of the ML to do
this kind of thing.

Thanks,
Zero
> 
> Regarding what other can commit or not... I think a general good policy
> would be to:
> 1. If package is not hardly broken -> report a bug to maintainer with a
> 1 week timeout. If he/she doesn't reply, go ahead.
> 2. If package is nonfunctional -> go ahead and fix it as soon as
> possible!
>  
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRxmTwAAoJEKXdFCfdEflKRDgQAIri9eHC2/TQOlqPF7FaD4KU
wsAjR1b93uXt5XaXyFfZA3n4eGeWYD8nh2kTId4+XGoAUjCA5fyYT4R2nlvDpfvw
luNvf5o7nLVmrLDkui95tNd8ZI6Msn8OJVw26eOic+dkVgu8XSVB/BPJEqsP2c9b
e3Rw3nNycOf0Za6/RTR11kobigTKYNcPGh+TCsjpcnB9VVFBT/0Ehyi5+aRoqRiM
bQ83hofgbFGJYvGyDlquLh8D2fd8KQxEjojleStzZtNgCR0O2r1egOu+M9GRaWXF
aI+S5YoOSAR1BCwJN2zN8HYSBTUUXXwsU71s4Z8k+7DN/E1Ot61zyIDK6zcL5Jej
0r8LhBE3J+oP2KLJ3hDIc8WgsxnFqK90dVi2kbAj+0tuKps6hBauZiGYZnDme6LV
mqWQhacQpp//G2wjwDpe+4Z+nBsg31iO6MNg/n78ieUqirlw45HWnXjHp/tdW2qU
krdwmOuL99jAWdAjtGY8Ck8lr1a6OBxIhOVQOm5R9QbQoCAPBrxtEzJH6SC9OODi
anho7zl4NE26SkkgvX/S6K88p6qnTmPR7g70dfTDm/OTuXUNWEI81XbcKjso+Pmi
d+iDKOVEmL3btu0rRAriz7bA/bNiM4emHs3bnezUFc2fBlGsKvQSJdWUzac+jo3f
yYDkATk2Y2Sli8ktiKCR
=EEsb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/23/2013 05:01 AM, Rick "Zero_Chaos" Farina wrote:
> On 06/22/2013 06:11 AM, Pacho Ramos wrote:
>> El sáb, 22-06-2013 a las 00:06 +0000, Robin H. Johnson escribió: 
>> [...]
>>> I'm not going into review systems here at all, I'm simply
>>> trying to have a policy of what changes are welcomed/blocked
>>> WITHOUT interaction from the listed maintainer(s) of a given
>>> package/herd.
>> [...]
> 
>> In my case I would like to be always notified a change has been 
>> committed (even forwarding gentoo-commits message to me), that
>> will help me to keep track of the committed changes, and learn
>> more if they corrected a bug caused by me ;)
> 
> I have myself on the gentoo-commits ML and then I filter out so
> that just changes to my packages make it to me.  You could further
> filter so that just changes to your packages where you are not the
> commiter make it to you...  There is ample information in the
> headers of the ML to do this kind of thing.
> 

There is no meta information on the maintainer of a package (just the
comitter). You'd have to create a filter rule for every single package
afais, unless I'm missing something.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRzIHnAAoJEFpvPKfnPDWz1mwIAK0Ku2fT0Nv0EdvERXv/AIsw
EKnzSCCH01XKEVoP14ujXwD+JZQBKVkqOLICZN0hSUlkmYoUCJAxUtMrMp8dkoOX
+yR4yfa5Gm62CbgxI836T0j644ii0Z6vTdvg7ZLKVWc1/sGF736dm63CsoBRFCaO
Nk163csHShCYFdCUmdLZZGjGn2XYSbyA6hoS5Bjx8NrdaKHM6JDqB5UlcUlNjgQW
cv/OVFWiWeLZZMZzkLeItuZQFEhfLrNpJdZuzoVDiuZZLW1AtIwbWTSW7z1L1HhN
m2dtadw6xT9EoGnUM12gYKvPmiYiiulK/DCH5uJsyWGfA3ejmskGbR1a7ZCXSJM=
=b87U
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Soliciting input for a non-maintainer update (NMU) GLEP

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/27/2013 02:18 PM, hasufell wrote:
> On 06/23/2013 05:01 AM, Rick "Zero_Chaos" Farina wrote:
>> On 06/22/2013 06:11 AM, Pacho Ramos wrote:
>>> El sáb, 22-06-2013 a las 00:06 +0000, Robin H. Johnson
>>> escribió: [...]
>>>> I'm not going into review systems here at all, I'm simply 
>>>> trying to have a policy of what changes are welcomed/blocked 
>>>> WITHOUT interaction from the listed maintainer(s) of a given 
>>>> package/herd.
>>> [...]
> 
>>> In my case I would like to be always notified a change has been
>>>  committed (even forwarding gentoo-commits message to me),
>>> that will help me to keep track of the committed changes, and
>>> learn more if they corrected a bug caused by me ;)
> 
>> I have myself on the gentoo-commits ML and then I filter out so 
>> that just changes to my packages make it to me.  You could
>> further filter so that just changes to your packages where you
>> are not the commiter make it to you...  There is ample
>> information in the headers of the ML to do this kind of thing.
> 
> 
> There is no meta information on the maintainer of a package (just
> the comitter). You'd have to create a filter rule for every single
> package afais, unless I'm missing something.
> 

You are missing nothing, that's what I did.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRzJKLAAoJEKXdFCfdEflKZW8P/22iQ23+KrIubCTWm67llIsB
SYzqnnUQZ85d21neRdq9A1wRrKDFHl2HKSXqavyb5sdO7myZN1jrpZyqYyg2B32O
/cADoO8KJVTk9vziRADX+ahYMMdfsFwkfxEOAY73u8UhhUnyI8uil51hGX0akpAu
tnFw/u5IYSN3tWa6/7bBuA/ZzmmwAB36Sf9qqBQ+F3wFBPDYJVdAiwnGmC6dHljx
D4O/YlLZffOXkU6nHNd8L8T7H0axQCMZeF7QvL6Js/jlclX+pqEsTC66AamOzXTb
bG+aDSWKOlWDU6yf/F7Rq5BBgoa/XV1CAoJubrlALf+2hLmhz2D7cbVf2/6jD7dE
udeaKE2aspYt8t6+oYWEvUG3ePeDjEPvkyKM+KI4V58hsIrRVSi4GkYBYwS7kgeo
Df6N6h++AO52k2x6xiXlBKx2+X6BGUT5p01ZVMLO/YMrJQcjTUyYn691iE1LitL1
xJJ08192LeyIOSoYkUNcQOmGG0nt5wpdz/sBNgNtXJxkM6bQBuLwr+yEZ2eQNuga
2wNPoWKBZGbDASv488DclP7rsilzxYAZypUue2KO7H3qGJeu/DWLOOHUpMiiewln
9xBj0vcKxCh8PEoKg8kVuX7bnj+RTUwEHnewAulcPizqGrYlZqwx6jThS1h6rAq5
0OL8WdxBJLAa2wGgTGNl
=2zi0
-----END PGP SIGNATURE-----