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

Re: nginx



Andrew Sharp schrieb am Montag, den 18. Januar 2010:

> On Mon, 18 Jan 2010 15:11:34 -0700 Jan Ingvoldstad <frettled@gmail.com>
> wrote:
> 
> > On Mon, Jan 18, 2010 at 11:00 PM, daniel
> > <drmartens@gnu.univ.gda.pl<mailto:drmartens@gnu.univ.gda.pl>> wrote:
> > Alexander Wirt wrote:
> > > Lee Azzarello schrieb am Montag, den 18. Januar 2010:
> > >
> > >> I believe this email thread contradicts that sentiment, as Daniel
> > >> went from newbie to backporter in a very short time when the right
> > >> questions were answered.
> > > And I believe that I will reject the backport because I don't think
> > > he can maintain it properly. Maintaining is more than executing
> > > some commands that sombody else told someone.
> > >
> > 
> > Fair enough, I got your point.
> > I'll just build/maintain it for myself then, as I need it anyway.
> > Thanks to all the folks for help and encouragement!
> > 
> > It's repeated examples like these that make me realize why there are
> > so few useful backports, and it also keeps me from contributing.
> > 
> > Perhaps contribution will be appreciated one day, who knows.
> 
> I have to agree.  I find this attitude needlessly snobby.  Of all the
> areas, backporting is the easiest.  It's the natural best place
> for newbies start out and cut their teeth.  There has to be somewhere
> for this to happen, unless those involved have forgotten how they got
> started in the first place.
We can disagree about my words. But anyhow I think I'm right here.
Backports.org is meaned as an addition to stable, usable on stable/production
systems. As with this target I owe my users to take care about the quality of
backports.org. 

I expect a contributor to have experience with the normal debian ressources
like bts, pts, mailinglists and so on. The contributor should be able to fix
packaging problems in backporting, hunt errors in the backport und fill bugs
if the problem is also in the unstable package. 

Security is also a point, a contributor should follow the securitystate of a
package and has to be able to rate how critical the problem is and should be
able to do the right think afterwards [TM]. 

I don't think a newbie has this experience. 

Alex


Reply to: