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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.