On Wednesday 26 February 2014 11:09:56 Jonathan Riddell wrote: > On Wed, Feb 26, 2014 at 11:21:49AM +0100, Harald Sitter wrote: > > To me the solution then seems to revise kubuntu-dev membership criteria > > and > > control? If they are competent and trustable enough they should become > > member of kubuntu-dev as that attributes technical knowledge (and could > > easily get added a 'technical trustworthy' attribute). > > Membership of kubuntu-dev implies membership of kubuntu-members. Asking in > #ubuntu-devel just now > > 10:30 < xnox> Riddell: to become a developer, one needs to show a > sustained contribution for more than one cycle, so yeah > 6+ months is requirement for developers. > > Allowing informal membership of kubuntu-packagers and kubuntu-ppa is a > nice stepping stone to tell people they are valued and trusted > contributors before we can give them full -membership or -dev > privilages. > > (And I still think 6 months is too long for -membership or -dev, > building community needs letting people in without too much barrier, > one of the aims of Ubuntu was to allow a lower barrier of entry than > Debian.)
So it's a larger ubuntu issue and should be discussed as such. Bringing me back to the original argument that if a person cannot be formally trusted and accepted into one of the existing teams, then everyone must review all new changes in every bzr branch before uploading as otherwise they might be uploading something that is not as good as it ought to be, or at the worst malicious content. ~kubuntu-packagers holds the qt packaging which is also meddled with by ubuntu developers who would rightfully assume that only formally trusted people can commit changes there. However, that would no longer be the case if we add people informally to that team simply because we decide to trust their abilities enough. So we'd then potentially lure !kubuntu members into uploading potentially bad or malicious content because they did not know that we have a lax policy on who gets to change the official packaging branches. And that is why neither kubuntu-packagers nor kubuntu-ppa should be directly joined. We have trust validation processes in place (becoming kubuntu-dev or kubuntu-member), if the time barriers to join those are too long, then a resolution/exception should be sought in ubuntu at large, not work around the perhaps ludicrous barrier by allowing people to sneak in changes even though they really shouldn't be able to sneak in anything anywhere. On a related note, what I just thought of: currently the exceptions read that manual additions to the teams happen at the discretion of the council, which is slightly silly if the argument is that individuals might be competent enough, as the only team able to asses that is ~kubuntu-dev and not ~kubuntu- council. HS -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
