I would appreciate, if you didn't speak for all of us on topics we haven't voted on or otherwise found a consensus. At least for me improving the Trac/patches workflow is only a secondary goal. Having a better tool (that is less broken when it comes to merging and that sports all the nice DVCS features) is the primary goal for me.
Sorry about that, I felt it was the consensus when writing that mail...Anyway, I think the concerns I raised are what started the discussion, but maybe I missed some parts. Of course, it doesn't prevent getting all the new features, but it needs some thinking on how to make good use of them.
It happened to me multiple times, and reworking the patch is an annoying task which isn't actually getting any progress done. When applying a patch could be a one-click operation with the proper tools, this gets quickly boring.Besides, I don't even think that patches becoming impossible to be applied has been a common problem. There are other Trac/features that would help a lot more with our patch workflow than a new VCS would (there was a GSoC application for improvements in that regard).
That's only a start, I hope we will get used to the new features and find good ways to use them. But switching from our current workflow to a massively-forked one on github seems like a too big change at once.The goal, however, is to keep our current centralized workflow, and only use some DCVS features to ease things that were painful in SVN.There have been a few discussions about the workflow, but beyond that most (all?) people seemed to prefer to continue having a central, official repository, I don't recall any specifics everyone has agreed upon. Definitely not that we don't want to use certain features of the potential tools.
This is not a problem per se, the question is, can we track all these forks and merge the changes which deserve it ? Or will one of the forks become more widely used because we can't keep up with the stream of patches from them ? On one side it's nice to see more development hapenning, on the other it's of no use if each patch lives in a separate fork and there is no easy way to merge them all.[...]We don't want people making easy forks, moving away from the current server setup, or anything else. We want to keep the current setup as much as possible, while still adding these improvements. Switching to github would be a way too big move for that. It has a great risk of going out of control.I really wish you wouldn't speak for all of us. At least I don't see any "going out of control" risks. If we switch to git, I'd consider it inevitable that people would clone the official repository on GitHub, Gitorious, etc. and I don't see a problem with that. On the contrary, I'd even encourage a more open development.
Where we host the official repository is mostly a technical matter. I guess we'll have more flexibility hosting it on our own server. That doesn't mean that we couldn't have auto-updated clones on GitHub/Gitorious/...
Sure. But do we need them ?On a personal note this time, I don't feel like thrusting another web service and think it's a bad move in the cloud computing direction. But maybe that's only me.
-- Adrien / PulkoMandy
