Team coordination for kde-extras

Tue Feb 9 02:24:05 UTC 2016

On Tuesday 09 February 2016 00:29:30 Maximiliano Curia wrote:
> On 02/02/16 16:16, Lisandro Damián Nicanor Pérez Meyer wrote:
> > I won't remove it for now until we clear up this then.
> 
> I've pinged Kubuntu developers via irc to participate in this discussion,
> I've changed the subject to reflect the topic of the discussion.
> 
> > - The shared repos where for the *kde* side of the team, not kde*-extras*
> > nor Qt.
> 
> When we agreed to have shared repositories we didn't mention that kde-extras
> was special, so it's understandable that they didn't know about this..

I agree on this one.

> > - kde-extras is a special case in itself. Each repo belongs to it's
> > principal maintainer(s). We can, as a team, do updates from time to time
> > but *always* with the ACK from the principal maintainer(s). In case of
> > long absences in which the maintainers are not reachable we can of course
> > notice the fact in this very list, wait some days (normally 5 is fine)
> > and then contribute to the repo doing the best effort to keep the
> > maintainer's workflow. That's team work.
> 
> This is something that is not written and different people may have
> different expectations. As far as I see it, the status quo of team packages
> is that if the Maintainer names the team, then changes from the team
> members are welcome, what you describe is what I would expect to be the
> workflow when the Maintainer field doesn't list the team.

To the best of my knowledge that's not the status-quo in this case, but old 
timers can easily probe me wrong.

> > - We can't overtake a repo without asking the original maintainer(s)
> > first.
> > Again, team work. For the kdeconnect special case I don't know the status
> > of this, I asked recently and it seems my question was misinterpreted.
> kdeconnect is one of those packages where the Maintainer field is not the
> team, and so changes should be coordinated. However, we are not talking
> about overtaking a repo but rather creating a sibling directory for the
> plasma version. Still, I understand that this has created confusion,
> particularly because the repo contains a master branch that is not in use
> and contains an old version.
> 
> There is a technical problem related to the fact that git is a pain if you
> don't have a master branch, so the repositories created by kubuntu
> developers (that mostly don't touch the master branch) start with whatever
> they had the moment they created it (may be an old debian package, an old
> ubuntu package, an empty file, whatever). Instead, for cases like this it
> would be better to use the --allow-empty flag, that allows one to create an
> empty branch.
> 
> It's been a year since the creation of this separate repo so it's hard to
> know exactly what happened in this case. Instead, we should focus on how we
> would like to operate in the future for cases where Kubuntu wants to
> package something independently of what already exists (for example because
> the maintainer is not responsive or doesn't want the repository to have
> additional kubuntu branches).
> 
> I think that in this case the clearest way would be to put the repository
> under the pkg-kde/kubuntu/ hierarchy, so that it's clear that it's a repo
> used only by Kubuntu and avoids any further confusion.

And then we should have yet another one for every distro that asks us for 
this?

> For team maintained packages, I believe it's fine for them to do their work
> in the kubuntu_* branches, as this does not interfere with the work that we
> do for Debian.

Except we are giving them permission to commit everywhere, anybranch.

> > Now following kdeconnect's situation as an example. We might have two
> > possible outcomes:
> > 
> > - It is agreed with the maintainer to use a new repo for the plasma5/qt5
> > version. Tis is cool, but in this case do not imort old history, as we
> > consider this a new source.
> > 
> > - It is agreed that we keep the old repo. In this case use branches as a
> > special case. Of course, that fits well in Debian's normal workflow,
> > having
> > separated branches for Ubuntu stuff just gets things complicated in my
> > opinion, but...
> 
> I believe that the right thing to do with this now is to merge the kubuntu_*
> branches from kdeconnect-plasma into kdeconnect, and start working from
> there. To avoid breakage, kdeconnect-plasma should become a symlink to
> kdeconnect.

Might work, but we are still talking about kde*-extras* now.

> > I might have missed something, but we really need clear rules to play
> > along as a *team* who cares about *Debian* and not as to different
> > entities sharing repos. In this last case I would simply prefer not to
> > share anything.
> Working together is hard and it's going to generate conflicts when it's
> unclear how we should operate, but it's important that we concentrate on
> trying to find out a way of making it work because we all benefit from not
> having to do the same thing twice (once we have figured out these issues).

We all benefit? Sorry, I don't agree. We would all benefit if changes where 
*correctly* done (+/- fixes, nobody is perfect) in Debian's master branches 
and having the delta's in Ubuntu's branches. The way I see it currently works 
is "it is better because you can check ubuntu's changes and get them from the 
same repo". If that where true we should also share repos with each and every 
other distribution out there.

Sorry, this *is* Debian, the first goal should be Debian, not $otherdistro.

-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20160208/737e1d71/attachment.sig>