[oe] Package Maintenance

Junqian Gordon Xu xjqian at gmail.com
Tue Mar 24 19:19:19 UTC 2009


On 03/24/2009 02:05 PM, Chris Larson wrote:
> On Tue, Mar 24, 2009 at 11:56 AM, Junqian Gordon Xu <xjqian at 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




More information about the Openembedded-devel mailing list