Ian Bicking
2009-10-29 20:44:09 UTC
In an effort to make it easier to contribute and manage patches to
FormEncode, Paste*, WebOb, and other libraries, I have moved
everything to bitbucket. You can see the repositories here:
http://bitbucket.org/ianb/
Or, more specifically FormEncode
(http://bitbucket.org/ianb/formencode/) and a bunch of Paste-related
libraries:
http://bitbucket.org/ianb/paste/
http://bitbucket.org/ianb/pastedeploy/
http://bitbucket.org/ianb/pastescript/
http://bitbucket.org/ianb/webob/
http://bitbucket.org/ianb/webtest/
http://bitbucket.org/ianb/scripttest/
http://bitbucket.org/ianb/tempita/
http://bitbucket.org/ianb/wsgiproxy/
I'd like to use these repositories somewhat similarly to how
Subversion is used: most development should happen in these specific
repositories. If you have (and use) commit to one of these projects
in Subversion, I'd like to give you write access to the main
repository. If that's the case, PLEASE EMAIL ME (off list) with your
bitbucket username and the projects you'd like access to. I'm
generally pretty open to giving commit access to people who have been
around and I know (even if only online), since I've found most people
to be appropriately self-limiting (e.g., anyone should feel
comfortable fixing a typo in a docstring, but API changes require
discussion).
If you want to do something experimental, or something you might do in
a branch in Subversion, I'd prefer these be forks. Mercurial branches
are appropriate for maintenance branches (e.g., bug fixes on a stable
branch), but otherwise I don't think they are as convenient as a fork,
and they are more error-prone.
I have not definitively decided what to do with issue trackers. There
is an issue tracker on bitbucket, and it is functional though not
really anything special (though it requires very little maintenance).
FormEncode uses SourceForge, while the others all use a single trac
instance. I don't want to split issues between multiple systems, so
I'd only want to switch to bitbucket if existing (open) tickets were
moved over. So... mostly I'm just throwing this out there as an
option, if someone is up to doing the work to migrate tickets. If
someone was willing to setup a rig to do distributed issue tracking,
that would also be of interest to me (at least to experiment with).
FormEncode, Paste*, WebOb, and other libraries, I have moved
everything to bitbucket. You can see the repositories here:
http://bitbucket.org/ianb/
Or, more specifically FormEncode
(http://bitbucket.org/ianb/formencode/) and a bunch of Paste-related
libraries:
http://bitbucket.org/ianb/paste/
http://bitbucket.org/ianb/pastedeploy/
http://bitbucket.org/ianb/pastescript/
http://bitbucket.org/ianb/webob/
http://bitbucket.org/ianb/webtest/
http://bitbucket.org/ianb/scripttest/
http://bitbucket.org/ianb/tempita/
http://bitbucket.org/ianb/wsgiproxy/
I'd like to use these repositories somewhat similarly to how
Subversion is used: most development should happen in these specific
repositories. If you have (and use) commit to one of these projects
in Subversion, I'd like to give you write access to the main
repository. If that's the case, PLEASE EMAIL ME (off list) with your
bitbucket username and the projects you'd like access to. I'm
generally pretty open to giving commit access to people who have been
around and I know (even if only online), since I've found most people
to be appropriately self-limiting (e.g., anyone should feel
comfortable fixing a typo in a docstring, but API changes require
discussion).
If you want to do something experimental, or something you might do in
a branch in Subversion, I'd prefer these be forks. Mercurial branches
are appropriate for maintenance branches (e.g., bug fixes on a stable
branch), but otherwise I don't think they are as convenient as a fork,
and they are more error-prone.
I have not definitively decided what to do with issue trackers. There
is an issue tracker on bitbucket, and it is functional though not
really anything special (though it requires very little maintenance).
FormEncode uses SourceForge, while the others all use a single trac
instance. I don't want to split issues between multiple systems, so
I'd only want to switch to bitbucket if existing (open) tickets were
moved over. So... mostly I'm just throwing this out there as an
option, if someone is up to doing the work to migrate tickets. If
someone was willing to setup a rig to do distributed issue tracking,
that would also be of interest to me (at least to experiment with).
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker