RFC: remove qt-copy

[Sune Vuorela]

On 2009-05-25, Aaron J. Seigo <aseigo at kde.org> wrote:
> --nextPart5537885.rdAQ807pBK
> Content-Type: text/plain;
>   charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> hi all ...
>
> since it's finally come up on the kde-commit list, i'd like to make a "form=
> al"=20
> proposal regarding qt-copy, namely:

I don't know how the workflow nor the patch extraction is going to work
with using kde-qt git repository, so there might be some things I have
missed, and I do also not have that much git experience.

but. 

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)

With my current git knowledge, diffing two git branches does not give me
the same seperated patches.

So basically, how do I get a overview like:
http://websvn.kde.org/trunk/qt-copy/patches/
at the qt gitorious site and easily browse the individual patches

And how do I get all the patches in a simple manageble directory like I
get by svn co'ing the above mentioned dir ?

If I still can get the information I need easily (And learn a bit of
git), I don't mind changing.
If I need to be a git guru to get the information I need, I think
something should be changed in the kde-qt git repository.

/Sune

>
> Proposal
>=2D------------
> * Use http://qt.gitorious.org/+kde-developers/qt/kde-qt instead of qt-copy
> * Remove qt-copy from our svn repository after a post-announcement grace=20
> period (so that we don't pull the rug out from under people)
>
> Details and Benefits
>=2D---------------------------
> Any KDE developer can be added to the kde-developers team and thereby have=
>=20
> commit access, just as we do now.
>
> Keeping kde-qt up to date with Qt upstream can be done via gitorious, which=
>=20
> should make it easier for us.
>
> It fits directly into the Qt Software development team's daily workflow=20
> meaning that the odds of our patches getting upstreamed increases.
>
> It removes a bit more burden on our svn server and we can probably stop wit=
> h=20
> things like the apply-patches stuff. Less overhead and time =3D=3D good, an=
> d=20
> people won't have to know about apply-patches to make it all work.
>
>
> Downsides
>=2D---------------
> It means using git, not something everyone is comfortable with. This is nea=
> rly=20
> a moot point, however, as that move seems inevitable; while there isn't=20
> unanimity on the topic (and I doubt that's realistically achievable; it's a=
>=20
> little like whitespace conventions ;) there as an apparent general consensu=
> s=20
> on the matter.
>
> It means checking out and building Qt again.
>
>
> Implementation
>=2D--------------------
> Someone will need to make sure that all of our patches are already in kde-q=
> t=20
> if they aren't already.
>
> Someone will need to update any articles on Techbase that refer to qt-copy =
> and=20
> provide a step-by-step on how to use kde-qt. This might be a nice exercise =
> in=20
> starting to put together a "Using KDE's git repositories" information we'll=
>=20
> need in the future anyways (assuming that the KDE git transition does actua=
> lly=20
> occur)
>
> Someone will need to provide a formal announcement so everyone has a heads =
> up=20
> along with pointers to the above instructions.
>
> Someone will need to actually remove qt-copy from svn after the grace perio=
> d=20
> following the announcement (1 week? 2? 3?).
>
>
> Thoughts? Opinions?
>
>=2D-=20
> 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
>
>
> --nextPart5537885.rdAQ807pBK
> Content-Type: application/pgp-signature; name=signature.asc 
> Content-Description: This is a digitally signed message part.
>
>
> --nextPart5537885.rdAQ807pBK--
>