Package Maintenance

Package Maintenance

[Chris Larson]

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.

Opinions?
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Koen Kooi]

On 17-03-09 20:18, Chris Larson 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.
>
> Opinions?

As long as it doesn't get put in resulting packages in any way, it's 
fine by me.

regards,

Koen

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 17, 2009 at 12:25 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 17-03-09 20:18, Chris Larson 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.
>>
>> Opinions?
>
> As long as it doesn't get put in resulting packages in any way, it's fine by
> me.

Good point, I don't think anyone wants to get emails from people who
found the MAINTAINER contact info in ipk files in feeds via google :)
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Frans Meulenbroeks]

2009/3/17 Koen Kooi <k.kooi@student.utwente.nl>:
> On 17-03-09 20:18, Chris Larson 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.
>>
>> Opinions?
>
> As long as it doesn't get put in resulting packages in any way, it's fine by
> me.
>
> regards,
>
> Koen
>

Agree with koen

FM

Re: Package Maintenance

[Chris Larson]

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.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Richard Purdie]

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

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 2:06 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> 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...

Well, that works too, I don't particularly care how we do it, as long
as we do it :)  Is the Maintainers file actually being maintained? ;)
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Frans Meulenbroeks]

Disadvantage of a Maintainers file is that it is yet another file to
update when you create a package (adjacent to the checksums file and
of course the package recipe). Guess it will be forgotten regularly.

Also I fear we're going to end up with a lot of orphaned packages.

Frans

Re: Package Maintenance

[Tom Rini]

On Tue, Mar 24, 2009 at 07:36:29PM +0100, Frans Meulenbroeks wrote:

[snip]
> Also I fear we're going to end up with a lot of orphaned packages.

Do you mean finding out we have a bunch of orphaned packages?  However
it's done, I don't think having people take ownership will make people
stop doing it.

-- 
Tom Rini

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 11:36 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Disadvantage of a Maintainers file is that it is yet another file to
> update when you create a package (adjacent to the checksums file and
> of course the package recipe). Guess it will be forgotten regularly.
>
> Also I fear we're going to end up with a lot of orphaned packages.

The point I'm trying to make is that we have a lot of orphaned
packages today, we just aren't being honest about it.  90% of the
recipes in the tree don't get the attention they should.

At least this way, it's quite clear which get individual attention vs
those that get cursory attention by the entire team.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Junqian Gordon Xu]

On 03/24/2009 01:36 PM, Frans Meulenbroeks wrote:
> Disadvantage of a Maintainers file is that it is yet another file to
> update when you create a package (adjacent to the checksums file and
> of course the package recipe). Guess it will be forgotten regularly.
> 
> Also I fear we're going to end up with a lot of orphaned packages.

One possibility is to get statistics about the committer from the last X 
commits, calculate the mean and standard deviation (STD) of the age of 
the last X commits to indicate how likely the maintainer is alive, and 
automatically update the Maintainer file every month. There will be 
other details to discuss, but the maintainer file would look something 
like this.

Recipe name	Maintainer	Mean Age (last 5)	STD (last 5)

gcc		Koen		2 month            	10 days
binutils        RP		1 year			2 month
...

Regards
Gordon

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 11:56 AM, Junqian Gordon Xu <xjqian@gmail.com> wrote:
> On 03/24/2009 01:36 PM, Frans Meulenbroeks wrote:
>>
>> Disadvantage of a Maintainers file is that it is yet another file to
>> update when you create a package (adjacent to the checksums file and
>> of course the package recipe). Guess it will be forgotten regularly.
>>
>> Also I fear we're going to end up with a lot of orphaned packages.
>
> One possibility is to get statistics about the committer from the last X
> commits, calculate the mean and standard deviation (STD) of the age of the
> last X commits to indicate how likely the maintainer is alive, and
> automatically update the Maintainer file every month. There will be other
> details to discuss, but the maintainer file would look something like this.
>
> Recipe name     Maintainer      Mean Age (last 5)       STD (last 5)
>
> gcc             Koen            2 month                 10 days
> binutils        RP              1 year                  2 month

That's an interesting possibility.  I'd thought about looking at the
committers, but didn't think about using the age.  How would you
handle something that's had 3 commits by one person and 2 by another?
And those 3 were minor bugfixes by a contributer, not someone who
plans on taking any responsibility for the state of the recipe? :)
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Koen Kooi]

On 24-03-09 19:55, Chris Larson wrote:
> On Tue, Mar 24, 2009 at 11:36 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com>  wrote:
>> Disadvantage of a Maintainers file is that it is yet another file to
>> update when you create a package (adjacent to the checksums file and
>> of course the package recipe). Guess it will be forgotten regularly.
>>
>> Also I fear we're going to end up with a lot of orphaned packages.
>
> The point I'm trying to make is that we have a lot of orphaned
> packages today, we just aren't being honest about it.  90% of the
> recipes in the tree don't get the attention they should.

I suspect we have approx 100 properly maintained recipes, which is 
approx 1.5%. The rest is 'unmaintained' due to dormant upstream, or 
because it builds and works just well enough for people to ignore it.
Also, having people put their name down as maintainer doesn't help when 
they have no interest in QA at all.

What about recording when a recipe has been 'vetted' and the results of 
the 'vetting':

# foo_1.0.bb vetting record:
# 2008/10/31  -  koen@openembedded.org
# 	beagleboard/angstrom-2008.1
#		fails to build with gcc >= 4.3.0
#	tosa/angstrom-2008.1
#		works
# 2006/5/16 - hrw@openembedded.org
#	tosa/openzaurus-3.5.3
#		works

thoughts?

regards,

Koen

Re: Package Maintenance

[Junqian Gordon Xu]

On 03/24/2009 02:05 PM, Chris Larson wrote:
> On Tue, Mar 24, 2009 at 11:56 AM, Junqian Gordon Xu <xjqian@gmail.com> wrote:
>> On 03/24/2009 01:36 PM, Frans Meulenbroeks wrote:
>>> Disadvantage of a Maintainers file is that it is yet another file to
>>> update when you create a package (adjacent to the checksums file and
>>> of course the package recipe). Guess it will be forgotten regularly.
>>>
>>> Also I fear we're going to end up with a lot of orphaned packages.
>> One possibility is to get statistics about the committer from the last X
>> commits, calculate the mean and standard deviation (STD) of the age of the
>> last X commits to indicate how likely the maintainer is alive, and
>> automatically update the Maintainer file every month. There will be other
>> details to discuss, but the maintainer file would look something like this.
>>
>> Recipe name     Maintainer      Mean Age (last 5)       STD (last 5)
>>
>> gcc             Koen            2 month                 10 days
>> binutils        RP              1 year                  2 month
> 
> That's an interesting possibility.  I'd thought about looking at the
> committers, but didn't think about using the age.  How would you
> handle something that's had 3 commits by one person and 2 by another?
> And those 3 were minor bugfixes by a contributer, not someone who
> plans on taking any responsibility for the state of the recipe? :)

That's the details I'm thinking abouts.

1) For a recipe who has a strong opinion on taking responsibility. We 
can use the logic of strong assignment for that person, so the 
maintainer field won't be overwritten by the weak assignment generated 
by the statistics.

2) For other recipes, I would use winner-takes-all (who has the most 
commits) for the last X commits, whether it's a bug fix or contributer. 
If the contributer really cares, please go back to step 1). If there is 
a tie, just list all the winners or list the last winner.

Regards
Gordon

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 12:14 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 24-03-09 19:55, Chris Larson wrote:
>>
>> On Tue, Mar 24, 2009 at 11:36 AM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com>  wrote:
>>>
>>> Disadvantage of a Maintainers file is that it is yet another file to
>>> update when you create a package (adjacent to the checksums file and
>>> of course the package recipe). Guess it will be forgotten regularly.
>>>
>>> Also I fear we're going to end up with a lot of orphaned packages.
>>
>> The point I'm trying to make is that we have a lot of orphaned
>> packages today, we just aren't being honest about it.  90% of the
>> recipes in the tree don't get the attention they should.
>
> I suspect we have approx 100 properly maintained recipes, which is approx
> 1.5%. The rest is 'unmaintained' due to dormant upstream, or because it
> builds and works just well enough for people to ignore it.
> Also, having people put their name down as maintainer doesn't help when they
> have no interest in QA at all.

Having people put down their name as the maintainer means they're the
ones responsible for keeping it in good shape.  They're responsible
for fixing it if it breaks, though someone else may be nice enough to
fix it themselves, if it's blocking them.

I also don't think the fact that a recipe builds is an excuse to
ignore it.  Recipes should be kept in good shape, by current
standards, in my opinion.  As an example, many recipes still don't
take advantage of the ${BP}, etc variables, and are overriding
FILES{DIR,PATH} unnecessarily.

> What about recording when a recipe has been 'vetted' and the results of the
> 'vetting':
>
> # foo_1.0.bb vetting record:
> # 2008/10/31  -  koen@openembedded.org
> #       beagleboard/angstrom-2008.1
> #               fails to build with gcc >= 4.3.0
> #       tosa/angstrom-2008.1
> #               works
> # 2006/5/16 - hrw@openembedded.org
> #       tosa/openzaurus-3.5.3
> #               works

I'm sure that would be useful, but I don't see that as a replacement
for people taking responsibility.  Personally, I'd be a lot more
confident in my builds if I knew everything I was building was
actively maintained by an individual member of the team.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Philip Balister]

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

Junqian Gordon Xu wrote:
> On 03/24/2009 02:05 PM, Chris Larson wrote:
>> On Tue, Mar 24, 2009 at 11:56 AM, Junqian Gordon Xu <xjqian@gmail.com> 
>> wrote:
>>> On 03/24/2009 01:36 PM, Frans Meulenbroeks wrote:
>>>> Disadvantage of a Maintainers file is that it is yet another file to
>>>> update when you create a package (adjacent to the checksums file and
>>>> of course the package recipe). Guess it will be forgotten regularly.
>>>>
>>>> Also I fear we're going to end up with a lot of orphaned packages.
>>> One possibility is to get statistics about the committer from the last X
>>> commits, calculate the mean and standard deviation (STD) of the age 
>>> of the
>>> last X commits to indicate how likely the maintainer is alive, and
>>> automatically update the Maintainer file every month. There will be 
>>> other
>>> details to discuss, but the maintainer file would look something like 
>>> this.
>>>
>>> Recipe name     Maintainer      Mean Age (last 5)       STD (last 5)
>>>
>>> gcc             Koen            2 month                 10 days
>>> binutils        RP              1 year                  2 month
>>
>> That's an interesting possibility.  I'd thought about looking at the
>> committers, but didn't think about using the age.  How would you
>> handle something that's had 3 commits by one person and 2 by another?
>> And those 3 were minor bugfixes by a contributer, not someone who
>> plans on taking any responsibility for the state of the recipe? :)
> 
> That's the details I'm thinking abouts.
> 
> 1) For a recipe who has a strong opinion on taking responsibility. We 
> can use the logic of strong assignment for that person, so the 
> maintainer field won't be overwritten by the weak assignment generated 
> by the statistics.
> 
> 2) For other recipes, I would use winner-takes-all (who has the most 
> commits) for the last X commits, whether it's a bug fix or contributer. 
> If the contributer really cares, please go back to step 1). If there is 
> a tie, just list all the winners or list the last winner.

I think a report that calculates a score and reports the top three would 
be really useful. The scoring should give us an idea of how well 
maintained a recipe is, and who is doing the work. It should also handle 
active versus inactive recipes.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Package Maintenance

[Tom Rini]

On Tue, Mar 24, 2009 at 12:24:27PM -0700, Chris Larson wrote:
[snip]
> I also don't think the fact that a recipe builds is an excuse to
> ignore it.  Recipes should be kept in good shape, by current
> standards, in my opinion.  As an example, many recipes still don't
> take advantage of the ${BP}, etc variables, and are overriding
> FILES{DIR,PATH} unnecessarily.

I'm saying this as an example, but, the what-now variable?  And why
didn't however added a handy new variable regex an update in?  If we're
going to push cleanups off of the person writing them and onto the
maintainer, they need to be documented and linked from a single spot or
so (so people can check a page once a week / whenever and see what's
been put on their plate).

-- 
Tom Rini

Re: Package Maintenance

[Tim Ellis]

I am happy with whatever the outcome of this is as long as my packages  
as specified in the MAINTAINERS file end up being maintained by me -  
we should start whatever changes by transferring the information there  
to wherever it is destined to go and then assessing the logs of  
individual packages imho. Once a decision has been made getting devs  
that are listed there to transfer the information would be a good way  
to see who is active and actually wants to maintain their packages.

I don't really have a problem with the way it is at the moment to be  
honest and try to contact people using git log on packages and the  
MAINTAINERS file if I have a need to touch other packages, which isn't  
really that hard!

Thanks

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 12:50 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> On Tue, Mar 24, 2009 at 12:24:27PM -0700, Chris Larson wrote:
> [snip]
>> I also don't think the fact that a recipe builds is an excuse to
>> ignore it.  Recipes should be kept in good shape, by current
>> standards, in my opinion.  As an example, many recipes still don't
>> take advantage of the ${BP}, etc variables, and are overriding
>> FILES{DIR,PATH} unnecessarily.
>
> I'm saying this as an example, but, the what-now variable?  And why
> didn't however added a handy new variable regex an update in?  If we're
> going to push cleanups off of the person writing them and onto the
> maintainer, they need to be documented and linked from a single spot or
> so (so people can check a page once a week / whenever and see what's
> been put on their plate).

Not all usage scenarios can be hit by a regex, and regexes are prone
to introducing syntax errors due to not considering every usage.  I'm
not saying don't use them, just pointing out that it's no substitute
for personal care.

BPN is the base package name, basically the package name with
-native/-cross ripped off.  I didn't add it, but it's a lovely thing.
A -native recipe doesn't need to manipulate FILESPATH/FILESDIR to
ensure their file:// uris in SRC_URI are found, for example, since the
base variables are also used.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Mike (mwester)]

Frans Meulenbroeks wrote:
> Disadvantage of a Maintainers file is that it is yet another file to
> update when you create a package (adjacent to the checksums file and
> of course the package recipe). Guess it will be forgotten regularly.
> 
> Also I fear we're going to end up with a lot of orphaned packages.

Is lack of a Maintainers file _really_ our problem?

