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/
Description: This is a digitally signed message part.