[RFC] Removing MAINTAINER field from recipes

[RFC] Removing MAINTAINER field from recipes

[Koen Kooi]

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

Hi,

After some discussion about the actual meaning of the MAINTAINER field in OE we have
formulated a proposal:

  'All MAINTAINER fields will be removed from the recipes in org.openembedded.dev, and
will only be valid in a distro config file'

We have a number of reasons for doing this:

 * A lot of the MAINTAINER fields are stale
 * Not all people listed in the MAINTAINER fields (want to) have commit access
 * People have blindly copied recipes without contacting the respective MAINTAINER
 * Certain MAINTAINER only care about supporting their $DISTRO
 * The SCM (monotone) holds all the information about who added the recipes and who edited
them.

For monotone-challenged people and tarball snapshots we will add a file into the metadata
that will like names, contact information and interested areas, for example:

- ---

Koen Kooi <koen@openembedded.org>

	* abiword, abiword-plugins
	* angstrom distro and task files
	* h2200, hx4700, efika, ep93xx, netbook-pro machines

Michael 'mickeyl' Lauer <mickeyl@openembedded.org>

	* everything python related
- ---

You can view the patch implementing said proposal at
http://www.openembedded.org/~koen/OE/remove-maintainers.patch

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFKW6PMkyGM64RGpERAk25AJ0bzxc8HfJSvZxLGklgMm6Ewy9CggCfU1jp
z+tRO3+ZMjepQ3oXPUKRGs4=
=Ar2h
-----END PGP SIGNATURE-----

Re: [RFC] Removing MAINTAINER field from recipes

[Graeme Gregory]

I shall start by saying that I do not like this proposal.

>  * A lot of the MAINTAINER fields are stale
Not a reason to nuke fields of files where they are not stale.

>  * Not all people listed in the MAINTAINER fields (want to) have commit access
Then there should be a policy of only having a MAINTAINER field with
your email address if you are an oe developer.

>  * People have blindly copied recipes without contacting the respective MAINTAINER
This is due to the above staleness and peoples lack of commit status.

>  * Certain MAINTAINER only care about supporting their $DISTRO
Then they should no claim MAINTAINER of generic packages.

>  * The SCM (monotone) holds all the information about who added the recipes and who edited
> them.
> 
Not normally in a nice easy to read manner.

All the packages that I am listed as maintainer on I actively try and
maintain and improve the quality of. I would like people to feel they
can contact me to moan and complain about their lack of workingness on
their machine or distro of choice. I can then try and work with the
distro maintainers to get a fix into the generic .dev and then pushed
out into the distro that needs it.

I feel rather than nuking the MAINTAINER field which I feel is a useful
peice of information. That it would be more productive to come up with a
set of policies governing peoples MAINTAINERSHIP. I cant see debian for
example dropping all package maintainers overnight.

Maybe for example for people who dont want OE access but want to fix up
software we start some form of sponsorship where an OE dev with an
interest in that package can list as MAINTAINER but pass out bugs etc to
the actual MAINTAINER.

Thanks

Graeme

List of packages as like original proposers.

kismet, links. dillo, mplayer, sulpheed, sylpheed-claws, gqview, fbpanel
tightvnc, epdfview, xmms-tremor, xmms-mad

Re: [RFC] Removing MAINTAINER field from recipes

[Richard Purdie]

On Sun, 2006-10-08 at 23:33 +0200, Koen Kooi wrote:
> After some discussion about the actual meaning of the MAINTAINER field in OE we have
> formulated a proposal:
> 
>   'All MAINTAINER fields will be removed from the recipes in org.openembedded.dev, and
> will only be valid in a distro config file'
> 
> We have a number of reasons for doing this:
> 
>  * A lot of the MAINTAINER fields are stale
>  * Not all people listed in the MAINTAINER fields (want to) have commit access
>  * People have blindly copied recipes without contacting the respective MAINTAINER
>  * Certain MAINTAINER only care about supporting their $DISTRO
>  * The SCM (monotone) holds all the information about who added the recipes and who edited
> them.

What is missing here is the proposed alternative. The idea we discussed
was having a Maintainers file, similar in spirit to that in the Linux
kernel where people can detail areas they're interested in and give some
kind of indication of the type of support they want to give.

For example, in the case of linux-openzaurus-*, I'd consider that I
actively maintain that, and I'd like to be consulted on changes to those
files.

This removes all kinds of policy issues such as "when I copy a .bb file
to a new version, who is the maintainer"? 

