Team coordination for kde-extras

[Maximiliano Curia]

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..

> - 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.

> - 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.

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.

> 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.

> 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).

Happy hacking,
-- 
"By definition, when you are investigating the unknown, you do not know what
you will find"
-- The Ultimate Principle
Saludos /\/\ /\ >< `/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20160209/3f8d7415/attachment.sig>