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

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team



On Friday 01 June 2012 20:08:22 Jonas Smedegaard wrote:
> On 12-06-01 at 06:06pm, George Danchev wrote:
> > On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote:
> > 
> > Hi,

Hi,

> > > > ...hence the Sponsors (who are also a full-fledged DDs) are
> > > > responsible. It is that simple.
> > > 
> > > If it's really that simple, one should never sponsor a package one
> > > doesn't care to maintain.  If this is the case, we should just do
> > > away with sponsorship and require the uploader to be either
> > > Maintainer or in Uploaders unless it's an NMU (note: I don't think
> > > this is what we want).
> > 
> > I don't think this is that black and white indeed. In the case of
> > unresponsive non-DD maintainer, obviously the Sponsors (having more
> > powerful pedals and knobs than the sponsoree wrt to the archive) have
> > several courses of action (in no particular order; various
> > combinations are also possible):
> > 
> > * step in and maintain the package themselves
> > * ask for help, search for co-maintainers, etc
> > * suggest orphanage
> > * you name it
> > 
> > and I guess this is a very basic, but fairly sufficient measure to
> > handle the the case of run-away non-DD maintainers.
> 
> Sorry if I am dense, but those pedals and knobs look like maintenance
> ones to me: 

Maintaining a package via long series of non-invasive NMUs does not declare  
maintainership (I meant pedals as in sponsors are able to upload without their 
sponsoree). It is just inconvenient for both the maintainers and the end 
users, and should be a temporal measure in the ideal case (and yes, I know we 
have packages in the archive effectively maintained via NMUs for many years).

> Simply relabel the sponsor as maintainer as Scott
> (non-)proposes and it _is_ black and white to me.
> 
> I am genuinely interested in understanding the reasons for labeling
> sponsoree rather than sponsor as maintainer.  Could you (or anyone)
> elaborate on that?

Maintainer field is meaningless, it is very meaningful. Why not just think of 
it this way (hopefully this could make you sleep better :) - If a Maintainer 
field points to a non-DD entity and that entity disappears from the horizon, 
then a DD-entity (the Sponsor [1], the Safeguard if you want) should do 
something meaningful to help to resolve the situation. This is not to say that 
the DD-entity (the Sponsor) is then allowed to perform hostile acts and all 
sorts of unlawful interferences (e.g. a hijacks) in the terms of the Debian 
normative docs.

[1] http://udd.debian.org/sponsorstats.cgi

-- 
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>


Reply to: