[oe] Package Maintenance

Philip Balister philip at balister.org
Tue Mar 24 19:29:00 UTC 2009


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 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20090324/9dd91c73/attachment-0002.bin>


More information about the Openembedded-devel mailing list