RFC: remove qt-copy

Thiago Macieira thiago at kde.org
Fri May 29 07:11:35 BST 2009


Aaron J. Seigo wrote:
>On Thursday 28 May 2009, Alexander Neundorf wrote:
>> On Tuesday 26 May 2009, Aaron J. Seigo wrote:
>> > 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 better mechanism than having this done upstream in KDE?
>> > that sounds like a great way to have various functionally
>> > incompatible versions of Qt out there with the reasons for those
>> > differences depending on the understanding and motivation of the
>> > packager.
>> >
>> > as a software developer, that runs chills (and not the good sort)
>> > down my spine.
>>
>> I fully agree, but that's what is simply the case today for many
>> packages and for many distros, they ship patched packages.
>
>patching shared libs is very different than patching applications or
> even shared infrastructure.
>
>and just because it's "how it is" doesn't mean it's good. it just means
> that's how it is.
>
>we don't need to support poor practice in the future just because it's
> what we've done in the past.
>
>that all sounds obvious and perhaps even simplistic when written in
> black and white. but it's not obvious and it's not at all simple.

Your arguments could be applied to qt-copy patches too.

Should we forbid ourselves from adding any patches at all?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090529/0fbc74eb/attachment.sig>


More information about the kde-core-devel mailing list