> And I found that the debian-perl group is working quite well maintaining
> all their packages in a single subversion repository where all
> developers in the group have write access.
> :
> So I proposed something similar.
I personally agree with Raphaël and Benjamin.
IMHO, when we drop packages from our archive just because they are orphaned (I
have
the jpeg2ps example in mind) we definitely loose a point (just think to the
end-user
point of view).
The solution used for the Perl packages really sounds good, but it raises some
important questions:
- on which basis an orphaned package could enter this third-maintenance
system? (is that automatic for each orphaned package? I don't think it
should be).
- how would we give permissions to "foreign" developers? I'm thinking at the
fact that we should not allow everyone who waves to have access to the
alioth project, then I'm thinking at a kind of a light applicant system
(could just be a mail discussion on a list).
- should a team be setup for handling and supervising those third-maintained
packages? (I think so).
- Should the package still be named orphaned? Yes, it's not maintained, but
if patches are handled with care by an "expert", it's not really orphaned
anymore.
If we find good answers to those questions, I think we can have someting
interesting to discuss.
Here is a scheme I have in mind (up for discussion):
- an alioth project is created, named "debian-zombies" (yes, that name is not
the best, I agree, but you get the idea, I don't like to call them orphaned
for the reason explained above).
- that project handles one module in the SVN repository for each "zombie"
package.
- "Experts" are registered after an applicant approval by the Debian Zombie
Team (again, you can blame me for that name, just an example :-)
The application should be really light, for not discouraging applicants, but
should reamin a bit strict to filter applicants. In a way, we should just
check that the applicant is a real expert for the zombie package.
- Expert have SVN access to the module they are registered for.
- A mailing list is setup for handling coordination between experts and Debian
developers.
- When needed, one member of the "debian zombie team" upload a new zombie
package.
- The maintainer field of such packages could be filled with something like
Debian Zombie Team <[EMAIL PROTECTED]>, this would underline that the
package is not maintained in the classical meaning, but is better than
orphaned.
All this leads to conclude that I tend to vote for a new state for packages that
are orphaned in debian, but have experts that are able to give support: the
zombie state.
Feel free to comment all this, that's just what I have in mind, regarding to
this discussion.
Cheers.
--
- Alexis Sukrieh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
