From: Philip Balister <philip@balister.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Package Maintenance
Date: Tue, 24 Mar 2009 15:29:00 -0400 [thread overview]
Message-ID: <49C9347C.7010309@balister.org> (raw)
In-Reply-To: <49C93237.7010205@gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2009-03-24 19:30 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 19:18 Package Maintenance Chris Larson
2009-03-17 19:25 ` Koen Kooi
2009-03-17 19:32 ` Chris Larson
2009-03-17 19:43 ` Frans Meulenbroeks
2009-03-23 20:35 ` Chris Larson
2009-03-24 9:06 ` Richard Purdie
2009-03-24 15:08 ` Chris Larson
2009-03-24 18:36 ` Frans Meulenbroeks
2009-03-24 18:54 ` Tom Rini
2009-03-24 18:55 ` Chris Larson
2009-03-24 19:14 ` Koen Kooi
2009-03-24 19:24 ` Chris Larson
2009-03-24 19:50 ` Tom Rini
2009-03-24 19:59 ` Chris Larson
2009-03-24 18:56 ` Junqian Gordon Xu
2009-03-24 19:05 ` Chris Larson
2009-03-24 19:19 ` Junqian Gordon Xu
2009-03-24 19:29 ` Philip Balister [this message]
2009-03-24 19:51 ` Tim Ellis
2009-03-24 20:01 ` Chris Larson
2009-03-24 20:16 ` Koen Kooi
2009-03-24 20:30 ` Lon Lentz
2009-03-24 20:44 ` Junqian Gordon Xu
2009-03-25 8:51 ` Frans Meulenbroeks
2009-03-25 11:03 ` Koen Kooi
2009-03-25 13:36 ` Richard Purdie
2009-03-25 14:16 ` Holger Schurig
2009-03-25 14:40 ` Richard Purdie
2009-03-25 15:32 ` Holger Schurig
2009-03-25 14:26 ` Otavio Salvador
2009-03-25 16:05 ` Mike (mwester)
2009-03-25 16:20 ` Koen Kooi
2009-03-25 18:03 ` Jeremy Lainé
2009-03-25 18:22 ` Koen Kooi
2009-03-25 18:13 ` Mike (mwester)
2009-03-25 22:07 ` Frans Meulenbroeks
2009-03-25 22:27 ` Jeremy Lainé
2009-03-25 23:54 ` Mike (mwester)
2009-03-27 9:22 ` Richard Purdie
2009-03-24 19:59 ` Mike (mwester)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49C9347C.7010309@balister.org \
--to=philip@balister.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox