Quoting Ximin Luo (2017-01-05 16:26:00)
> Jonas Smedegaard:
> > 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.)
I welcome suggestions for how we might identify and maybe even kick
inactive users. I won't spend time proposing or defending such
procedures myself, as I find no need for them (we use this team only to
exchange emails and exchange git repos - each of us is responsible to
validate each email and each git repo!!!).
I (loudly!) oppose treating not-yet-members as inactive: Improving
security by minimizing activity is a luxury we cannot afford!
> > 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
> > to contribute to Debian in other ways than continuous mainenance).
> This is why I suggested having them apply individually later.
I disagree that requiring individual membership requests helps.
Some are inspired to join when alone and seeking friends, other are
inspired to join when with friends also joining, or when meeting and
working concentrated for days with a role model - as I guess might be
the case for (some or all of) these applicants.
> 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 packages.
I sure hope you are telling me how *you* find it fun to collaborate.
If you are imposing on me and others in this team the reasons we should
find it fun to be here, you are effectively *discouraging* anyone with
different personality than yourself. Please embrace variety!
> Another issue that I noticed is some of the requests were very vague.
> (Other requests were suitably specific.) I hope these are fixed the
> small, it would also be good to mention more numbers of packages in
> these requests.
Since when did we validate membership based on how they formulated
their requests to join?
Were you yourself treated with scrutiny when you joined, then I
appologize on behalf of the team, and kindly ask you to not repeat that
flawed attitude towards newcomers.
or alternatively - if this team generally appraise such attitude, I will
respect that by leaving the team, as I personally appreciate the *lack*
of hierarchy in Debian.
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private