Ubuntu's Qt Base packaging in Debian git

Dmitry Shachnev mitya57 at debian.org
Fri May 22 15:53:48 UTC 2015


Hey,

On Fri, 22 May 2015 12:19:21 -0300, Lisandro Damián Nicanor Pérez wrote:
> 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.

Yes, I fully support moving the packaging to Git. Even though I am
less active in Ubuntu than in Debian, this will help me to know what
the delta is and cherry-pick it to Debian.

Also, Timo sometimes updates the packaging to new upstream versions
earlier than we do that in Debian, and having that in Git is also
helpful in that case.

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

Re the branch naming scheme: I am fine with any scheme, I just want to
document pros of using kubuntu_*:

- We already have kubuntu_unstable branches (created by Rohan) for all
  Qt modules, which currently do not have Ubuntu delta actually applied
  there. I think it's quite confusing.
- kubuntu_* names are already used for KDE and Qt 4 packages. It might
  be easier if our names are consistent.

Timo said that the packaging is for whole Ubuntu, not just Kubuntu.
However the previous Bzr repositories also had kubuntu in their name,
so I don't think anything changes here.

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

Third pro:

- It's git, not bzr :)

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

I agree.

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

Yes, I think that if we have qtbase in Git, then we should have
anything else in Git as well.

We can also convert the old repositories to be Bzr mirrors of the new
Git branches, in case something (CI?) needs it.

--
Dmitry Shachnev
-------------- 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/20150522/42d82d44/attachment.sig>


More information about the pkg-kde-talk mailing list