kdev-python move to extragear -- once more

[Albert Astals Cid]

El Dissabte, 9 de març de 2013, a les 12:13:08, Pino Toscano va escriure:
> 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).

So what is your solution? Kill him? Make him wait 1 year before he can release 
his software? I agree this is not optimal, but if there is no other way to do 
it, then there's no other way to do it, or would you block kpdf on the basis 
that it embedded xpdf code?

Cheers,
  Albert

> 
> [1] OTOH you are not the only one -- hello Gilles Caulier!