multiple uploaders

[Reinhard Tartler]

Hi Ross,

On Sun, May 31, 2015 at 1:32 PM, Ross Gammon <ross at the-gammons.net> wrote:
> On 05/31/2015 02:58 PM, Reinhard Tartler wrote:
>> Well, it really boils down what we want the team's reputation to be.
>> The rule tests whether or not there is *team* commitment, and for that
>> you need *more than one person* actively caring for a package. If a
>> package fails the "two active uploaders" test, how can you argue that
>> the package was "team maintained"?
>
> Hi Reinhard,
>
> 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.

> 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?

> 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?

> 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?

> This is not meant to be a rant, it is just how I have observed some of
> the other packaging teams operating in Debian.

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.

> 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 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.

-- 
regards,
    Reinhard