> Quoting Ximin Luo (2017-01-05 13:51:00)
>> The security aspect is just one factor, not the main factor.
> Ok, you now tell me that security is not the main factor.
> I clearly read your previous email as if security was the main factor
> for rejecting these requests. For clarity of discussion I shall
> *ignore* the security factor.
>> But to give more detail, (a) just because we have "little" security,
>> doesn't mean we have to make it quantitatively worse, which we will do
>> if we add anyone that asks - it adds surface area. And (b) the
>> standards of time and continual maintenance that I described
>> elsewhere, also indicates that a person is careful about their general
>> computing practices, which also helps to not-reduce security -
>> compared to giving access to a random person.
> Do I understand you correctly that in your opinion the main factor is
> devotion to continued mainentance?
I agree it's the main factor, but for me this is also linked to security.
Having lots of inactive people with that level of access increases risk with no
benefit in return. It's better to have fewer active people. (Of course lots of
active people are even better.)
> If so, then we agree on what is "main factor" - but still we disagree on
> how to then deal with it:
> It seems Praveen find it reasonable to approve "because they are ready
> to upload their packages", and it seems you find that exact situation
> reason for rejecting. I find it neither reject nor approve reason.
> I welcome into this team any and all persons who feel they are ready to
> *maintain* official Debian packages. I find it wrong to impose
> restrictions on that, but I want to emphasize _maintain_ - this team is
> contribute to Debian in other ways than continuous mainenance).
This is why I suggested having them apply individually later. They can see if
they're comfortable with doing this semi-regularly. Everything is more fun at a
group event but this is not the same as robust long-term maintenance of
Another issue that I noticed is some of the requests were very vague. (Other
requests were suitably specific.) I hope these are fixed the next time around.
to mention more numbers of packages in these requests.