kdeconnect repos mess

[Lisandro Damián Nicanor Pérez Meyer]

Replying on-list, Maxy told me that he's reply was intended to the list.

On Tuesday 02 February 2016 11:31:16 Maximiliano Curia wrote:
> On 01/02/16 21:33, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Currently we have two repos for kdeconnect:
> > 
> > = http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect.git/
> > 
> > = http://anonscm.debian.org/cgit/pkg-kde/kde-extras/kdeconnect-plasma.git/
> 
> The first one was the kde4 version of kdeconnect, the second one was created
> by kubuntu to work on the plasma 5 version of kdeconnect, and is still in
> use by them (check the branches kubuntu_xenial_archive and
> kubuntu_unstable).
> > - But simply removed the git history from the above one, pushing
> > everything as a single commit. Bad.
> 
> It should be easy enough to merge the branches to gain back the history from
> the other repository.
> > So what on earth I am supossed to do with these ones?
> > I'm tempted to keep the original one because it keeps the correct history
> > and remove the other one, which is useless for Debian.
> 
> Don't remove it, ping Riddel if you think something different should have
> been done. We pushed to have shared git repositories with Kubuntu, it
> doesn't matter it there things that aren't useful to Debian anymore.

I won't remove it for now until we clear up this then.

But please take into account:

- The shared repos where for the *kde* side of the team, not kde*-extras* nor 
Qt.

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

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

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

Now, as Scott has once proposed on IRC: let's try to get a common ground here 
with clear rules. There is no other way to act like a team, if that's what we 
really want to achieve.

I'm listening you now.

-- 
Trabaja como si no necesitaras el dinero.
Ama como si nunca hubieses sido herido.
Baila como si nadie estuviera mirando.
Canta como si nadie escuchara.
Vive como si fuera el Cielo en la Tierra.
  Anónimo

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/20160202/4fcbb142/attachment.sig>