RFC: remove qt-copy

[Aaron J. Seigo]

On Monday 25 May 2009, Sune Vuorela wrote:
> On 2009-05-25, Aaron J. Seigo <aseigo at kde.org> wrote:
> > --nextPart1663294.0fHKoBbkBR
> > Content-Type: Text/Plain;
> >   charset="us-ascii"
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Monday 25 May 2009, Sune Vuorela wrote:
> >> The current way of doing things for me (in debian) is to take the
> >> released qt tarballs and read over the patches dir of qt-copy and
> >> delicately pick the ones I think is relevant and understandable (these
> >> factors is also influenced by commiter and names in the patch)
> >
> > erf ... are we sure that having packagers decide which patches are best
> > is = a=20
> > better mechanism than having this done upstream in KDE? that sounds like
> > a= =20
> > great way to have various functionally incompatible versions of Qt out
> > ther= e=20
> > with the reasons for those differences depending on the understanding
> > and=20 motivation of the packager.
>
> You already have that - various functionality differences - and packagers
> also randomly patches kde and whatever else they ship. Packagers also apply
> patches to qt that aren't part of qt-copy.

... and this is all complete and utter folly.

> Welcome to open source.

just because we do things stupidly now isn't a justification to continue on 
doing things stupidly.

and freedom is not an excuse for encouraging bad practice, either. freedom is 
there to give us the ability to do what we deserve to do and need to do. we 
shouldn't use that freedom as a justification for doing foolish things.

> The packagers are first in line for issues in the distribution. Why
> shouldn't they have the last word in what they ship?

because they don't know enough about what we deal with on a daily basis at the 
level of understanding we do to make those calls. similarly, i don't know 
enough about packaging to do your job.

> If it is hard to figure out why a specific patch is needed, then you
> (plural) haven't done the work of documenting it good enough.

i don't think it's your job to figure out why a patch is needed. that's our 
job. i don't make debian packages, i don't see why you'd need to become a 
patch manager for Qt.

> > i'd much, much rather see a "you pick either qt or kde-qt" world. two
> > versi= ons=20
> > of Qt is already too many if you ask me and hopefully in this brave new
> > wor= ld=20
> > kde-qt will simply become a staging ground for the changes KDE needs in
> > Qt= =20
> > itself and everyone just packages Qt directly.
>
> Is kde-qt going to have regular releases? 

they are sync'd to upstream Qt releases, so this is a non-issue.

> What happens the day someone
> accidentally pushes some BIC change to kde-qt at the time the
> distributions choose to snapshot it?

we don't do BIC changes

-- 
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/20090525/d35b8925/attachment.sig>