On Friday 22 May 2015 17:26:18 Timo Jyrinki wrote:
> Hi,
> 
> Let's discuss this here. At least mitya57 has wished for Ubuntu's Qt
> packaging to from Launchpad to Debian git, similar to how Kubuntu
> (Ubuntu's KDE flavor) has moved KDE packaging to Debian git branches.
> Lisandro however wanted to discuss this more formally and I agree.

Right, and thanks a lot for this :) Moreover I wanted this to happen on a 
mailing list so we can point people here in case a doubt arises. IRC logs just 
evaporate ;)

> I did a couple of cleanup uploads this week and now put up the ubuntu
> branch of qtbase to git:
> http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/log/?h=ubuntu.
> This can still be easily removed of course and I can go back to
> Launchpad.

As discussed over IRC, let's keep it there until we decide something.

> I was planning to follow mesa
> (http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git) way of using eg
> ubuntu and ubuntu+1 branches.

With my "I really don't understand much of how ubuntu works" hat on I like the 
idea with minor exception: I would keep debian branches as they currently are: 
master for whatever has to go to unstable, experimental, <release>, etc. And 
this just to keep the current workflow, nothing more, nothing else.

> I don't mind doing it either way, both have pros and cons. Like:
> 
> Pros Debian git
> - Closer to Debian where a lot is directly synced from anyway
> - Easier for Debian people to see what Ubuntu is doing differently if
> interested.

I do totally agree here.

> Cons Debian git
> - Limits access to pkg-kde people
> - Brings all Ubuntu commits to Debian git
> 
> Related to the first con, practically all commits in the Ubuntu
> Launchpad branch have been done by people who are both Ubuntu
> developers and Debian pkg-kde members. I also prefer that all changes
> go through those people. Other people in Ubuntu (on the Unity 8 side)
> are used to going through me for Qt patches/changes. And Kubuntu
> people are familiar with going through Debian.

If we keep this as a hard rule to follow, I'm all for it. If someone from 
Ubuntu wants to be able to commit [s]he has to follow the same principles for 
every new contributor: show patches until we know we can trust her/him 
(including workflows, atomic commits, not pushing non upstream-ACKed patches 
except for packages/very very special cases and proper discussing them before 
doing the commit, etc).

I want to stress that this is the same current requirement we have for Debian, 
and we are happy to help people to get familiar with them.

> Now all Ubuntu core developers are technically allowed to upload Qt
> packages, so that's different from Debian. If that happens past me,
> that'd mean I'd need to sync up those changes to Debian git. So this
> process difference is there, even though it's the same as for KDE
> packages' kubuntu branches.

And that also means that if someone uploaded something which should have not 
been uploaded you will not cherry pick that change into our branches, so 
that's totally fine.

> I was currently planning to do this only for qtbase, as that's where
> most of the action happens. 14 Qt packages are directly synced from
> Debian as is, and the rest with modifications (qtdeclarative,
> qtwebkit, qtgraphicaleffects, qtmultimedia, qtsensors, ...) have more
> minor changes than qtbase. Many have just transitional packages until
> the next LTS release.

*If* we follow the approach which we are discussing here I do not mind if you 
extend the usage to other Qt repos, and of curse you are free to do it 
whenever you see fit.

> As said, I can handle it either way and I'm already used to the manual
> syncing process with Debian also for qtbase.

I think the proposal is good and as long as we follow this principles we can 
both join efforts.

Anyone with other ideas/against this?

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Reply via email to