RFC: remove qt-copy

[Aaron J. Seigo]

On Friday 29 May 2009, Thiago Macieira wrote:
> Your arguments could be applied to qt-copy patches too.
>
> Should we forbid ourselves from adding any patches at all?

following the guidelines you outlined, i think we can get Close Enough(tm).

will there be exceptions? almost certainly.

but right now we don't deal with these as exceptions and there is clearly 
defined workflow for how things move into qt-copy and ultimately into qt as a 
result. it's all a bit ad-hoc; we do have (unwritten?) guidelines and we try 
and stick to sane practices but that's clearly not enough.

the result is that what should be the exception has become the status quo.

from talking with 3rd party software developers and seeing our own track 
record (that we had a BIC patch in there at one point is really concerning), 
it's very apparent to me that exceptions are ok, but the status quo needs to 
be much more conservative and well defined.


when we are inflexible through the pursuit of perfect solutions ("there are 
exceptions, so we can't adopt this strategy at all") we end up with lesser or 
even no solution. when we can accept that this is the principle we strive 
towards at every turn, even though there will be exceptions, then we end up 
with something that may not be perfect but is a lot closer to it than we would 
have otherwise.

so it is that the attitude that it's perfectly cool for every packager to 
decide on their own set of patches to apply to Qt is just fine as far as we're 
concerned and that we don't really need a defined workflow that prevents this 
should be tossed. Qt devel is opening up, we should take advantage of that; we 
are seeing more 3rd party developers coming online (or at least, so it seems) 
and we ought to take that seriously.


so yes, there will be times when we face an exception here or there, BUT can 
we not achieve:

* the same patch set amongst packages of the same Qt version as much as 
possible (so we don't have different-patches-in-different-versions-in-the-
wild)

* we severely limit ourselves as to what we allow into kde-qt and instead 
focus more on Qt itself (you have provided some good guidelines for this 
already, imho)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090529/043220e7/attachment.sig>