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/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120130081820.gm25...@rivendell.home.ouaza.com
