[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