On Wednesday 02 December 2015 10:58:41 Jonathan Riddell wrote:

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 

[*] 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.


Hope that explains my position, Lisandro.

17: Cual es la funcion inicial de un antivirus
    * Desarrollar virus para vender el producto
    Damian Nadales

Lisandro Damián Nicanor Pérez Meyer

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


Reply via email to