It also means when someone creates a branch, be it openzaurus, poky or
something else, they don't have to go through and remove all the
MAINTAINERS. The obvious concern there is .dev maintainers getting mail
about some branch they have no control over and don't want bug reports
about. Changing a single maintainers file is much easier than patching
every .bb file.

MAINTAINER would still exists but would become a distro variable so
distros would still use it to set the maintainer of distributed packages
but since this is usually a distro contact, setting it in a distro.conf
file shouldn't be a problem (and it can be overridden on a per package
basis MAINTAINER_pn-linux-opnzaurus = "").

The format of the maintainers file is yet to be determined and proposals
are welcome. So far the requirements are something simple and consistent
in an easily parsed format (both human and computer parsed). We need to
list a contact, the packages covered and the level of interactivity of
the maintainer (we need a list of these levels?).


By creating this new file, we get the overhaul of the MAINTAINERS we
need and it solves a lot of existing policy issues which we can't solve
with the existing structure so personally, I'm very much in favour of
it.

Regards,

Richard
 

Re: [RFC] Removing MAINTAINER field from recipes

[Graeme Gregory]

> What is missing here is the proposed alternative. The idea we discussed
> was having a Maintainers file, similar in spirit to that in the Linux
> kernel where people can detail areas they're interested in and give some
> kind of indication of the type of support they want to give.
> 
> For example, in the case of linux-openzaurus-*, I'd consider that I
> actively maintain that, and I'd like to be consulted on changes to those
> files.
> 
This I like as a proposal. For example my listing would be the packages
that I actively maintain now plus a generic entry about audio/video.

> This removes all kinds of policy issues such as "when I copy a .bb file
> to a new version, who is the maintainer"? 
> 
That does neatly fix that problem, as long as people dont take it for an
excuse not to communicate.

> The format of the maintainers file is yet to be determined and proposals
> are welcome. So far the requirements are something simple and consistent
> in an easily parsed format (both human and computer parsed). We need to
> list a contact, the packages covered and the level of interactivity of
> the maintainer (we need a list of these levels?).
> 
> 
> By creating this new file, we get the overhaul of the MAINTAINERS we
> need and it solves a lot of existing policy issues which we can't solve
> with the existing structure so personally, I'm very much in favour of
> it.
> 
I second this proposal, it covers the issues I raised with my earlier
email and gives still a point of contact which I like.

Graeme

Re: [RFC] Removing MAINTAINER field from recipes

[pHilipp Zabel]

On 10/9/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Sun, 2006-10-08 at 23:33 +0200, Koen Kooi wrote:
> > After some discussion about the actual meaning of the MAINTAINER field in OE we have
> > formulated a proposal:
> >
> >   'All MAINTAINER fields will be removed from the recipes in org.openembedded.dev, and
> > will only be valid in a distro config file'
> >
> > We have a number of reasons for doing this:
> >
> >  * A lot of the MAINTAINER fields are stale
> >  * Not all people listed in the MAINTAINER fields (want to) have commit access
> >  * People have blindly copied recipes without contacting the respective MAINTAINER
> >  * Certain MAINTAINER only care about supporting their $DISTRO
> >  * The SCM (monotone) holds all the information about who added the recipes and who edited
> > them.
>
> What is missing here is the proposed alternative. The idea we discussed
> was having a Maintainers file, similar in spirit to that in the Linux
> kernel where people can detail areas they're interested in and give some
> kind of indication of the type of support they want to give.
>
> For example, in the case of linux-openzaurus-*, I'd consider that I
> actively maintain that, and I'd like to be consulted on changes to those
> files.
>
> This removes all kinds of policy issues such as "when I copy a .bb file
> to a new version, who is the maintainer"?
>
> It also means when someone creates a branch, be it openzaurus, poky or
> something else, they don't have to go through and remove all the
> MAINTAINERS. The obvious concern there is .dev maintainers getting mail
> about some branch they have no control over and don't want bug reports
> about. Changing a single maintainers file is much easier than patching
> every .bb file.
>
> MAINTAINER would still exists but would become a distro variable so
> distros would still use it to set the maintainer of distributed packages
> but since this is usually a distro contact, setting it in a distro.conf
> file shouldn't be a problem (and it can be overridden on a per package
> basis MAINTAINER_pn-linux-opnzaurus = "").

Does this mean we'll have additional per-distro .conf files
which contain hundreds of MAINTAINER_pn-foo variables?

