FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-24-2010, 10:41 PM
"Robin H. Johnson"
 
Default metadata.xml:

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
 
Old 02-25-2010, 05:22 AM
Ulrich Mueller
 
Default metadata.xml:

>>>>> 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
 
Old 02-25-2010, 12:41 PM
Markos Chandras
 
Default metadata.xml:

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
 
Old 02-25-2010, 01:17 PM
Ulrich Mueller
 
Default metadata.xml:

>>>>> 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
 
Old 02-25-2010, 04:01 PM
Angelo Arrifano
 
Default metadata.xml:

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
 
Old 02-25-2010, 05:44 PM
Vlastimil Babka
 
Default metadata.xml:

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
 
Old 02-25-2010, 07:42 PM
Fabian Groffen
 
Default metadata.xml:

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
 
Old 02-25-2010, 07:53 PM
Sebastian Pipping
 
Default metadata.xml:

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
 
Old 02-26-2010, 03:40 PM
Alec Warner
 
Default metadata.xml:

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
>
>
 
Old 03-01-2010, 06:39 AM
Markos Chandras
 
Default metadata.xml:

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
 

Thread Tools




All times are GMT. The time now is 03:59 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org