[Debian-med-packaging] Sponsoring many uploads

[Andreas Tille]

On Thu, Mar 17, 2016 at 05:28:12PM +0000, Mattia Rizzolo wrote:
> > 
> > As long as we did not had so many sponsors it worked like this.  Do you
> > have a suggestion how to do better.  I personally consider the RFS
> > mechanism via BTS a bit overkill
> 
> I find the RFSes very efficient with this workflow (as I just archive
> the mails for new RFS and when I'm in sponsoring moods I just haed over
> bugs.d.o/sponsorship-requests), but it has the downside of using the BTS
> which is really not the nicest thing to deal with, especially for quick
> packages where

For me more importantly it has the effect that our team RFS just end up
in the huge amount of other RFS.  I simply set my preference onto Debian
Med sponsering.  I also "invented" a way to pick general Blends RFS out
of the dust by "Sponsering of Blends"[1].

>   *) it's OK if the sponsor does some edits on his own (most of the
>      packages I deal with in RFS I review without doing anything on my
>      own, I just report what I want to see changed)

In the Debian Med team we agreed that it is OK if the sponsor is doing
changes if this is more efficient (for both sides).  Sometimes (most
times?) explaining what need to be changed takes more time than doing
the actual change.

>   *) they are usually quite ready and don't need long work; sometimes
>      ITPs or ITAs that come in the RFS queue needs months of iterations
>      between the reviewer/sponsor and the sponsoree... this took 3 hours
>      in total for 4 packages, with long pause in the middle)

I think the sponsees in our team are doing quite a good work and this is
the usual time frame when working on these packages - even less in cases
when I have sponsored a package before and its just an update.
 
> Maybe it's just me and I need to work better on my mail workflow, keep
> RFS (of all kinds, also coming from MLs like this) somewhere separate.

I have some procmail rules that fit my needs for this.

> But a downside that won't go away of method is that it's racy, and it's
> hard to track who is taking care of that given RFS.

We did not yet had this racing condition until, say February this year.
If it turns out that sponsors are doing duplicated work to some extend
we should definitely find some means to avoid this.  On the other hand
I'm really happy about the fact that kind of a niche topic in the Debian
universe is covered by this amount of manpower.
 
> > time consuming.
> 
> Time consuming are very much not.  Nowdays sometimes happen that a RFS
> is already closed after not even 10 minutes.  Rare, but happens :)
> Yet, it's an annoyance for the sponsoree, as they need to either upload
> to mentors.d.n (=> up to 15 minutes of waiting for the package to be
> accepted) and then they have the template (still a template to write),
> or anyway, open a bug which is not really quick to do either.

I admit I fully ignore mentors.d.n since I exclusively build from VCS.
I had cases when I refused sponsering since a package was not in VCS.

> Then, there are no rules there to use mentors.d.n or just git, and
> sometimes people post both details, and everything get messy in my head :D
> 
> I'm quite new at the sponsoring world, I've been a DD for a little more
> than 4 months, maybe I really just need to improve my own workflow.

Thanks anyway that you are helping out in the Debian Med team.  If I'm
not misleaded you do not have a background in the fields we are working
on, right?

> Or maybe I'll develop something in the future to improve everybody's
> workflow, we'll see ;)

Keen on learning some more nifty things. ;-)

Kind regards

      Andreas.


[1] https://wiki.debian.org/DebianPureBlends/SoB

-- 
http://fam-tille.de