[gentoo-dev] metadata.xml: <changepolicies>

[gentoo-dev] metadata.xml: <changepolicies>

[Robin H. Johnson]

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

I'm forking this thread from -core, so we can have some useful
discussion about the idea, and then somebody can take it to the
gentoo-dev list.

This needs a lot more polishing still, and I'm not happy with some of
the semantics (esp. "policy" is too harsh a word for what we are trying
to convey).

====
Metadata.xml should allow use of a <changepolicies> element. Within the
element, package maintainers should be able to describe how
non-maintainer changes to the package are handled.

The changepolicy element should contain zero or more <change> elements,
each of which present a tuple of the type of change ("type" attribute)
and the policy ("policy" attribute) for that type.

Proposed types:
---------------
- version-bump
- trivial-version-bump
- trivial-fixes
- fixes
- enhancements
- qa-fixes
- trivial-qa-fixes

TODO: I'm not sure what we'd put into some of these type at this point.
One dimension of split would be things that require a revbump vs. those
that don't. trivial-version-bump is probably the easiest one to handle,
simply copying the ebuild with changes to HOMEPAGE/SRC_URI/KEYWORDS.

Proposed policies:
------------------
- file-bug: A bug (ideally with patch) should be filed only.
- review-requested: Discuss the change with a maintainer via ANY means,
  get a +1 for it, and then you can commit it.
- notify: Do the change AND notify the maintainer.
- allowed: Do the change, no notification required.

Proposed defaults:
------------------
TODO: I can see a lot of value in motivating developers by declaring the
defaults for change policies shall be that all types are "notify".

====

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Ulrich Mueller]

>>>>> On Wed, 24 Feb 2010, Robin H Johnson wrote:

> Metadata.xml should allow use of a <changepolicies> element. Within
> the element, package maintainers should be able to describe how
> non-maintainer changes to the package are handled.

Could we allow this element in the category metadata files, too?
Its value there would be the default for the category, with the
possibility to override it for individual packages.

Ulrich

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Markos Chandras]

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

On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote:
> >>>>> On Wed, 24 Feb 2010, Robin H Johnson wrote:
> > Metadata.xml should allow use of a <changepolicies> element. Within
> > the element, package maintainers should be able to describe how
> > non-maintainer changes to the package are handled.
> 
> Could we allow this element in the category metadata files, too?
> Its value there would be the default for the category, with the
> possibility to override it for individual packages.
> 
> Ulrich
How are you so sure that a general "rule" can apply to a whole category? E.g. 
the x11-misc/ one. Which rule for non-maintainer changes are you going to 
apply since every single developer is maintaining a x11-misc application? Same 
for app-misc etc.
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

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

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Ulrich Mueller]

>>>>> On Thu, 25 Feb 2010, Markos Chandras wrote:

>> Could we allow this element in the category metadata files, too?
>> Its value there would be the default for the category, with the
>> possibility to override it for individual packages.

> How are you so sure that a general "rule" can apply to a whole
> category? E.g. the x11-misc/ one. Which rule for non-maintainer
> changes are you going to apply since every single developer is
> maintaining a x11-misc application? Same for app-misc etc.

Of course it would make no sense for the x11-misc category. But we
have categories that mainly consist of packages belonging to one herd,
for example the dev-<language> categories.

Ulrich

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Angelo Arrifano]

On Qui, 2010-02-25 at 15:41 +0200, Markos Chandras wrote:
> On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote:
> > >>>>> On Wed, 24 Feb 2010, Robin H Johnson wrote:
> > > Metadata.xml should allow use of a <changepolicies> element. Within
> > > the element, package maintainers should be able to describe how
> > > non-maintainer changes to the package are handled.
> > 
> > Could we allow this element in the category metadata files, too?
> > Its value there would be the default for the category, with the
> > possibility to override it for individual packages.
> > 
> > Ulrich
> How are you so sure that a general "rule" can apply to a whole category? E.g. 
> the x11-misc/ one. Which rule for non-maintainer changes are you going to 
> apply since every single developer is maintaining a x11-misc application? Same 
> for app-misc etc.

I'm speaking from the GPE herd which have some gpe- categories. IMHO,
this won't be useful to us. I also think it adds unnecessary development
overhead and sounds difficult to maintain in categories with lots of
packages.
-- 
Angelo Arrifano AKA MiKNiX
Gentoo Embedded/OMAP850 Developer
Linwizard Developer
http://www.gentoo.org/~miknix
http://miknix.homelinux.com

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Vlastimil Babka]

