Re: DEP-2: Debian Package Maintenance Hub
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/
Reply to: