[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reinforcing comaintainance



Hi,

On Fri, May 19, 2006 at 06:20:46PM +0300, Eddy Petri??or wrote:
> My personal feeling is that the concept of "ownership" of packages is
> still present within the team.
> 
> I want to take this ocasion to afirm that from now on we should stop
> this idea at once. Bugs are sitting in the BTS without nobody touching
> them. I see this as a bad thing and we should fix it.

Actually, I think this shows that there isn't enough "ownership".  Sure, if
people feel like fixing bugs, please go ahead.  But if nobody else does,
there's still one person who's responsible for fixing it.

> So I propose:
> - Create a special zone in the repository for really egoistic people
> :P who feel like not sharing the maintainership of the packages with
> others; still bug fixes should not be reagrded as an intrusion (IMHO)
> from others if:
>    - an announcement like "I am going for #nnnnnn" has occured
>    - there is no answer/opposition from the egoistic maintainers at
> the said announcement
>    - even if there was opposition there is no activity within 3 days
> from the maintainer
> - Everything else is assumed to be comaintained 100% (of course
> working on the same package at a time should be arbitrated)

IMO everything which has the maintainer field set to the list should be
considered comaintained.  This is orthogonal to if it's in the repository.

I currently have two packages which are team-maintained, but are not in the
repository.  Both have a reason for that:
- GFingerPoken: I am upstream, and I like having the debian directory in the
  upstream repository (not in the release tarballs though).  It is under
  version control there, so it would just be more complex to move it to here.
- SDLJump: I packaged it and had it uploaded.  It should probably be in the
  repository.  I don't have the packaging on my system anymore, I'd apt-get
  source if I'd need to do something.  If anyone feels the need to have it in
  the repository, go ahead and upload it.  I don't think it has much "added
  value" though (because maintainance is hardly needed).
Both of these are only possible because they are totally stable: Hardly any
upstream releases, no bugs to fix.  For such packages, I don't have a problem
with them not being in the repository.

> - Ask every maintainer which has "given" packages to the team, but has
> not published via SVN the sources to revert the maintainer field or
> publish the source package in the svn repo. This is more like a
> request to decide if he/she is comaintaing the package or just
> participates on the mailing list.

For GFingerPoken, I have a problem with that.  I see comaintainance of a group
of packages as big as this one to be usable for two things:
- If there are several people interested in the package, really comaintain
  them (that is, work on them together).  This assumes upstream activity,
  otherwise there's not much to do.
- If there's no (or not much) upstream activity, provide a fallback in case a
  maintainer goes MIA.  This is why I do like to have those games
  comaintained.  And don't get me wrong: if there's a bug and someone feels
  like fixing it before I do, that's good!  But because that isn't going to
  happen a lot (both because there aren't a lot of bugs, and because I suppose
  others haven't looked at the packaging), I'm not waiting for it.  And if a
  bug is reported, I still see fixing it as my responsibility.

Also, I think every game should have a wiki page which describes how the
packaging is done, and where it is located.  If that isn't clear, I'd go for
the Debian source package.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

Attachment: signature.asc
Description: Digital signature


Reply to: