[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