On Sun, Mar 25, 2012 at 11:31 AM, Reinout van Rees firstname.lastname@example.org wrote:
On 24-03-12 20:56, Ross Patterson wrote:
Can we possibly get this branch merged and a release made?
From what I remembered from 2.5 year ago was that the fix was pretty small.
I guess that depends on what you men by small. I don't consider the change small. I would call it straight forward.
I wish this had gotten merged before the 1.5 changes. I'm sorry.
I think I only had to call some setuptools function, basically.
Looks like more than that.
Would it be an idea to move zc.buildout out of the zope svn repo into github?
Yes. In fact, I was just looking at that. Github's review mechanism is particularly attractive.
(AFAICT, bitbucket doesn't have a review/comment process like github's. All I see is the ability to accept or reject pull requests. I only know either from reading docs. If I'm mistaken, please correct me, as the review process is what makes me lean toword github.)
It is quite central to many non-zope projects and nobody outside of zope is going to bother with a contributor agreement, I think.
Yes, although I don't think that's the main problem. (Don't argue this with me, it's just an opinion. :)
And some extra outside effort into buildout would be nice.
Absolutely. I think the code needs a drastic simplification to enable that.
A good thing about github (or xxx or yyy) would be the ease of pull requests. And a pull request coupled with a visible bug report "scripts don't work" stands more chance of being included than a 2.5 year old simple fix in some branch with some old mailinglist messages.
Not sure about that. I think the integrated review support would definitely be accretive.
And... I'd love a list of current maintainers of zc.buildout that are allowed to commit to trunk.
Um, any svn.zope.org committer is technically allowed. I realize that's not what you're asking, but ...
iirc Jim only works on the python 3 port
Not intentionally. :)
("1.5.x is too hard to understand now")
Unfortunately, the Python 3 port (aka buildout2) was based in trunk/1.5. I don't understand it either. ;)
I spent a few hours yesterday poking at the 2 branch trying to find a way to attack simplifying it. My suspicion is that it would be easier to start from 1.4, although that will require redoing the Python 3 port. <whimper>
As an aside, I'm wrapping up an OS project that I've been working on for the past few months, so I'm ready to spend some focussed time on buildout.
and the 1.5.x trunk itself hasn't seen any development lately as far as I could see, despite people being stuck on 1.4.x. So... who's maintaining buildout right now?
Theoretically, I am, as are various helpers. Thomas Lotze put in a bunch of work last year trying to help me clean up the 2 branch. I appreciate his efforts, but it wasn't enough....
A little bit was done on the trunk (and ported to the 2 branch) in a sprint last fall.
I would love to move to a more team-based approach. I really don't want to be in charge. I certainly don't want to be a blocker. OTOH, someone will beed to protect simplicity, if we ever achieve it.
I think to make contributors more effective, we have to simplify the code a lot. (We also need better docs, but that's another issue.)
Here's a possible plan:
- Create a github repo from svn.
Not sure the best apprach to this. I was thinking of using svn2git to copy the zc.buildout svn project.
Someone with git foo could help with this, although this wants to be soon. (Like nowish :)
- Create a new branch from 1.4.4.
(Don't know the proper git terminilogy for this, as I don't know git yet. :)
- Remove support for multiple Python interpreters in a single buildout.
- Remove setuptools support (just use distribute).
- Think of ways to simplify the code, or more importantly, the tests.
Maybe provide some test infrastructure to make setup and assertions easier.
At this point, I think it should be easier for people to contribute.
- Merge reinout-scripts :)
- Change some defaults (always unzip, prefer final, etc.)
- maybe rename the project to buildout, thus avoiding backward compatibility issues.
- Release buildout 0.1 (not zc.buildout).
- Port to 2&3 (one codebase as was done for the 2 branch).
- Cherry pick changes since 1.4.4.
This would, of course, include better interaction with system Pythons including:
- Simple isolation from site customization (ala -S),
- Better behavior when not isolated (recognize and don't override system-installed projects),
- Better failure. When not isolated and something goes wrong give better error messages.
- Work with virtualenv.
This needs to be done more simply than what was done in 1.5. (Again, FTR I appreciate the huge effort that went into 1.5.) I have some ideas for this.
Releasing along the way.
- New hotness (and releases)!
- Somewhere along the line, when we think we aren't going to break things for a while, release 1.0.
- Port to d2/p.
Thoughts? Anyone wanna help (take over :)? Wanna maybe sprint via IRC?
P.S. I'm happy to let someone else (preferably a team) be in charge, but I have no intention of washing by hands of buildout.
-- Jim Fulton http://www.linkedin.com/in/jimfulton