On 2011-08-14, Dominik Psenner wrote: > sorry for the late response. This sunny sunday took me for a trip into > the mountains. :-) See the inlines below.
I live further up north in Germany (guessing from your name) so it hasn't been as sunny around here 8-( >> The normal state of an ASF project is that all people who contribute >> code on a regular basis have write access - if they want it. > I would not advise to commit to the ASF SVN repository directly. Changes > put into SVN are carved into stone and immutable FOREVER. Mercurial > allows a more flexible way for working on things. Just read this mail to > the end to get there. :-) I did, and I'm sorry that won't happen as it simply is not the way ASF projects operate. Immutable history actually is an asset. One thing I've noticed when following github projects and similar constructs has been that they have a hard time building a real community. Too much focus is put on code and branches and not much on agreeing how to move forward and actually collaborating. It is too easy to simply create your own branch, go off and say "I know better" rather than search for a compromise. Yes, I am oversimplifying and generalizing here. The ASF model forces all people working on the project to build consensus on what goes into the project. This helps to have a real community behind the code base - *the* code base as there is only one. And a community rather than a few single devs who know better is what makes a project sustainable and allows it to survive if the original devs go away. I really do appreciate what you've set up and I do understand the model you describe has advantages and disadvantages over how the ASF works traditionally, but it is at odds with the ideals of the ASFs in some areas. > You may ask yourself how we can discuss on a changeset if the others > don't know about it? Mercurial offers some very convenient ways to share > information between developers. One is to publish the information in a > repository so that others can pull that information into their local > clone (that's how mercurial works after all) or the other way would be > to mail a patch to this list so that others can import it and comment on it. See, we prefer to discuss on the mailing list - not in JIRA and not in code via patches. Discussions in plain English (or what people like me consider English ;-) are easier to follow when you want to revisit them five years later. Yes, this happens. The "why did we decide to use X instead of Y" questions do come up. >> The normal process is that a committer resolves the JIRA issue once the >> code is in svn. Sometimes the user who opened the issue will close it >> after the fix has been verified but this is truely optional. > Yes. Right now we can only comment on issues, which is obviously not > enough to be productive. We should contact some people @ JIRA so that at > least one of us gets write privileges to the repository and > administrative privileges to the bugtracker ASAP. This is on the way. Stefan
