Hi all, as you might have already noticed, Python 2.4 is out. It's nice that things are going onwards, with the drawback that we have a lot of work with such a change, because most of the dependent ports will break. I don't have a clear position how we should deal with such a situation. The python dependent ports, maintained by me, works well after rebuilding, but some will probably not, e.g. bittorent-curses. ok, what can we do ? 1. commit python 2.4 now, fixing all dependent ports 2. wait for CRUX 2.1 3. ... I tend to go with 1. To prepare this, I've added a python 2.4 port to my private repo [1]. What do you think ? thanks for your attention and kind regards Jürgen [1] http://jue.li/crux/ports/#python -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
On 05/12/2004 14:10 Juergen Daubert wrote:
Hi all,
Hi Juergen,
as you might have already noticed, Python 2.4 is out. It's nice that things are going onwards, with the drawback that we have a lot of work with such a change, because most of the dependent ports will break.
ok, what can we do ?
1. commit python 2.4 now, fixing all dependent ports 2. wait for CRUX 2.1 3. ...
I tend to go with 1. To prepare this, I've added a python 2.4 port to my private repo [1].
What do you think ?
I like option 3 :) Seriously, I think committing now is a good idea, also because it's one less thing we have to care for 2.1 Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
--- Simone Rota <sip@varlock.com> wrote:
Hi Juergen,
I like option 3 :) Seriously, I think committing now is a good idea, also because it's one less thing we have to care for 2.1
Regards, Simone
-- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
I agree as well - it would be best to take care of it as soon as possible. A README notifying people to: prt-get update `prt-get dependent python` Should be prepared and included with the new port. Actually as the first line of build() in the Pkgfile you could cat the README. Users would have plenty of time to skim through it as the 2.4 sources download. Perhaps a "Heads up" mail to the main list would also be wise. Juergen, you don't maintain *all* the Python-dependent ports..let's not forget Gay Media Player. I suck, <3 Jay ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Hi, On Sun, Dec 05, 2004 at 06:43:13 -0800, Jay Dolan wrote:
--- Simone Rota <sip@varlock.com> wrote:
Hi Juergen,
I like option 3 :) Seriously, I think committing now is a good idea, also because it's one less thing we have to care for 2.1
Regards, Simone
-- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
I agree as well - it would be best to take care of it as soon as possible. A README notifying people to:
prt-get update `prt-get dependent python`
Or prt-get lock python, as an alternative. This leads me to another consideration: we could extend the commit guideline proposal to denote binary incompatible changes as well, to enable tracking of those. And - as discussed on IRC - we could trigger e-mails with a CVS post commit hook, checking for the few keywords (security, binary incompatible) and sending out a warning to a dedicated CLC commit-info list. Any opinions on this? At least for me, it would be helpful to have such additinal information available easily. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 05/12/2004 18:06 Johannes Winkelmann wrote:
This leads me to another consideration: we could extend the commit guideline proposal to denote binary incompatible changes as well, to enable tracking of those. And - as discussed on IRC - we could trigger e-mails with a CVS post commit hook, checking for the few keywords (security, binary incompatible) and sending out a warning to a dedicated CLC commit-info list. Any opinions on this? At least for me, it would be helpful to have such additinal information available easily.
I'm afraid some binary-incompatible changes would be a bit tricky to detect: there could be cases in which having a port introducing _some_ incompatibility could not necessarily imply that all depending ports are affected. Apart from this, I think we have a couple of options to notify binary incompatibiities: - put the info in cvs as suggested and let the user do the upgrade - updating the affected dependent ports (bumping the release number) If we're going to support / facilitate the use of binaries I think the 2nd solution is preferrable (even if it brings up coordination issues between maintainers). Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
On 05/12/2004 18:06 Johannes Winkelmann wrote:
This leads me to another consideration: we could extend the commit guideline proposal to denote binary incompatible changes as well, to enable tracking of those. And - as discussed on IRC - we could trigger e-mails with a CVS post commit hook, checking for the few keywords (security, binary incompatible) and sending out a warning to a dedicated CLC commit-info list. Any opinions on this? At least for me, it would be helpful to have such additinal information available easily.
I'm afraid some binary-incompatible changes would be a bit tricky to detect: there could be cases in which having a port introducing _some_ incompatibility could not necessarily imply that all depending ports are affected.
Apart from this, I think we have a couple of options to notify binary incompatibiities: - put the info in cvs as suggested and let the user do the upgrade - updating the affected dependent ports (bumping the release number) Sure, but in order to detect possible (forseeable) problems, an automatic notification would be nice; this way, Jürgen could commit his
Hi, On Sun, Dec 05, 2004 at 18:11:35 +0100, Simone Rota wrote: port with a message, and wait until maintainers of dependent ports catch up, and finally tag it. I think it should be a combination of both options you suggest. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On December 5, 2004 6:10, Juergen Daubert wrote:
ok, what can we do ?
1. commit python 2.4 now, fixing all dependent ports 2. wait for CRUX 2.1 3. ...
How about committing now, and tagging/branching python 2.4 and related ports as CONTRIB-2_1, rather then 2_0? Shouldn't a non-trivial update like python wait for at least a point release of CRUX? I'm publishing a bunch of python-dependent ports in my httpup repo, and am hoping to bring kdebindings back from the attic when KDE-3.3.2 is released--and am reasonably certain that pyqt (the basis for kdebinding's python support) does not support python-2.4. Koffice also has a tendency to exibit crash-happiness, when dependant packages are newer then its release. I'm not sure exactly how to do it, but I'm pretty sure that with a command like "cvs branch CONTRIB-2_0" one can switch back to CONTRIB-2_0 as the current working tree. Updates to python-related packages will probably be python 2.4 fixes from here on out, yes? This means that switching back to the CONTRIB-2_0 branch in order to update python-related packages should be rare. Why not keep our solid python 2.3 implementation for now--and limit the bugs to a CONTRIB-2_1 branch? Shipping bleeding-edge is for ricers. (http://funroll-loops.org) I have nothing against imports, btw. Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Juergen Daubert wrote: | 1. commit python 2.4 now, fixing all dependent ports | 2. wait for CRUX 2.1 | 3. ... I like option 1 as well. It's not too much work, in my opinion, and will save time later on. Matt (jaeger@freenode/#crux) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBtLLLGFVQ7mavvGgRAtrrAJ903mAp4gonE3ZGMJmENG9cTVtl+QCfUvXi d0iNZyeCScboGlvw2236kEg= =vToU -----END PGP SIGNATURE-----
On Mon, Dec 06, 2004 at 01:28:11PM -0600, Matt Housh wrote:
Juergen Daubert wrote: | 1. commit python 2.4 now, fixing all dependent ports | 2. wait for CRUX 2.1 | 3. ...
I like option 1 as well. It's not too much work, in my opinion, and will save time later on.
ok, looks like a clear vote. I'll commit the port today. kind reagrds Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
participants (6)
-
Jay Dolan -
Johannes Winkelmann -
Juergen Daubert -
Matt Housh -
Nick Steeves -
Simone Rota