IMO, our current issue is what I would term "Drive-by Commits" (for
example, the past two weekends have seen commits that have introduced
major breakage of some sort where the committer has not been about for
some fairly significant period of time.

I don't think listing a name in a Maintainers file is going to change
anything, frankly.

Mike (mwester)

Re: Package Maintenance

[Chris Larson]

On Tue, Mar 24, 2009 at 12:51 PM, Tim Ellis <tim@ngndg.com> wrote:
> I am happy with whatever the outcome of this is as long as my packages as
> specified in the MAINTAINERS file end up being maintained by me - we should
> start whatever changes by transferring the information there to wherever it
> is destined to go and then assessing the logs of individual packages imho.
> Once a decision has been made getting devs that are listed there to transfer
> the information would be a good way to see who is active and actually wants
> to maintain their packages.
>
> I don't really have a problem with the way it is at the moment to be honest
> and try to contact people using git log on packages and the MAINTAINERS file
> if I have a need to touch other packages, which isn't really that hard!
>

I don't think the current method is difficult, persay, but rather I'd
like to see:
- More individual responsibility in the project in general,
particularly in class and recipe maintenance.
- Clearer delineation between what gets the most attention and what does not.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Package Maintenance

[Koen Kooi]

On 24-03-09 21:01, Chris Larson wrote:
> On Tue, Mar 24, 2009 at 12:51 PM, Tim Ellis<tim@ngndg.com>  wrote:
>> I am happy with whatever the outcome of this is as long as my packages as
>> specified in the MAINTAINERS file end up being maintained by me - we should
>> start whatever changes by transferring the information there to wherever it
>> is destined to go and then assessing the logs of individual packages imho.
>> Once a decision has been made getting devs that are listed there to transfer
>> the information would be a good way to see who is active and actually wants
>> to maintain their packages.
>>
>> I don't really have a problem with the way it is at the moment to be honest
>> and try to contact people using git log on packages and the MAINTAINERS file
>> if I have a need to touch other packages, which isn't really that hard!
>>
>
> I don't think the current method is difficult, persay, but rather I'd
> like to see:
> - More individual responsibility in the project in general,
> particularly in class and recipe maintenance.

I'm all for that.

> - Clearer delineation between what gets the most attention and what does not.

This kind of 'passive' QA can be quite usefull, I really hope someone 
gets Junqians suggestion working so we have some hard data.

regards,

Koen

Re: Package Maintenance

[Lon Lentz]

  Please excuse my ignorance here, but what happens when a package literally
has no maintainer?

  Is OE attempting to manage a consumer facing product or provide a
centralized clearinghouse and methodology as a service to developers?


On Tue, Mar 24, 2009 at 4:01 PM, Chris Larson <clarson@kergoth.com> wrote:

> I don't think the current method is difficult, persay, but rather I'd
> like to see:
> - More individual responsibility in the project in general,
> particularly in class and recipe maintenance.
> - Clearer delineation between what gets the most attention and what does
> not.
>
>

Re: Package Maintenance

[Junqian Gordon Xu]

On 03/24/2009 03:30 PM, Lon Lentz wrote:
>   Please excuse my ignorance here, but what happens when a package literally
> has no maintainer?
> 
>   Is OE attempting to manage a consumer facing product or provide a
> centralized clearinghouse and methodology as a service to developers?

I think you took the word "responsibility" too seriously.

Regards
Gordon


> On Tue, Mar 24, 2009 at 4:01 PM, Chris Larson <clarson@kergoth.com> wrote:
> 
>> I don't think the current method is difficult, persay, but rather I'd
>> like to see:
>> - More individual responsibility in the project in general,
>> particularly in class and recipe maintenance.
>> - Clearer delineation between what gets the most attention and what does
>> not.
>>
>>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: Package Maintenance

[Frans Meulenbroeks]

Having read all of the responses let me explain the (admittedly
chaotic) way I work.

My interest is mostly in application packages. I added several recipes
for them in the past.
Also I've been using several packages that were already present (e.g.
for the beagleboard james project).
If I start doing so, I typically check whether the package is more or
less current. If the package is at 1.3 and the src is already at 2.4
I've updated the package if possible (as I felt it was probably
orphaned). Mainly I did so because I needed a newer version of that
package, but I do not desire to take ownership of all those packages.

If I find a trivial problem in a package that can be repaired easily
and with a low risk I also tend to fix it (e.g. a missing DEPENDS).
This is mostly independent of the package.
Not sure if that is the right way though.

Generally my attitude is: if you need something and detect that is
broken, don't whine about it, but fix it if possible (probably asking
advice on #oe or the mailing list)
And of course in due time I learned who to consult/contact/push for
specific packages.

Wrt the statistics to get a (proposed) maintainer. Good idea.
And if there is a (near) draw: As far as I am concerned it would be
perfectly ok if a package has two maintainers.

One last note. sometimes I created packages just because another
package needed them. My interest in that package is then a little bit
secondary. E.g.if I want package A and it does not exist I create it,
and if A needs B I probably need to create that one too, but keeping B
up to date might be less interesting if A does not need the newer B.

