[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [list.debian.project] two questions for DPL nominees

>  - non-free archives?

The thing that would make me happiest would be for everything in non-free to 
be obsoleted by some better piece of free software.  Until / unless that 
happens, my take on this from a practical standpoint is that we should leave 
non-free alone.

In passing, let me mention the 'vrms' package, which I dreamed up and Bill
Geddes wrote after an email exchange with RMS about non-free.  While it 
doesn't directly relate to where we host non-free (and has some bugs that I
think Stephen Moraco is addressing), it can be a useful tool for those of us 
who care what dependencies we might have on non-free software. 

>  - sluggish new maintainer process?

As a general principle, I want there to be *some* inertia in both the new
maintainer and MIA maintainer processes.  It became quickly obvious to me 
while serving as an AM shortly after we restarted the NM process that the DM 
is the rate limiter on how quickly new applicants complete the process.  It's
not clear to me that we have a big problem, but if elected, I will review our 
DM's workload with him, and discuss ways of making sure the other jobs he 
does for Debian don't interfere with timely processing of applicants.  
>  - Maintainers who are MIA

The processes by which we manage maintainership clearly need to continue to
evolve.  I joined Debian on the strength of one piece of introductory email
from Bruce Perens to Ian Murdock, at a time when we didn't even sign uploads.  
While we've come a long way since then, we are not yet explicitly managing 
the complete "lifecycle" of a maintainer in our organization.  

There are a number of maintainer responsiveness issues that I think we might 
address, of which this is arguably the most detrimental.  It's important to
remind ourselves that Debian is a volunteer organization, and interact with 
each other accordingly.  However, anyone who accepts maintainership of a 
package is making some currently-unarticulated commitments to the rest of our 
community that shouldn't be abandoned lightly.  Setting up a process to 
identify, contact, and take action to recover from MIA maintainers makes 
complete sense to me.


Reply to: