Re: DEP-2: Debian Package Maintenance Hub
On Sun, 29 Jan 2012, Charles Plessy wrote:
> - It would be great to integrate it with Debian Pure Blends, so that
> a maintainer knows that his package is part of one of them.
Why not but this is not something that needs to be part of the early
design.
> - I like the current workflow to decide who is maintainer: it is defined
> by the last person who uploaded the package. This our do-o-cracy.
> For unmaintained package, we have the [O] bugs in the WNPP pseudo-package.
> If the canonical place for information is the Hub, who will decide who
> is maintainer ?
I don't expect any change here. The maintainer is the maintainer, and the
next maintainer is whoever has been approved by the former maintainer when
we have a package that was not abandoned but properly handed over.
Otherwise it's whoever claimed the package first and in case of big
problems we have the tech-ctte to intervene.
But I truly hope this infrastructure will continue to reduce the
territoriality that has been seen in the past and will continue to
encourage collaboration.
> I think that the source package, and its VCS, are the
> most appropriate canonical place for such information. Now that we
> have “team uploads”, there is less needed to be listed in the Uploaders
> field for occasional help, so the best I think is to use this field
> to record who is responsible, and the Maintainer field to record where
> the information is sent. The Hub you propose will facilitate this a lot.
Yes.
> - <package>@packages.debian.org is a special user for BTS usertags.
> It would be great to integrate these settings in the Hub, and
> perhaps provide some facilities to packaging teams for managing
> these settings globally.
I'm not sure I understand you. Do you want a web interface to manage BTS
usertags?
> - If the Hub could provide a feed in containing all the commits from one's
> team, plus all the commits from his packages, that could be very useful.
> VCS commit messages are becoming an integral part of the information flow in
> package development. But on the other hand, I spend more and more time
> deleting commit messages that I do not read. As an example, I have packages in
> the Debian Med and Debian Perl and Science repositories, but I do not want to
> read all the commits of the Debian Perl and Science team, in which my
> participation is far lower than in the Debian Med team.
Good point. Note that if you properly setup the PTS integration with your
repositories, you'd already have this today.
I read the commits of the developers-reference but not all the other of
the debian-doc SVN repository. And I get them via the PTS.
> Lastly, perhaps the DEP can discuss brifely why a new development is necessary,
> compared to using or extending existing tools, such as Launchpad or other
> forges.
Do you feel like suggesting a text for this? To me it seems obvious that
there's not much in common with Launchpad or a forge and that we're
building an infrastructure tailored to the very specific use case of the
Debian project.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: