I don't think you've said what the problem is with committing to
separate branches, it makes life easier for Kubuntu and doesn't get in
the way of Debian packagers in any way.  But it does allow for merges
to happen if the Debian packager thinks it's relevant.

I quite understand your frustration if people are making commits not
suitable to Debian to the branch used for the debian package, they are
also not suitable for Ubuntu and I've just rejected that qtbase
package from Ubuntu and requested the non-free file to be removed.
However this has nothing to do with the branches used for kubuntu and
plasma phone images.


On Wed, Dec 02, 2015 at 09:58:39AM -0300, Lisandro Damián Nicanor Pérez Meyer 
> 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/

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


Reply via email to