[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, 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.
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
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:
- 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
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