Openembedded Devel Discussions
 help / color / mirror / Atom feed
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 --]

  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