On Wednesday 02 December 2015 10:58:41 Jonathan Riddell wrote: [snip] Hi Jonathan! > I created the kubuntu_vivid_mobile branches. Kubuntu developers have > been using Debian pkg-kde git for some years now in an effort to share > resources and allow earier cooperation. This was done at the request > of Debian pkg-kde as well as Kubuntu developers. It allows for > branches to be easily merged and changes to be cherry-picked.
The original agreement was for KDE-related packages, not Qt. And this was for what I consider good reasons, please read below. > In this case it's packaging needed for the phone images > http://kubuntu.plasma-mobile.org/ which needs newer versions of Qt on > older base systems so it won't be anything that's useful to merge into > other branches but its what allows our work to be used in an > interesting end product. Can you explain what problems it causes? Maybe the problem comes from me mixing ubuntu and kubuntu, but allow me to share how I see this, as until now for me they are the same thing. There is a huge difference between KDE stuff and Qt in terms of ubuntu. Qt is part of the core of Ubuntu and so it's repo can be modified not only by people listed in Uploaders but also by external developers. And I have seen quite a lot of commits coming from external people that we would have not been taking for different reasons. One example is the one I'll point you below. The other point of interest is that we Qt maintainers (historically maybe from the times where I was just learning to package) don't want no one not listed in Uploaders pushing stuff to our branches without our previous consent (read it: show me the patch). The fact that we don't have ACLs was one of the reason I was against sharing the repos in the first time. Currently anyone who can commit in KDE's repos can commit in Qt's ones, as you have found out :) So far I haven't seen any benefit of this model for us yet [*], but only more noise. [*] Excluding mitya57's and Mirv's commits, but they are DDs listed in Uploaders who follow both projects and act accordingly. So in the way I see it so far it would be better if you have a clone of the repos somewhere else (having triggers to keep them synchronized in the debian → [k]ubuntu path is of course totally possible) and manage your branches and users there. Having said that I'm open to discuss other ways of collaboration which might or not include sharing repos. But I still fear that if we allow derivative A then we need to allow derivative B and then C and then... And for every derivative we need to add new users who can commit anywhere... Having triggers if of course something else. This is something we can set up quite easily and easily control. > Kubuntu has very strong politices for upstream patches and free > software. I've found myself recently bullied out of Ubuntu for > defending its free software policies. If you can point me to any > non-DFSG additions I'll be the first to remove them. This patch re adds non-dfsg-compliant RFCs to the archive. Timo told me it was added by the QA people. It comes from Ubuntu, not Kubuntu, which might or not be the difference. <http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/patches/enable-tests.patch?h=ubuntu> Hope that explains my position, Lisandro. -- 17: Cual es la funcion inicial de un antivirus * Desarrollar virus para vender el producto Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Description: This is a digitally signed message part.