[lxml-dev] Codespeak shutting down: migration plans?
Dear colleagues, As a long-time user of lxml I was shocked to read a message today from Holger Krekel about the end of Codespeak (see full text at the end of this). First we need to thank Holger for all these years of free service. Then we need to quickly plan and execute a migration to some other repository. I am willing to help, but I am no core developer of lxml, and in fact this is my first message ever to this mailing list, so I think we need someone better known to this community to lead the migration effort. lxml as a key piece of the Python ecosystem and for the benefit of its present and future users and the wider Python community we need to make sure it continues to be available, and to make sure as many references (pypi!) as possible point to the new canonical repository. Finally, a big thank you to Martijn, Philikon, Stefan and all the others who have built this great piece of software. Cheers, -- Luciano Ramalho programador repentista || stand-up programmer Twitter: @luciano ######################################### hi codespeak.net users, (sorry if you get mail twice, i wanted to make sure ...) after 8 years of operation codespeak.net services are bound to terminate, starting END OF FEBRUARY 2011 Background: one of the original codespeak purposes was to offer subversion (then in version 0.17) for the PyPy and other projects but today this is not too interesting given the pletora of VCS hosting solutions. Also, there aren't too many admins besides me, the hosting is costing money, PyPy's repository has moved to Bitbucket and i am re-shuffling my priorities preparing for my soon to emerge father-hood. After February 2011 i probably won't be able to help much with any transition issues or questions. The host will keep on running for a while but i give no guaruantees. Some remarks regarding termination wrt to the FEB 2011 deadline: * the subversion repo will turn read-only (and will eventually be switched off). * Shell accounts will be restricted to those people who need it *and* mail me about it. Some time later they will be gone as well. * Mailing lists will be terminated as well unless i get a mail asking me to postpone termination for a specific time. You can go to your respective mailman admin page and extract a list of members. If you mail me i can also provide a list of members. * Any remaining web docs/pages will probably continue to exist for a while but i also prefer them to be moved away by end Feb 2011. Note that the codespeak svn repository contains a lot of projects. For migration you have two options: do a flat import just of your project checkout directory into a new version system. This is super-simple, obviously. If you want to preserve history for your project please mail me and i either provide you a full dump or a filtered dump only containing your project. So long and I hope you all had a good time and enjoyed the services and also have a good transition now. see you in other places, holger krekel _______________________________________________ codespeak-ann@codespeak.net http://codespeak.net/mailman/listinfo/codespeak-ann
Luciano Ramalho, 10.02.2011 11:12:
As a long-time user of lxml I was shocked to read a message today from Holger Krekel about the end of Codespeak (see full text at the end of this).
So was I. And I'm not aware of any April-1st-like day anywhere on this planet right now. Actually, even if it's going to be some work to switch mailing list and web site, I think the most painful thing will be getting the current links to "http://codespeak.net/lxml" diverted to the new place (many of the links are in blog entries that will never get updated) and convincing the web search engines that this new place is just as good as the old one. Then again, searching for "python xml" gives me good-ol'-dead-and-gone PyXML as top hit in Google, so that needs updating anyway.
First we need to thank Holger for all these years of free service.
Yes, I'm also grateful about the support in the past years. Thanks, Holger.
Then we need to quickly plan and execute a migration to some other repository.
I am willing to help, but I am no core developer of lxml, and in fact this is my first message ever to this mailing list, so I think we need someone better known to this community to lead the migration effort.
I've just created a repo at github. https://github.com/lxml/lxml There's nothing there yet, but given that I already switched to hg-svn a while ago, I have the complete trunk history available that I could just push. I'm not sure what to do with the maintenance branches, though. It would be nice to preserve them as well, at least the 2.2 line. I could convert them and just hang them in as separate repositories. Opinions? I've also been looking for a better issue tracker than launchpad for ages. github could provide that as well (I mean, seriously, anything is better than launchpad), but that's not urgent and the main problem is getting at the current set of issues to move them over... One project I could use help with is the web site. I'd like to migrate it to Sphinx. Shouldn't be hard, but it's not a quick action either. This includes the PDF version, for example. That's not urgent, but if we switch web sites anyway, it would be a good time to get it in shape. Any help with that would be appreciated.
lxml as a key piece of the Python ecosystem and for the benefit of its present and future users and the wider Python community we need to make sure it continues to be available, and to make sure as many references (pypi!) as possible point to the new canonical repository.
Again, any help is welcome.
Finally, a big thank you to Martijn, Philikon, Stefan and all the others who have built this great piece of software.
You're welcome. Stefan
Hi,
First we need to thank Holger for all these years of free service.
Yes, I'm also grateful about the support in the past years. Thanks, Holger. +1
Then we need to quickly plan and execute a migration to some other repository.
I am willing to help, but I am no core developer of lxml, and in fact this is my first message ever to this mailing list, so I think we need someone better known to this community to lead the migration effort.
I've just created a repo at github.
And just as I was about to ask if the lxml repo should switch to mercurial... ;-)
There's nothing there yet, but given that I already switched to hg-svn a while ago, I have the complete trunk history available that I could just push.
I'm not sure what to do with the maintenance branches, though. It would be nice to preserve them as well, at least the 2.2 line. I could convert them and just hang them in as separate repositories. Opinions?
Are there any "established" best practices for dealing with maintenance branches in distributed vcs? From skimming mercurial docs I got the impression that named branches living in the main repo might fit the bill. What about the release tags? I suppose they are already preserved in the repo history, as they are just some symolic name for a revision/changeset (?) My daily routine is still svn-centric and I haven't used hg but for the simplest "track some changes" use case - never used git so far. Holger -- Schon gehört? GMX hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://www.gmx.net/de/go/toolbar
jholg@gmx.de, 10.02.2011 13:57:
Then we need to quickly plan and execute a migration to some other repository.
I am willing to help, but I am no core developer of lxml, and in fact this is my first message ever to this mailing list, so I think we need someone better known to this community to lead the migration effort.
I've just created a repo at github.
And just as I was about to ask if the lxml repo should switch to mercurial... ;-)
Well, I used it for a while now. Maybe I should have given a note about it on the ML.
There's nothing there yet, but given that I already switched to hg-svn a while ago, I have the complete trunk history available that I could just push.
I'm not sure what to do with the maintenance branches, though. It would be nice to preserve them as well, at least the 2.2 line. I could convert them and just hang them in as separate repositories. Opinions?
Are there any "established" best practices for dealing with maintenance branches in distributed vcs? From skimming mercurial docs I got the impression that named branches living in the main repo might fit the bill.
Well, there are basically two ways: branches (in-repo) and separate repos. I think separate repos generally make more sense for maintenance branches where you explicitly want things to diverge (and a trunk user really won't care about a 1.3 branch). In-repo branches are better for short-lived experiments, collaboration, etc. In both cases, it's easy enough to cherry-pick patches from one branch to the other.
What about the release tags? I suppose they are already preserved in the repo history, as they are just some symolic name for a revision/changeset (?)
Tags are a problem, yes. SVN doesn't readily provide tag information, it sees tags and branches as simple directories. And most tags in lxml originate from the maintenance branches, so that's even trickier to re-engineer. I don't currently have that information in my hg repo at all.
My daily routine is still svn-centric and I haven't used hg but for the simplest "track some changes" use case
Here's a good read then: http://hginit.com/
- never used git so far.
Well, I keep being disgusted by git, it just feels so wrong each time I can't help using it. From a German POV, the name is really well chosen (basically means 'yuk!'). Stefan
Are there any "established" best practices for dealing with maintenance branches in distributed vcs? From skimming mercurial docs I got the impression that named branches living in the main repo might fit the bill.
Well, there are basically two ways: branches (in-repo) and separate repos. I think separate repos generally make more sense for maintenance branches where you explicitly want things to diverge (and a trunk user really won't care about a 1.3 branch). In-repo branches are better for short-lived experiments, collaboration, etc. In both cases, it's easy enough to cherry-pick patches from one branch to the other.
Not sure if this is out of date feature-wise but PEP 374 talks about "git cherry-pick doesn't work across repositories; you need to have the branches in the same repository." (http://python.org/dev/peps/pep-0374/)
What about the release tags? I suppose they are already preserved in the repo history, as they are just some symolic name for a revision/changeset (?)
Tags are a problem, yes. SVN doesn't readily provide tag information, it sees tags and branches as simple directories. And most tags in lxml originate from the maintenance branches, so that's even trickier to re-engineer. I don't currently have that information in my hg repo at all.
Here's a good read then:
Thanks. This might be of help for the strategy for handling of branches/tags: http://www.python.org/dev/peps/pep-0385/#transition-plan Though I don't see anything on keeping correct tags, on first glance.
Well, I keep being disgusted by git, it just feels so wrong each time I can't help using it. From a German POV, the name is really well chosen (basically means 'yuk!').
Read "it just feels so wrong each time that I can't help but using it" or "it just feels so wrong each time when I can't help using it"? 8-) Holger -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
Stefan Behnel, 10.02.2011 13:09:
I've just created a repo at github.
... and now recreated it as an organisation. I think that makes more sense. Stefan
Stefan Behnel <stefan_ml <at> behnel.de> writes:
Stefan Behnel, 10.02.2011 13:09:
I've just created a repo at github.
... and now recreated it as an organisation. I think that makes more sense.
Stefan
Actually the other issue is that codespeak is the registered location for releases of lxml for setuptools eggs. Could they be distributed elsewhere? Jon (author of PsychoPy which uses lxml. Thanks! ;-) )
Jonathan Peirce, 22.07.2011 22:10:
Stefan Behnel writes:
Stefan Behnel, 10.02.2011 13:09:
I've just created a repo at github.
... and now recreated it as an organisation. I think that makes more sense.
Actually the other issue is that codespeak is the registered location for releases of lxml for setuptools eggs. Could they be distributed elsewhere?
Right. I had already fixed the links in the sources back when I switched to github, but also changed them on PyPI now.
Jon (author of PsychoPy which uses lxml. Thanks! ;-) )
You're welcome. The website seems to lack a link in the dependencies section, though... Stefan
participants (4)
-
jholg＠gmx.de -
Jonathan Peirce -
Luciano Ramalho -
Stefan Behnel