On 02/25/2010 02:41 PM, Markos Chandras wrote:
> On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote:
>>>>>>> On Wed, 24 Feb 2010, Robin H Johnson wrote:
>>> Metadata.xml should allow use of a<changepolicies>  element. Within
>>> the element, package maintainers should be able to describe how
>>> non-maintainer changes to the package are handled.
>>
>> Could we allow this element in the category metadata files, too?
>> Its value there would be the default for the category, with the
>> possibility to override it for individual packages.
>>
>> Ulrich
> How are you so sure that a general "rule" can apply to a whole category? E.g.
> the x11-misc/ one. Which rule for non-maintainer changes are you going to
> apply since every single developer is maintaining a x11-misc application? Same
> for app-misc etc.

I think it would make more sense in herds.xml. Not sure about packages 
with more than one herd though :) maybe use the stricter one?
This would definitely need some tool support for simple queries, to be 
usable.

Vlastimil

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Fabian Groffen]

On 24-02-2010 23:41:26 +0000, Robin H. Johnson wrote:
> Proposed types:
> ---------------
> - version-bump
> - trivial-version-bump
> - trivial-fixes
> - fixes
> - enhancements
> - qa-fixes
> - trivial-qa-fixes

Isn't the QA team by its definition allowed to fix QA issues?  If so, I
don't see a point in explicitly allowing qa-fixes of any kind, since
it's implicit for the QA team that is supposed to do this.  For QA its
probably good to get people in the loop anyway, so they learn, instead
of just find their packages fixed in one way or another.

In general it feels like if you really want to allow a very high degree
of modifications to your ebuilds as "maintainer", perhaps it is better
to introduce a special group of ebuilds that have in the best case
someone watching over them every now and then, but are not tied to
"someone".  Almost sounds like "maintainer-needed": looking for someone
who really cares about this package, perhaps even users welcome for
proxy maintenance.

Another thing may be just the "maintainer-timeout" thing, that simply
says that if the maintainer doesn't respond to requests for a
change/update, you are allowed to perform the change.  Normal sanity and
responsibility rules apply of course.  Some bugs just hang around for
even years with multiple devs commenting on them, and the maintainers
just not responding at all.  Seems like in such case a time-out rule
says more than a once written metadata element.

Maybe we just shouldn't try to own something, but rather be the first to
say something about it.  Maybe we should try to identify (groups of)
packages that are way more important than others (think of ... python?)
and mark them as needing special care, treatment and barriers before any
dev would feel like touching them.  Perhaps that would just mean rings
of developer ranks where the inner circle is QA or something?  The more
you are on the outside, the less you are allowed to touch by policy.  As
learning process, making the thin line of the Gentoo quizes too access
all or nothing more fine-grained and hopefully community controlled?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Sebastian Pipping]

Stop.

Is introduction of such a high level of bureaucracy really a good idea?

In my eyes it could backfire and make matters worse as people either
- start ignoring it due to high noise
- reduce people's activity below set permissions

To summarize presented proposal has a few points that may not work well
with humans.  To my understanding we have the assumption in Gentoo that
a Gentoo dev is at least willing to use his brain most of the time.  To
me such a machine only makes sense when assuming the opposite(!)

So I would like to propose a much more loose and simple approach: A
distinction
- between major and minor changes
- need for prior interaction or not

A sensible default may differ from developer to developer.  I propose
collecting these defaults somewhere and make it overridable per
maintainer per package in metadata.xml (just as robbat2 did).

One question to decide would be if access is allowed iff
- no one is objecting or
- everyone is acknowledging
Once all defaults are collected the options are equal, before they are not.

How to best handle herds is not clear to me in detail, yet.
Anyone seing potential in this minimalistic with a natural extension on
herds in mind?



Sebastian

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Alec Warner]

On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> Stop.
>
> Is introduction of such a high level of bureaucracy really a good idea?
>
> In my eyes it could backfire and make matters worse as people either
> - start ignoring it due to high noise
> - reduce people's activity below set permissions
>
> To summarize presented proposal has a few points that may not work well
> with humans.  To my understanding we have the assumption in Gentoo that
> a Gentoo dev is at least willing to use his brain most of the time.  To
> me such a machine only makes sense when assuming the opposite(!)

