till: It's up to you guys if you want to help to improve the ispconfig project or work against it by splitting the development without contributing back.
The irony of that comment is, as I said, that it would be easier for me to fork the project on Github and continue by myself than to have to deal with antiquated and disjointed project tools. Just my opinion but if you truly want more community input then using Github is a clear path forward to enable many more contributions. Your guarded approach tends to stifle innovation and experimentation and even if I, or anyone else, did, or has, forked ISPConfig then there is nothing stopping anyone from cherry picking the best parts back into "upstream". Of course if you are not using Git and/or Github then it makes it that much harder to cherry pick between separate and different repository types.
Personally I have no intention of ever using Subversion ever again. No point, Git/Github totally destroys any incentive to bother. As I said, and say it again, it would be easier and less time consuming for me to fork the entire ISPConfig project to Github and continue by myself than to deal with... crazy stuff from last century.
till: Why is it not so easy to contribute?
Because you are not using Github. How can you possibly compare "sending a patch (set) via email" to a one-click fork of the entire project and then a one-click pull request that can then be reviewed and commented upon using the included issue tracker which very nicely sends emails to all involved, and replies to those emails go back to the issue tracker for all to see.
I appreciate you going into the complexities of dealing with the codebase in your previous comment, it is indeed a very large and complex project, so much so it deserves a decent project work flow to match and assist that complexity. The right way to manage contributions is via branching. You could have a "testing" branch for just that and then anything that survives scrutiny in that branch gets merged into a "next" branch which would be like RC release quality . When the folks that like fiddling with the latest codebase indicate all is well then next is merged into the master branch which could be the canonical single point of release quality code. No real need for versioned release tarballs. Any problems and just roll back some troublesome commits in the master branch that somehow managed to get through the testing and next branches.
On top of that, every man and his puppy can experiment in as many local branches as they care to, go completely nuts and try anything out locally, go wild, and when something sticks that could be useful upstream then... click on pull request and bingo, some new code starts on a trajectory towards the master release branch. Most of the problems you cited could be far better managed using Git (via cheap branches) and Github just doubles, even trebles, the benefits of using Git.
Last edited by markc; 4th March 2013 at 17:47.