kubuntu-council team mailing list archive

[Philip Muskovac <yofel@xxxxxxx>]

Am 09.01.2017 um 23:10 schrieb Valorie Zimmerman:
> On Mon, Jan 9, 2017 at 5:50 AM, Rik Mills <rikmills@xxxxxxxxxxx> wrote:
> > Hi.
> >
> > I sadly have some concerns regarding Simon Quigley's actions and push
> > access to git and ppas.
> >
> > There have now been several 'incidents', including.
> >
> > (1) On 18th Oct 2017 after having been asked not to practice changes on
> > our git LP repos by Clive, Simon pushed all yakkety_archive branches to
> > master branches.
> >
> > (2) On 7th Nov 2017 Simon deliberately deleted ECM and other critical
> > build depends from the KCI ppa during the nightly build, breaking the
> > builds. He was not able to give a reasonable explanation for his actions.
> >
> > (3) On Jan 8/9th he prepared a "surprise" for us by staging without
> > consultation frameworks 5.30.
> >
> > This was despite again Clive asking Simon NOT to push anything.
> >
> > This was inevitably broken as the issues here:
> >
> > https://trello.com/c/J5w6GdXP/246-cleaning-up-the-road-for-frameworks-5-29
> >
> > regarding frameworks 5.29 are still largely unresolved.
> >
> > Simon was aware of this, as several weeks previously when Simon was keen
> > to stage 5.29, this was pointed out to him.
> >
> > Also it is clear that as there were no appropriate commits regarding
> > package lists and dependencies to kubuntu automation,  the workflow in
> > KA readme was ignored.
> >
> > While I like Simon immensely, this series of incidents in my mind calls
> > into question the appropriateness of Simon's ongoing git an ppa push
> > access. Especially after incident (2) where he reassured us that there
> > would be no such repeat and that he would act responsibly.
> >
> > Rik
> After extensive discussion in #kubuntu-council (public channel, join
> us!) we've concluded that
>
> 1. Ninja status for Simon will be withdrawn until he meets with the
> Kubuntu Devels and satisfies them that permission should be restored;
> and
>
> 2. That we need a change in Kubuntu Policy about the git permissions
> granted to all Kubuntu Members.
>
> Therefore, I move and place before the Kubuntu Council the following:
>
> I move to amend the Kubuntu Policies
> (https://community.kde.org/Kubuntu/Policies) by changing
>
> "Members, while not having any upload or bug control permissions, are
> meant to be trustworthy and act in the best interest of the project.
> ~kubuntu-members consequently also are members of all other Kubuntu
> teams that do not have additional requirements other than trust."
>
> to "Members, while not having any git or bug control permissions, are
> meant to be trustworthy and act in the best interest of the project.
> ~kubuntu-members consequently also are members of all other Kubuntu
> teams that do not have additional requirements other than trust."
>
> Once we change the policy, we can remove
>
> In addition, I believe that we should evaluate which of the
> memberships that https://launchpad.net/~kubuntu-members reports are
> relevant and should stay:
>
> “Kubuntu Members” is a member of these teams:
> KDevelop
> Kubuntu CI
> Tomahawk
> Kubuntu Users
> Kubuntu Bugs
> Kubuntu Members - KDE 4 Repository
> Planet Ubuntu
> Ubuntu Members
> Kubuntu Packagers
> Users of the Ubuntu Etherpad instance
>
> Given that not all Kubuntu Members are packagers, perhaps some of
> these should be revoked? Specifically: KDevelop, Kubuntu CI, Tomahawk,
> Kubuntu Members - KDE 4 Repository and Kubuntu Packagers.
>
> Let's thrash this out here before making the changes and announcing
> them on Kubuntu-devel.
>
> Thanks,
>
> Valorie

Hi.

As for 1) I'm in consent with Clive regarding removing ninja status. 
Forget staging, after these incidents I don't feel well about him having 
access to kubuntu-ppa/ppa and /backports.

2)
IMO the 'upload' part can stay, maybe make that 'commit, upload ...' as 
we still use bzr in rare cases.
Section 7.5 needs 'kubuntu-members' removed from it.
I would suggest adding new sections for ~kubuntu-ci and 
~kubuntu-ci-admins which were not in our control back when the policy 
was last updated.

~kubuntu-ci to document that members do not have access to it for 
packaging reasons and that it's locked down to ~kubuntu-ninjas (as only 
people with git permissions need access to the CI)

~kubuntu-ci-admins are members of ~kubuntu-ninjas that are willing to 
help with developing the CI tooling and server administration. 
Permission levels are:
- regular members have access to the jenkins website and can edit and 
update jobs.
- team administrators can add new people to the team and have SSH access 
to the servers.

As for the other teams, some of that is historic:
- tomahawk was created by me and harald and he later added members to it 
to make contributing easer. While not being a KDE project, they have 
always been at akademy and were affiliated with KDE. I now re-owned the 
team to muesli though as I'm not really contributing to it anymore.
- kdevelop was created by me and Matthias Kolberg back at DS 2010 when 
we were trying to set up dailies for kdevelop, which today is done by 
the CI. Later on it was re-owned to the KC because it was a team created 
by us and nobody else wanted to own it.

I would propose to first get the permission changes regarding -packagers 
and -ci out of the way. To change the membership status of other teams, 
we might have to reword "~kubuntu-members consequently also are members 
of all other Kubuntu teams that do not have additional requirements 
other than trust." first.

Now my summary regarding the teams:
- kdevelop: can go, but needs a new owner first
- kubuntu CI: should go, see above
- tomahawk: can go, was never really a kubuntu team, just kind of run by 
us in the beginning
- kubuntu users: badge collection team, does it really matter?
- kubuntu bugs: not sure what the membership even does as mails are only 
sent to direct members AFAIR
- KDE4: the whole team can be deleted
- planet: needed for blog updates
- ubuntu members: required by definition
- kubuntu packagers: should go, see above
- etherpad: can stay as long as it's used

actually, isn't planet and etherpad indirect through ubuntu-members?

Philip