and a last last thing: about the vetting: not sure whether I fully
understand the idea, but is a lot of this info on what builds on what
not already present in tinderbox?

Frans

Re: Package Maintenance

[Koen Kooi]

On 25-03-09 09:51, Frans Meulenbroeks wrote:

> and a last last thing: about the vetting: not sure whether I fully
> understand the idea, but is a lot of this info on what builds on what
> not already present in tinderbox?

The tinderbox data is purged periodically, so don't depend on it.

regards,

Koen

Re: Package Maintenance

[Richard Purdie]

Having given this some further thought, I think the problem is we need
to do something different.

We've tried MAINTAINERS in recipes, it wasn't a success.

The current Maintainers file is ok and roughly current but doesn't have
as much visibility as we'd ideally like.


I don't think the Maintainers file is wrong as such, I think whats
missing are scripts to do something with the data. It would be useful if
we had a program which could tell us:

* Who maintains file X (be it a class/recipe/conf/sitefile etc)?
* Who last changed file X?
* Who are the contributors to file X?
* Can we easily create a subset of the metadata which is "maintained"?

If we have scripts to do this which is possible with a combination of
the Maintainers file and the SCM, maybe with some tweaks to file formats
as needed such as adding the git commit IDs I think people will start to
maintain the files more and we might get more people registering their
maintainership.


I should also mention one big reason we dropped the MAINTAINER fields
from recipes - they make no sense outside of OE. As soon as you move a
recipe into something like Poky, you don't want your name there.
Dropping the Maintainers file is easy, editing several hundred recipes
is a pain for syncing between the trees. We do want to support
initiatives like Poky, right? :)

Cheers,

Richard

Re: Package Maintenance

[Holger Schurig]

> * Who maintains file X (be it a class/recipe/conf/sitefile
> etc)? * Who last changed file X?
> * Who are the contributors to file X?
> * Can we easily create a subset of the metadata which is
> "maintained"?

I don't really think that -- in the general case -- maintaining 
maintainers on a per-file or per-recipe basis works for the 
recipes. There are just too many.

But maybe maintainership based on categories make sense.

* all cross-compilation and build tools
* all Java stuff
* all Python stuff
* all matchbox stuff
* all KDE stuff
* all OPIE stuff
* (more categories that are easily identifiable and make sense)
* the "pool" :-)

The point is: a package that is in the python category could 
easily be in Mickey scope of interest anyway. Similar for other 
categories. There's no exact match, but still a high degree of 
correlation.

Now it's easy to say "John Doe is our Java guy". And John could 
of course have sub-maintainers.

Re: Package Maintenance

[Otavio Salvador]

On Wed, Mar 25, 2009 at 10:36 AM, Richard Purdie <rpurdie@rpsys.net> wrote:

[...]

> * Can we easily create a subset of the metadata which is "maintained"?

[...]

That would be awesome since it could also speed up the building of
the image. Nowadays, the time need to build the cache makes me
fed up! :-)

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: Package Maintenance

[Richard Purdie]

On Wed, 2009-03-25 at 15:16 +0100, Holger Schurig wrote:
> > * Who maintains file X (be it a class/recipe/conf/sitefile
> > etc)? * Who last changed file X?
> > * Who are the contributors to file X?
> > * Can we easily create a subset of the metadata which is
> > "maintained"?
> 
> I don't really think that -- in the general case -- maintaining 
> maintainers on a per-file or per-recipe basis works for the 
> recipes. There are just too many.
> 
> But maybe maintainership based on categories make sense.
> 
> * all cross-compilation and build tools
> * all Java stuff
> * all Python stuff
> * all matchbox stuff
> * all KDE stuff
> * all OPIE stuff
> * (more categories that are easily identifiable and make sense)
> * the "pool" :-)
> 
> The point is: a package that is in the python category could 
> easily be in Mickey scope of interest anyway. Similar for other 
> categories. There's no exact match, but still a high degree of 
> correlation.
> 
> Now it's easy to say "John Doe is our Java guy". And John could 
> of course have sub-maintainers.