> The format of the maintainers file is yet to be determined and proposals
> are welcome. So far the requirements are something simple and consistent
> in an easily parsed format (both human and computer parsed). We need to
> list a contact, the packages covered and the level of interactivity of
> the maintainer (we need a list of these levels?).
>
>
> By creating this new file, we get the overhaul of the MAINTAINERS we
> need and it solves a lot of existing policy issues which we can't solve
> with the existing structure so personally, I'm very much in favour of
> it.

I'm all for the proposal of a MAINTAINERS file, especially as it allows
to state a general field of interest.

regards
Philipp

Re: [RFC] Removing MAINTAINER field from recipes

[Richard Purdie]

On Mon, 2006-10-09 at 10:40 +0200, pHilipp Zabel wrote:
> On 10/9/06, Richard Purdie <rpurdie@rpsys.net> wrote:
> > MAINTAINER would still exists but would become a distro variable so
> > distros would still use it to set the maintainer of distributed packages
> > but since this is usually a distro contact, setting it in a distro.conf
> > file shouldn't be a problem (and it can be overridden on a per package
> > basis MAINTAINER_pn-linux-opnzaurus = "").
> 
> Does this mean we'll have additional per-distro .conf files
> which contain hundreds of MAINTAINER_pn-foo variables?

That is something for a distro to decide. In most cases, I see a distro
wanting a single point of contact so whilst it would be possible, I
don't see it happening. All current distros try and setup a single point
of contact as far as I know.

Richard

Re: [RFC] Removing MAINTAINER field from recipes

[Koen Kooi]

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

Graeme Gregory schreef:
<snip>

> I second this proposal, it covers the issues I raised with my earlier
> email and gives still a point of contact which I like.

Any comments about the patch?

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFKnLnMkyGM64RGpERApOnAJ9yDHEaRjo0yRA9MU2PSwG6Z6FohQCePMR6
+nu91pDrDKPP+6xlEhjDexI=
=Ug7l
-----END PGP SIGNATURE-----

Re: [RFC] Removing MAINTAINER field from recipes

[Graeme Gregory]

On Mon, Oct 09, 2006 at 06:03:52PM +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Graeme Gregory schreef:
> <snip>
> 
> > I second this proposal, it covers the issues I raised with my earlier
> > email and gives still a point of contact which I like.
> 
> Any comments about the patch?
> 
A quick scan of the patch and it looks fine to me.

G

Re: [RFC] Removing MAINTAINER field from recipes

[Marcin Juszkiewicz]

Dnia poniedziałek, 9 października 2006 10:21, Richard Purdie napisał:
> What is missing here is the proposed alternative. The idea we discussed
> was having a Maintainers file, similar in spirit to that in the Linux
> kernel where people can detail areas they're interested in and give some
> kind of indication of the type of support they want to give.

My suggestion:

==========================================================================
OpenEmbedded Maintainers List 

Please put you full name and email-address here for the areas of OE you 
want to support.

Note: For the hard of thinking, this list is meant to remain in 
alphabetical order. If you could add yourselves to it in alphabetical 
order that would be so much easier.

Person:     Real name
Mail:       Mail patches to
Website:    Web-page
Distros:    Maintained distros
Machines:   Maintained machines
Recipes:    Maintained recipes (subsystems first, then single ones)

-----------------------------------------------------------------------------

Person:     Koen Kooi 
Mail:       koen@openembedded.org
Website:    http://dominion.kabel.utwente.nl/koen/cms
Machines:   h2200, ipaq-pxa270, efika, ep93xx, netbook-pro
Distros:    Angström
Recipes:    OpenSync,, GNOME, GPE, Matchbox
Recipes:    abiword, bootchart, dia, farsight, freeciv, fuse, galago, geda,
Recipes:    gimp, gnumeric, (g)obby, imposter, inkscape
Recipes:    telepathy, tilibs, xchat, xournal. 

Person:     Marcin Juszkiewicz
Mail:       hrw@openembedded.org
Website:    http://www.hrw.one.pl/
Machines:   collie, spitz
Distros:    OpenZaurus
Recipes:    OPIE, HostAP, Orinoco, WPA-Supplicant, Wireless tools, Keymaps
Recipes:    OpenZaurus 2.6 kernels, Qtopia fonts, DejaVu fonts, Native SDK
Recipes:    kdepimpi, subapplet, corsair, gammu, iqnotes, zbedic
==========================================================================


