multiple uploaders

[Ross Gammon]

On 05/31/2015 07:55 PM, Reinhard Tartler wrote:
> Hi Ross,

[...] Quick response!

>> I agree in principle. But for me, having two uploaders does not test if
>> there is team commitment.
> 
> I see two ways how to interpret this sentiment:
> 
>  a) the check is not strict enough, and misses many too many
> situations were the package needs help
>  b) the check is too strict, and catches too many actively team
> maintained packages that do have commitment.
> 
> Reading through the comments so far, I don't think you had a) in mind,
> but rather b). Please correct me if I'm wrong.

Neither a, or b :-)

> 
>> It just makes sure that there is more than one
>> person taking care of the package.
> 
> Which is the point of team maintenance, isn't it?

Yes.

> 
>> And this is probably more important
>> for the high profile packages than for some of the more obscure ones. I
>> think it also helps prevent a new team member getting something
>> sponsored into the team, and then running away.
>>
>> If someone suggests a new package is brought into the team, and it is
>> accepted, then the team is making a commitment at that point.
> 
> How can you determine team commitment if only a single person is
> working on the package? How is this better than having the package not
> team maintained?

I would say that if only one person has been uploading a package over a
period of years and doing a good job, there is no need for team
commitment because everything is fine. The team commitment comes if that
person needs help at some point (technically or due to lack of time).

> 
>> When a package gets behind, it is usually because the uploader(s) is/are
>> a bit busy. The team should notice this on the QA page/dashboard and
>> ping the uploader(s) on the list to see what the problem is.
>>
>> If they are temporarily busy, maybe they would be happy with a "Team
>> Upload" by someone else?
> 
> How is that different to a NMU?

Only the changelog entry is different, and there is a series of commits
in the repo instead of a diff attached to a bug.

[...]

> I think Debian already has way too many "QA Teams". I'd rather see
> packaging teams that are responsive and don't just use the team as an
> easy way to divert responsibility.

Agreed. But I haven't seen examples of that (diversion of
responsibility) yet myself.

>> Can I suggest that for new packages:
>> 1. the one intending to ITP asks if the team are happy to bring in the
>> new package
>> 2. there is an "attempt" to find someone else to also love the package?
> 
> It seems to me that the current rule already implements exactly that.
> Can you elaborate how this would look like in practice, and how your
> suggestions is different?

I think we are mixing 1 & 2 up, and they should be separate steps. That
is, if the team accepts a new package is is best if there is more than
one uploader, but not mandatory.

>> I would be happy to try and draft a tweak to the policy if there was
>> consensus (including some guidelines).
> 
> Maybe we could first clarify why the current rule was "useless". Is it
> that too many packages violate that rule? This can be fixed with two
> means: relaxing the rule, or enforcing it. It appears to me that
> people might argue that it is not strict enough, but I'd suggest that
> we first focus on enforcing the rules.
> 

I don't think anyone thinks it is "useless". Everyone is probably happy
to abide by it if required. I only felt the need to write something
because I have observed IOhannes, Jaromir and Ruben have trouble
introducing new packages recently because no-one quickly jumped in to be
a second uploader. IOhannes stated in his recent ITP that he would push
it to collab-maint if no-one came forward. This is a little sad if it is
an obvious mutimedia application. I know IOhannes would take good care
of the package wherever it is. And I guess there would be someone in the
team that would help out if required.

Someone else stated earlier in the thread that allowing the odd package
to have one uploader every now an then also allows room for new
contributors to come in and look for packages to assist with. If all
packages have a "token" second uploader, it looks to a new person like
there is nothing left.

I hope that helps clarify things.

Regards,

Ross

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150531/a584536d/attachment-0001.sig>