Re: Ubuntu's Qt Base packaging in Debian git
Then I think we have consensus :-D Just one note on my side: On Tuesday 26 May 2015 08:51:29 Timo Jyrinki wrote: [snip] 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. Yes. There will be some ugly patches in Ubuntu not suitable for Debian. A good example is this one on a certain phone, a driver reports a wrong feature to Qt and we can't fix the driver at the moment. Right. Some may be more middle ground or inspiring, like the alternative qmake build for armhf cross-building. In this case it would be awesome if we can discuss them on irc and see if they are fit to be pushed upstream or if we can help upstreaming them in some other way. Ubuntu devs also upstream + cherry-pick many bug fixes, and those can be cherry-picked to Debian easily if they seem serious enough. As a rule of thumb backporting merged stuff it's a very nice idea if the fix is important enough, yes :) -- So long, and thanks for all the fish! The Hitchhickers guide to the Galaxy Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Ubuntu's Qt Base packaging in Debian git
2015-05-22 18:19 GMT+03:00 Lisandro Damián Nicanor Pérez perezme...@gmail.com: 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. Sure, I only meant the naming of the Ubuntu branches. 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 Absolutely. At this point I don't see others joining Qt packaging from Canonical side of Ubuntu people, but that can always change. I'm sometimes away but that doesn't necessarily require new pkg-kde members. Let's see if a need arises. 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. Yes. There will be some ugly patches in Ubuntu not suitable for Debian. A good example is this one on a certain phone, a driver reports a wrong feature to Qt and we can't fix the driver at the moment. Some may be more middle ground or inspiring, like the alternative qmake build for armhf cross-building. Ubuntu devs also upstream + cherry-pick many bug fixes, and those can be cherry-picked to Debian easily if they seem serious enough. 2015-05-22 18:53 GMT+03:00 Dmitry Shachnev mity...@debian.org: - 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. I was also wondering about those, but as discussed on IRC, they're related to Kubuntu's CI efforts. Maybe they'll move, or maybe they'll rebase on the Ubuntu branches (once available). 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. The kubuntu-packagers team in Ubuntu was selected for continuation in 2012, as Qt 4 was there too. But it has been confusing for many, and Ubuntu is the umbrella term for the Qt using Ubuntu flavors which already include Ubuntu, Kubuntu and now Lubuntu in this cycle. - It's git, not bzr :) That's starting to be an obsolete point, as Launchpad has just started to support git :) https://help.launchpad.net/Code/Git Anyhow, that'll probably help in setting up true mirrors instead of gateway'd ones. Yes, I think that if we have qtbase in Git, then we should have anything else in Git as well. That's true, maybe not immediately but with moving to Qt 5.5 it'd be natural. -Timo -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Ubuntu's Qt Base packaging in Debian git
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. 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. 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. 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. 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. 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. 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. As said, I can handle it either way and I'm already used to the manual syncing process with Debian also for qtbase. -Timo -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Ubuntu's Qt Base packaging in Debian git
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 signature.asc Description: OpenPGP digital signature -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