-- 
JID: hrw-jabber.org
OpenEmbedded developer

            That must be wonderful! I don understand it at all.

Re: [RFC] Removing MAINTAINER field from recipes

[Graeme Gregory]

A suggestion as to a possible format for MAINTAINERS file.

I tried to be machine parsable and human parsable.

DEVELOPER {
NAME="Koen Kooi"
NICK="koen"
EMAIL="Koen Kooi <koen@openembedded.org>
MACHINE="h2200 ipaq-pxa270"
DISTRO="angstrom.*"
RECPIPES="gnome/.* gnumeric/.*"
}

DEVELOPER {
NAME="Graeme Gregory"
NICK="XorA"
EMAIL="Graeme Gregory <dp@xora.org.uk>"
RECIPES="kismet/.* sylpheed/.*"
INTERESTS="Multimedia playback on console and x11"
}


Cheers

G

Re: [RFC] Removing MAINTAINER field from recipes

[Paul Sokolovsky]

Hello Graeme,

Tuesday, October 10, 2006, 6:39:18 PM, you wrote:

> A suggestion as to a possible format for MAINTAINERS file.

> I tried to be machine parsable and human parsable.

> DEVELOPER {
> NAME="Koen Kooi"
> NICK="koen"
> EMAIL="Koen Kooi <koen@openembedded.org>
> MACHINE="h2200 ipaq-pxa270"
> DISTRO="angstrom.*"
> RECPIPES="gnome/.* gnumeric/.*"
> }

  Well, just a note: this seems just like *too much machine* parsable
;-). As far as got from idea of removing the var, intention of the
list to be machine parsable was simple things, like sorting it
in some order or rendering in HTML. Not being able to write
a script which, for any given package, will return a maintainer for
it. In other words, I understood that intention was that maintainer
list's contents were intended for human consumption, and only syntax
of it should be machine-readable.

  Because otherwise, MAINTAINER field could have stayed the way it
was.

  Please correct me if I'm wrong.


Marcin Juszkiewicz wrote:

> Person:     Koen Kooi
> Mail:       koen@openembedded.org
> Website:    http://dominion.kabel.utwente.nl/koen/cms
> Machines:   h2200, ipaq-pxa270, efika, ep93xx, netbook-pro
> Distros:    Angstrom
> Recipes:    OpenSync,, GNOME, GPE, Matchbox
> Recipes:    abiword, bootchart, dia, farsight, freeciv, fuse, galago, geda,
> Recipes:    gimp, gnumeric, (g)obby, imposter, inkscape
> Recipes:    telepathy, tilibs, xchat, xournal. 


> Cheers

> G


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Removing MAINTAINER field from recipes

[Jamie Lenehan]

On Tue, Oct 10, 2006 at 05:34:27PM +0200, Marcin Juszkiewicz wrote:
[...]
> alphabetical order. If you could add yourselves to it in alphabetical 
> order that would be so much easier.

Didn't take long for it not to be in alphabetical order ;) And it
doesn't mention what the order is - first name? last name?

And I assume general areas of work just goes in recipes? (ie, for me
that would be anything sh4 related and anything cli router/firewall
related.)

-- 
 Jamie Lenehan <lenehan@twibble.org>

Re: [RFC] Removing MAINTAINER field from recipes

[Marcin Juszkiewicz]

Dnia piątek, 13 października 2006 02:28, Jamie Lenehan napisał:

> And I assume general areas of work just goes in recipes? (ie, for me
> that would be anything sh4 related and anything cli router/firewall
> related.)

Someone added "Interests" field which is better. So your entry would be:

Person:     Jamie Lenehan
Mail:       lenehan@twibble.org
Machine:    sh4-machines-which-you-maintain
Interests:  SH4, router/firewall stuff
Recipes:    this, that, other


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

                    If it happens, it must be possible.

Re: [RFC] Removing MAINTAINER field from recipes

[Jamie Lenehan]

On Fri, Oct 13, 2006 at 03:22:14PM +0200, Marcin Juszkiewicz wrote:
> Dnia piątek, 13 października 2006 02:28, Jamie Lenehan napisał:
> 
> > And I assume general areas of work just goes in recipes? (ie, for me
> > that would be anything sh4 related and anything cli router/firewall
> > related.)
> 
> Someone added "Interests" field which is better. So your entry would be:

Yeah, that works well. I've added my entry now.

-- 
 Jamie Lenehan <lenehan@twibble.org>