From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: Re: Package Maintenance
Date: Tue, 24 Mar 2009 09:06:46 +0000 [thread overview]
Message-ID: <1237885606.5348.8.camel@dax.rpnet.com> (raw)
In-Reply-To: <b6ebd0a50903231335y1ddfcb3bpd447b646e18d439a@mail.gmail.com>
On Mon, 2009-03-23 at 13:35 -0700, Chris Larson wrote:
> On Tue, Mar 17, 2009 at 12:18 PM, Chris Larson <clarson@kergoth.com> wrote:
> > I'd like to propose re-establishing MAINTAINER, set per package, to
> > individuals, or left as default for packages which aren't directly
> > maintained.
> >
> > Doing this would:
> > - Facilitate dumping a list of unmaintained packages to give to new
> > users wanting to volunteer to help us, but not knowing how to
> > contribute.
> > - Return some individual responsibility to the project, giving one
> > person the blame for brokenness for that package, as well as giving
> > responsibility for pushing patches upstream to that person. In my
> > opinion, a number of the recent issues in the project are due, in
> > part, to a lack of that individual responsibility. Everything is
> > fuzzy, determined by a group, instead.
> > - Allow us to physically separate, in the repository, those packages
> > which get the most attention (are maintained) from those which get the
> > least (maintained by the entire team). We could finally be *honest*
> > with our users about what we work on, telling them that the packages
> > which are maintained by the team are in need of an individual
> > maintainer, and get less attention, so bugs there will be fixed more
> > slowly, and there are no guarantees on functionality there. I think
> > it'd be better to have a core set of *functional* recipes than have a
> > huge set of "might work, might not" recipes as things stand today. In
> > my opinion, this would be more likely to give new users stability than
> > creating a stable branch, while making better use of our limited
> > manpower, rather than increasing the load drastically.
>
> If no one is against this, I'd say we should start taking ownership of
> packages and setting MAINTAINER in the recipes, after ensuring that
> the packaging code won't put MAINTAINER into the packages.
>
> Unless someone else wants them, as a start, I'd be willing to take
> autoconf, automake, libtool, and perhaps autotools.bbclass, though
> there's no good mechanism to record that.
Can we use something other than the MAINTAINER variable? The package
classes inject that value into the packages and that is really something
that should be set by the distribution. I'd don't want to end up back in
the position where that variable doesn't have a clear meaning.
It was also intended that the Maintainers file we added when MAINTAINERS
were removes would replace these variables in individual recipes. That
file format was designed to be machine readable so someone could have
written a script to find out who maintained a class/.bb/.conf file. This
has the advantage that is can handle .bbclass file maintainership which
is an issue with the MAINTAINERS variable...
Cheers,
Richard
next prev parent reply other threads:[~2009-03-24 9:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 19:18 Package Maintenance Chris Larson
2009-03-17 19:25 ` Koen Kooi
2009-03-17 19:32 ` Chris Larson
2009-03-17 19:43 ` Frans Meulenbroeks
2009-03-23 20:35 ` Chris Larson
2009-03-24 9:06 ` Richard Purdie [this message]
2009-03-24 15:08 ` Chris Larson
2009-03-24 18:36 ` Frans Meulenbroeks
2009-03-24 18:54 ` Tom Rini
2009-03-24 18:55 ` Chris Larson
2009-03-24 19:14 ` Koen Kooi
2009-03-24 19:24 ` Chris Larson
2009-03-24 19:50 ` Tom Rini
2009-03-24 19:59 ` Chris Larson
2009-03-24 18:56 ` Junqian Gordon Xu
2009-03-24 19:05 ` Chris Larson
2009-03-24 19:19 ` Junqian Gordon Xu
2009-03-24 19:29 ` Philip Balister
2009-03-24 19:51 ` Tim Ellis
2009-03-24 20:01 ` Chris Larson
2009-03-24 20:16 ` Koen Kooi
2009-03-24 20:30 ` Lon Lentz
2009-03-24 20:44 ` Junqian Gordon Xu
2009-03-25 8:51 ` Frans Meulenbroeks
2009-03-25 11:03 ` Koen Kooi
2009-03-25 13:36 ` Richard Purdie
2009-03-25 14:16 ` Holger Schurig
2009-03-25 14:40 ` Richard Purdie
2009-03-25 15:32 ` Holger Schurig
2009-03-25 14:26 ` Otavio Salvador
2009-03-25 16:05 ` Mike (mwester)
2009-03-25 16:20 ` Koen Kooi
2009-03-25 18:03 ` Jeremy Lainé
2009-03-25 18:22 ` Koen Kooi
2009-03-25 18:13 ` Mike (mwester)
2009-03-25 22:07 ` Frans Meulenbroeks
2009-03-25 22:27 ` Jeremy Lainé
2009-03-25 23:54 ` Mike (mwester)
2009-03-27 9:22 ` Richard Purdie
2009-03-24 19:59 ` Mike (mwester)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1237885606.5348.8.camel@dax.rpnet.com \
--to=rpurdie@rpsys.net \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.