Sponsorship Process (Was: Re: Packaging Help)

[Stephan Hermann]

Moins,

On Mon, 28 Sep 2009 18:50:48 -0400
Daniel Chen <seven.steps at gmail.com> wrote:

> On Mon, Sep 28, 2009 at 6:35 PM, Mackenzie Morgan <macoafi at gmail.com>
> wrote:
> > Yep yep. Theoretically, subscribing the sponsors is all you have to
> > do. But then we all know the difference between theory and reality.
> 
> I suppose that's a really good reason to encourage active contributors
> to seek MOTU privileges if they aren't already.
> 
> > and all that.  But it seems many sponsors have no idea what to do
> > when asked "can you sponsor this?" and pointed to a bug with a
> > branch attached.  AFAICT,
> 
> Sponsors _need_ to know what to do when asked to sponsor something. I
> would go as far as to say it's a responsibility that comes with the
> privilege of uploading to universe and multiverse.

Most of the Sponsors are knowing the way of how to do something, they
know the workflows...but really, having a branch attached or a patch
file attached, doesn't matter.

As an uploader you have responsibility that you understand what you are
uploading and for some software you need to have a deeper look into the
code and understand what's happening. If you as uploader don't
understand the code, would you upload it without this knowledge?

 
> In fact, it sounds like a prime developer classroom - or even Open
> Week - session.
> 
> > they have to branch trunk and your branch, then manually bzr merge,
> > then upload.  It makes more sense to me to just have a "Merge!"
> > button on the Merge Request page in LaunchPad (only for people with
> > permissions to merge into that package's branch, that is).  That'd
> > be easier even than debdiffs for the sponsors, I think.
> 
> While that's a great longer term approach, we still need to address
> the issue of blocking on uploads. And, as Scott mentioned a few
> moments ago, it's really incumbent on the potential sponsors to follow
> through with due diligence, some of which is esoteric.

TBH, it doesn't matter how the change comes in, via bzr branch,
debdiff, bunch of simple-patchsys patch files or quilt patch files...
Important is that you understand what's going on with the application
you patch, when you patch it.

Really, it's easy to pull in in fixes for e.g. Security issues, but
more important is, that you have a test case which shows that this
issue you patched is really fixed.

That's one of the reasons, why I decreased my involvement in the
security area...for some apps (especially web stuff) I know what the
patch fixes, and I know in theory how to test that...but I'm really too
"stupid" to convert public exploit code into a valid test case. (For
that reason I have some other people doing security audits)

Regarding all this, someone needs to decide what's more important:
Doing the Prio 1 topics, or pulling in some patches which needs more
time to investigate into a not so well known source.

Regards,

\sh
-- 
| Stephan '\sh' Hermann    | OSS Dev / SysAdmin         |
| JID: sh at linux-server.org | http://www.sourcecode.de/  | 
| GPG ID: 0xC098EFA8	   | http://leonov.tv/          |
| FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 |