kdev-python move to extragear -- once more
Pino Toscano
pino at kde.org
Tue Mar 12 09:57:57 GMT 2013
Hi,
Alle sabato 9 marzo 2013, Sven Brauch ha scritto:
> 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.
And the rest of the Python library API, like the stuff in Python/* and
Object/*?
> 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.
Bugs, leaks, and any kind of issue don't need to "affect kdev-python" to
be problematic.
Assuming you need to cherry-pick later some bugfix from python 2.7.x,
what do you do if that backporting cannot be done because the code has
changed in the meanwhile, and your code is still years behind?
> 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.
"people will package it" is not really an excuse for "allow broken
ways".
> 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.
You are misreading my words: I never said that "a fork is a horrible
solution" in general, but I was referring, in this case, to the
libpython fork you did.
(And WTF does it mean «I just wished you would list reasons I could
agree with», that my reasons are valid as long as you agree with them?)
> I'm still missing an
> example of a real world situation where this fork specifically would
> be a problem.
There were many, provided by Sune Vuorela or myself, in various emails
of this and the intial review thread [1].
[1] «Review of kdev-python for move to extragear»
--
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130312/992b5a12/attachment.sig>
More information about the kde-core-devel
mailing list