I agree. The current Maintainers file tried to capture this with the use
of wildcards which allows some improvements over per recipe but is far
from perfect. Better solutions welcome :)

Cheers,

Richard

Re: Package Maintenance

[Holger Schurig]

Uhh, I forgot to write that as an add-on I'd like to see the 
recipes for a category moved into it's own subdirectory.

That would make it easy to weed out lot's of uninteresting bb 
files by using a properly crafted BBFILES.

Re: Package Maintenance

[Mike (mwester)]

Koen Kooi wrote:
> On 25-03-09 09:51, Frans Meulenbroeks wrote:
> 
>> and a last last thing: about the vetting: not sure whether I fully
>> understand the idea, but is a lot of this info on what builds on what
>> not already present in tinderbox?
> 
> The tinderbox data is purged periodically, so don't depend on it.

In addition, you cannot determine which builds in tinderbox were done
with an empty TMPDIR -- and unless you have an empty TMPDIR, there's
really no complete test.

-Mike (mwester)

Re: Package Maintenance

[Koen Kooi]

On 25-03-09 17:05, Mike (mwester) wrote:
> Koen Kooi wrote:
>> On 25-03-09 09:51, Frans Meulenbroeks wrote:
>>
>>> and a last last thing: about the vetting: not sure whether I fully
>>> understand the idea, but is a lot of this info on what builds on what
>>> not already present in tinderbox?
>>
>> The tinderbox data is purged periodically, so don't depend on it.
>
> In addition, you cannot determine which builds in tinderbox were done
> with an empty TMPDIR -- and unless you have an empty TMPDIR, there's
> really no complete test.

Empty TMPDIR is only once case we should test for, I've seen many times 
that a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon 
to mention a recent one. So 'always build from empty TMPDIR' will leave 
serious and harder to trackdown bugs unnoticed.
Another example: building qt/e for ppc405 will OOM[1] if you have a 
populated TMPDIR, it will work fine from scratch.
We should certainly do builds from scratch to track down dependency and 
process bugs, but let's not forget about non-empty TMPDIR bugs.

regards,

Koen

[1] It took me a while to track that one down, since the OOM would 
either take sshd down as well, or just lock up the box.

Re: Package Maintenance

[Jeremy Lainé]

> Another example: building qt/e for ppc405 will OOM[1] if you have a
> populated TMPDIR, it will work fine from scratch.
> We should certainly do builds from scratch to track down dependency and
> process bugs, but let's not forget about non-empty TMPDIR bugs.

Eh? That's scary! What version of Qt are we talking about? I routinely build qt4/embedded
for powerpc targets (though admittedly not ppc405) without any problems.

-- 
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris

Re: Package Maintenance

[Mike (mwester)]

Koen Kooi wrote:
> On 25-03-09 17:05, Mike (mwester) wrote:
>> Koen Kooi wrote:
>>> On 25-03-09 09:51, Frans Meulenbroeks wrote:
>>>
>>>> and a last last thing: about the vetting: not sure whether I fully
>>>> understand the idea, but is a lot of this info on what builds on what
>>>> not already present in tinderbox?
>>>
>>> The tinderbox data is purged periodically, so don't depend on it.
>>
>> In addition, you cannot determine which builds in tinderbox were done
>> with an empty TMPDIR -- and unless you have an empty TMPDIR, there's
>> really no complete test.
> 
> Empty TMPDIR is only once case we should test for, I've seen many times
> that a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon
> to mention a recent one. So 'always build from empty TMPDIR' will leave
> serious and harder to trackdown bugs unnoticed.
> Another example: building qt/e for ppc405 will OOM[1] if you have a
> populated TMPDIR, it will work fine from scratch.
> We should certainly do builds from scratch to track down dependency and
> process bugs, but let's not forget about non-empty TMPDIR bugs.
> 
> regards,
> 
> Koen
> 
> [1] It took me a while to track that one down, since the OOM would
> either take sshd down as well, or just lock up the box.

