Hi, On Sat, 28 Jan 2012, Paul Wise wrote: > This proposal has a lot of potiential to change Debian for the better, > thanks a lot.
Glad to see that several persons are sharing my enthusiasm. :-) > I had planned to work on the BTS IRC bot from #debian-devel-changes > and enable it to forward stuff to more channels based on package name, > but it sounds like this proposal obsoletes that bot too. It could be interesting to put this as a service within this infrastructure. Currently the only place where I mentionned IRC was for personal notifications directed to a package maintainer. But extending such a bot to allow teams to configure notifications on their channels would be welcome indeed. > I guess this proposal could also obsolete the low threshold NMU list: > > http://wiki.debian.org/LowThresholdNmu Yes, it should. > The DMUA mechanism currently depends on Maintainer/Uploaders, how do > you see DEP-2 interacting with it? Personally I would very much like > the DMUA mechanism go away and be replaced by something much more > explicit (my initial thought was an OpenPGP-based mail bot). I don't envision any change for this currently. One of the key points is that the introduction of this infrastructure should not impact other Debian services (to ease its acceptance). > One thing that I have always wanted to see was better connections > between Debian and our users. Would this also enable say these? > > * the QA team to notify users a package is about to be removed > * the security team to notify users they need to update > * package developers to ask people to test a new feature I would say no. At least at the start. This is something that can be reconsidered later though. In particular if we decide to enlarge the scope to also try to replace packages.debian.org. > I wonder what kinds of commitments we might want people to document > about packages, some thoughts: > > I use foo but could easily switch to something else. > I use foo rarely but want it to be available when I do. > I use foo often and it is an integral part of my workflow. > I have access to commit upstream on foo. > I am willing to triage bug reports on foo. > I am willing to review VCS commits on foo. > I am willing to fix only RC bugs on foo. > I am willing to do usual package maintainence. > I want to know when foo is updated in stable. Yeah, that sort of stuff, although some your entries are not really commitments. My own list would be: - I will take care of RC bugs in unstable - I will take care of RC bugs in testing - I will take care of security updates in testing - I will take care of security updates in stable - I will package new upstream versions in unstable - I will triage incoming bugs - I will forward upstream bugs Then separately it would be nice to document why one is maintaining a given package: - because it's a build-dependency I need for "foo" - because I use it a lot - etc. > I wonder if this discussion should be brought to > debian-project/debian-devel, especially the maintainer/commitment > stuff will be quite far reaching. As discussed with Zack, this part of the discussion will be separate from DEP-2. But yes, this should be discussed on -project. > As someone who has done a few PTS patches, I would welcome the > technology changes you plan. I do worry that not using static HTML > will reduce the performance though. We will definitely have to be cautious here. That said there are multiple levels of caching that are possible, and I bet it should suffice to keep good performances in most cases. > I wonder about the alioth FusionForge instance and how this will > interact with it. Not much, alioth will remain the VCS-hosting & ML hosting & web hosting service that it is currently. The other functionalities (trackers) are seldomly used by packaging projects. Something that I question a bit more is http://wiki.debian.org/Teams as I would love to have this information standardized in the database of this new infrastructure. OTOH, the free from structure of this wiki page is also a benefit in many cases. 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/20120128145604.gm4...@rivendell.home.ouaza.com