You mistake the intent I think.  We deploy automation because humans
fail; even when they have the best intentions.  We make typos, copy
and paste errors, accidentally leave whitespace, type commands into
the wrong shell, hit the wrong key that kills our session, etc.  Smart
people avoid work by making a computer do parts that are easily
automated; which is why the proposed system is so fine-grained.  We
can likely add some logic to our current toolset to remind the human
that they may have further obligations than just typing repoman commit
(like asking on a bug, a mailing list, irc, etc.)  With a really
simple system; we cannot easily automate when to do what because the
criteria are so broad.  I agree that a moderately complex system is
useless for humans (I'd ignore it straight out) which is why we should
write software to do the work for us.  I am much more likely to
respond to a message from repoman telling me I need to file a bug
first as opposed to me looking at metadata.xml every time I commit
something.  Sure there are people who never read repoman output and
commit utter crap to the tree; but I do not really expect 100% success
from any system we deploy; I'd be happy with 60% honestly.

>
> So I would like to propose a much more loose and simple approach: A
> distinction
> - between major and minor changes
> - need for prior interaction or not
>
> A sensible default may differ from developer to developer.  I propose
> collecting these defaults somewhere and make it overridable per
> maintainer per package in metadata.xml (just as robbat2 did).
>
> One question to decide would be if access is allowed iff
> - no one is objecting or
> - everyone is acknowledging
> Once all defaults are collected the options are equal, before they are not.
>
> How to best handle herds is not clear to me in detail, yet.
> Anyone seing potential in this minimalistic with a natural extension on
> herds in mind?
>
>
>
> Sebastian
>
>

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Markos Chandras]

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

