kdev-python move to extragear -- once more

Milian Wolff mail at milianw.de
Tue Mar 12 09:17:06 GMT 2013


On Saturday 09 March 2013 12:13:08 Pino Toscano wrote:
> 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).

Pino, could you please respond to Sven's last email? Please confirm, that your 
reasonings above are unchanged even though we are speaking about a fork of the 
*parser* not of the full python library (i.e. no code is executed!).

If you are really still against merging a parser fork, then what do you 
propose to do? Esp. considering that Sven already tried to contact the Python 
developers multiple of times?

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130312/585ea861/attachment.sig>


More information about the kde-core-devel mailing list