Fair point -- which brings up a related area, which is parallel-enabled
builds.  Recipes and dependencies may behave differently due to Makefile
bugs, or inadequately-stated dependencies.

I guess we can't test everything, but we should agree about some minimum
standards to determine the "goodness" of a recipe.  I just don't know if
we can all agree on that minimum! :-)

Mike (mwester)

Re: Package Maintenance

[Koen Kooi]

On 25-03-09 19:03, Jeremy Lainé wrote:
>
>> Another example: building qt/e for ppc405 will OOM[1] if you have a
>> populated TMPDIR, it will work fine from scratch.
>> We should certainly do builds from scratch to track down dependency and
>> process bugs, but let's not forget about non-empty TMPDIR bugs.
>
> Eh? That's scary! What version of Qt are we talking about? I routinely build qt4/embedded
> for powerpc targets (though admittedly not ppc405) without any problems.

qt/e2, qt4 behaves nicely.

regards,

Koen

Re: Package Maintenance

[Frans Meulenbroeks]

2009/3/25 Koen Kooi <k.kooi@student.utwente.nl>:

> Empty TMPDIR is only once case we should test for, I've seen many times that
> a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon to
> mention a recent one. So 'always build from empty TMPDIR' will leave serious
> and harder to trackdown bugs unnoticed.

Test with unpopulataed TMPDIR and test with maximal populated TMPDIR ?

Re: Package Maintenance

[Jeremy Lainé]

>> Empty TMPDIR is only once case we should test for, I've seen many times that
>> a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon to
>> mention a recent one. So 'always build from empty TMPDIR' will leave serious
>> and harder to trackdown bugs unnoticed.
> 
> Test with unpopulataed TMPDIR and test with maximal populated TMPDIR ?

Speaking of populated TMPDIR, is there a notion of conflicts for staging? If two packages
want to put the same file into staging, will we barf an error or silently ignore it?

-- 
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris

Re: Package Maintenance

[Mike (mwester)]

Jeremy Lainé wrote:
>>> Empty TMPDIR is only once case we should test for, I've seen many times that
>>> a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon to
>>> mention a recent one. So 'always build from empty TMPDIR' will leave serious
>>> and harder to trackdown bugs unnoticed.
>> Test with unpopulataed TMPDIR and test with maximal populated TMPDIR ?
> 
> Speaking of populated TMPDIR, is there a notion of conflicts for staging? If two packages
> want to put the same file into staging, will we barf an error or silently ignore it?

It silently ignores it.

As a current example, unless distros have taken special care with libusb
and libusb1, they will suffer from exactly this problem, with the
library that is staged determined by which recipe is built most recently.

-Mike (mwester)

Re: Package Maintenance

[Richard Purdie]

On Wed, 2009-03-25 at 18:54 -0500, Mike (mwester) wrote:
> Jeremy Lainé wrote:
> >>> Empty TMPDIR is only once case we should test for, I've seen many times that
> >>> a 'populated' TMPDIR creates bugs, e.g. midori picking up libhildon to
> >>> mention a recent one. So 'always build from empty TMPDIR' will leave serious
> >>> and harder to trackdown bugs unnoticed.
> >> Test with unpopulataed TMPDIR and test with maximal populated TMPDIR ?
> > 
> > Speaking of populated TMPDIR, is there a notion of conflicts for staging? If two packages
> > want to put the same file into staging, will we barf an error or silently ignore it?
> 
> It silently ignores it.
> 
> As a current example, unless distros have taken special care with libusb
> and libusb1, they will suffer from exactly this problem, with the
> library that is staged determined by which recipe is built most recently.

One of the goals of packaged-staging was to detect this and error. Sadly
nobody has implemented it yet though...

Cheers,

Richard