On Friday 26 February 2010 18:40:47 Alec Warner wrote:
> On Thu, Feb 25, 2010 at 12:53 PM, Sebastian Pipping <sping@gentoo.org> 
wrote:
> > Stop.
> > 
> > Is introduction of such a high level of bureaucracy really a good idea?
> > 
> > In my eyes it could backfire and make matters worse as people either
> > - start ignoring it due to high noise
> > - reduce people's activity below set permissions
> > 
> > To summarize presented proposal has a few points that may not work well
> > with humans.  To my understanding we have the assumption in Gentoo that
> > a Gentoo dev is at least willing to use his brain most of the time.  To
> > me such a machine only makes sense when assuming the opposite(!)
> 
> You mistake the intent I think.  We deploy automation because humans
> fail; even when they have the best intentions.  We make typos, copy
> and paste errors, accidentally leave whitespace, type commands into
> the wrong shell, hit the wrong key that kills our session, etc.  Smart
> people avoid work by making a computer do parts that are easily
> automated; which is why the proposed system is so fine-grained.  We
> can likely add some logic to our current toolset to remind the human
> that they may have further obligations than just typing repoman commit
> (like asking on a bug, a mailing list, irc, etc.)  With a really
> simple system; we cannot easily automate when to do what because the
> criteria are so broad.  I agree that a moderately complex system is
> useless for humans (I'd ignore it straight out) which is why we should
> write software to do the work for us.  I am much more likely to
> respond to a message from repoman telling me I need to file a bug
> first as opposed to me looking at metadata.xml every time I commit
> something.  Sure there are people who never read repoman output and
> commit utter crap to the tree; but I do not really expect 100% success
> from any system we deploy; I'd be happy with 60% honestly.
> 
> > So I would like to propose a much more loose and simple approach: A
> > distinction
> > - between major and minor changes
> > - need for prior interaction or not
> > 
> > A sensible default may differ from developer to developer.  I propose
> > collecting these defaults somewhere and make it overridable per
> > maintainer per package in metadata.xml (just as robbat2 did).
> > 
> > One question to decide would be if access is allowed iff
> > - no one is objecting or
> > - everyone is acknowledging
> > Once all defaults are collected the options are equal, before they are
> > not.
> > 
> > How to best handle herds is not clear to me in detail, yet.
> > Anyone seing potential in this minimalistic with a natural extension on
> > herds in mind?
> > 
> > 
> > 
> > Sebastian
In my eyes, we don't need a smarter repoman to check whether we are supposed 
or not to do a specific commit. What we need are rules ( stricter or not ) 
which DO apply to all developers, and a team ( devrel ) which will be 
responsible to do that. Repoman will not help the situation but it will add a 
new level of complexity into our already complex "communication" system. 
We need an active devrel team which will postpone commit access to those 
developers who are repeatedly fail to behave correctly whatever that means.

That said, i am totally again messing with metadata.xml as long as there 
problem resides in a much higher level
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

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

Re: [gentoo-dev] metadata.xml: <changepolicies>

[Jorge Manuel B. S. Vicetto]

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

On 01-03-2010 06:39, Markos Chandras wrote:
> On Friday 26 February 2010 18:40:47 Alec Warner wrote:
>> You mistake the intent I think.  We deploy automation because humans
>> fail; even when they have the best intentions.  We make typos, copy
>> and paste errors, accidentally leave whitespace, type commands into
>> the wrong shell, hit the wrong key that kills our session, etc.  Smart
>> people avoid work by making a computer do parts that are easily
>> automated; which is why the proposed system is so fine-grained.  We
>> can likely add some logic to our current toolset to remind the human
>> that they may have further obligations than just typing repoman commit
>> (like asking on a bug, a mailing list, irc, etc.)  With a really
>> simple system; we cannot easily automate when to do what because the
>> criteria are so broad.  I agree that a moderately complex system is
>> useless for humans (I'd ignore it straight out) which is why we should
>> write software to do the work for us.  I am much more likely to
>> respond to a message from repoman telling me I need to file a bug
>> first as opposed to me looking at metadata.xml every time I commit
>> something.  Sure there are people who never read repoman output and
>> commit utter crap to the tree; but I do not really expect 100% success
>> from any system we deploy; I'd be happy with 60% honestly.
>>
> In my eyes, we don't need a smarter repoman to check whether we are supposed 
> or not to do a specific commit. What we need are rules ( stricter or not ) 
> which DO apply to all developers, and a team ( devrel ) which will be 
> responsible to do that. Repoman will not help the situation but it will add a 
> new level of complexity into our already complex "communication" system. 
> We need an active devrel team which will postpone commit access to those 
> developers who are repeatedly fail to behave correctly whatever that means.
> 
> That said, i am totally again messing with metadata.xml as long as there 
> problem resides in a much higher level

Markos,

the job of Developer Relations is not to act as a "repo police". What
you're talking about is mostly a QA issue.
Whenever Developers, in particular maintainers for a package, feel
someone ignored or broke policy and report that to Developer Relations,
than it will get into the team's radar. However, Developer Relations is
not and will not grep the commits ml to find "offenders".

PS - As Alec suggested, automated tools that help identify and report
issues are a good idea. In the least, when someone ignores a rule
repoted by repoman, you can be sure it wasn't a distraction, but a
conscious decision to ignore its output.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJLi7U1AAoJEC8ZTXQF1qEPJHEP/3eZp8fFoqdcgNJJVDHS6Xa3
YXKUYthkEzZZQhtfPgQdRh4pYqFwrc+d+uq1CoRLECLOuhNk0m+wu+jN7UByJGQp
wSlZMFxHuvI410oHhGTkNH7Mes9BBGKF3hYRyyd5og7qCseo3S6BTvJSdvV1QbH9
l1W3inag56ZjwCMWDjr2Z/iqhiym6lPBI7ShEz13SYffOKWrbMErDqIDi/JbIb4a
N7YKhTUEqsfYkVZbO42uj0wVWGR+mz0lAwJozh0jLvTtLLQc3xcr74SlsRno18k6
922JXxatbDQdsL3xDY4rxWUKlF2q/HDNLdKx4LLEIyr+oOH1V6Jaf9ygWlfhjQGQ
6KV6yQSvRcDhIGg4PLirfzXswFqxjfVc1jtc1JEHRjSFsWxAfZ4FNNk7w+XHo0Cx
5oPV5yNKCnYfOmq2BLyVQI8VALQ0dnv3OW3Hg1nGv0ILcrM6g35cvmPNqgyZXDid
5ut6u86U+JSFhq2geeCaIBqaZbOpWy8wJ7zIZ7MjMx9CzYpSHF4olAVy0JY+sQe7
NjNy1BM+gENqlFezltQGDaHwA1A/xNsaH0c8P0Zlc7QeoNQw/KQn7n5EpsWr+RR6
8c/mOQAruyA3BsWD2g+NOU64+Yo7NuGUAo94broIVBNf5wWbynC1pPFU7r3g0055
d385QdXsv8MlvosRkWck
=tXdy
-----END PGP SIGNATURE-----