kdev-python move to extragear -- once more

[Sven Brauch]

Hi Pino,

considering kdev-python is only using the Parser part of python, this
is actually all that has changed in the two years between 2.7.1 and
2.7.3:
http://paste.kde.org/691184/
As far as I can see, there's not a single change which would affect
the behavior of kdev-python in any way. And I do not expect such
changes to happen in further maintenance releases -- after all,
they're maintenance releases for fixing bugs, and the Python 2.7
*parser* code does not exactly have hundreds of bugs. And, since
Python 2 is dead anyways, no non-maintenance releases are going to
happen.

If it was only about this -- I could easily keep the fork updated with
the 2.7.x releases. But, as said, I don't really see a point, since
it's not going to affect kdev-python anyways. I see even less reason
for why anyone other than me should ever want to do such an update,
since it will most likely be a) irrelevant for  kdev-python or b) do
some changes which would actually affect kdev-python, but would then
need updates to kdev-python itself since it's very tightly integrated
with the parser code.

Still, altough I don't agree with the two points you raised, I see
your overall problem with this, and you can rest assured that I'm very
much interested in getting the fork removed as soon as possible too
(see my previous emails). So, if this is your last word, I'm going to
move kdev-python back to playground, wait for the Python 3.4 release,
and start the whole review process once again. It's not really going
to change much -- most distributions will still package kdev-python
and the fork is not going to be removed any sooner. It's just a bit
more annoying.

I'm not angry or anything, after all this is a review and if there was
no negative outcomes then it would be pretty pointless. I just wished
you would list reasons I could agree with -- there's the general "a
fork is a horrible solution", which I totally agree with, but which is
a rather philosophical point. I'm still missing an example of a real
world situation where this fork specifically would be a problem.

Best regards,
Sven

2013/3/9 Pino Toscano <pino at kde.org>:
> Hi,
>
> Alle sabato 16 febbraio 2013, Sven Brauch ha scritto:
>> A while ago, I asked for a review of kdev-python, in order for it to
>> be moved from playground to extragear. There was some (legitimate)
>> objection about the fork of the python parser code the plugin
>> contains, which is why the move has not taken place yet, and
>> kdev-python is still residing in kdereview.
>>
>> I'm actively working on solving the issue -- chances that a patch can
>> be applied upstream which enables me to drop the fork are good. [1]
>> (This would however only apply to future releases of the python 3
>> version of the plugin, since the patch introduces binary-incompatible
>> changes upstream which cannot be backported to python 2.)
>>
>> Thus, I would suggest to move kdev-python to extragear, even if the
>> issue is not solved yet.
>> If you disagree, let me know, in that case I must move kdev-python
>> back to playground and propose it for review again once the fork has
>> been removed from the master branch. I would however prefer not to do
>> this.
>
> Considering the libpython fork in kdevpython is:
> a) outdated (it is forked from python 2.7.1, current 2.7 is 2.7.3);
>    considering 2.7.1 has been released on 27/10/2010 and 2.7.3 on
>    9/4/2012, this means it is one years and half behind fixes and
>    improvements of any kind
> b) modified (so it is not totally pristine sources which can be updated
>    from upstream sources, if needed)
>
> this situation still makes me put -1 on this, sorry.
>
> I can understand it can seem frustrating having this kind of situation,
> but as both KDE developer and distro (Debian) developer I cannot find
> acceptable letting yet another case of embbeded code copy [1] in a new
> "extragear" software, yet more so when the software copied is something
> critical as python. As said in previous emails, this would put a non-
> trivial burden over packagers (and potentially also over self-compiling
> users).
>
> [1] OTOH you are not the only one -- hello Gilles Caulier!
>
> --
> Pino Toscano