Hi, On Nov 20, 2007 10:52 AM, <[EMAIL PROTECTED]> wrote: > [SNIP of good explanation of types of contribs] > > In these cases I think a fork is a more complex issue; if it's the best > > way to share significant experimental changes with the rest of the > > world, faced with my anally-retentive death grip on my repo, maybe > > it's not such a bad idea. ;) > > ...which (the "grip") is why I really recommend Mercurial - it enables > us all to branch easily AND to make sure contribs easily gets fed back > etc.
I have to agree with you. I've contributed to projects that used SVN (e.g., Trac) and I really hated the fact that there was no easy way to manage and save my patches (svk is horrible). If you have multiple patches you can't keep them separate, especially if they're related (e.g., you add feature A in one patch and in the next patch you add feature B that depends on A but might not be accepted, so you want to keep them separate). Mercurial makes it much easier to manage separate changes and keep track of them in your repos (e.g., one branch per patch, branches extending other branches, etc.). SVN sometimes frustrated me so much that I gave up and my contribution was never incorporated. A distributed SCM would've solved my issue. BTW, Mercurial is definitely easier to use than git and it runs on Windows without having to install that stupid Cygwin and mess up your system. There even is a full Mercurial package for Windows that comes with a three-way merge tool and all necessary Mercurial plugins, so it's even easier to get started. From my experience in an OSS project (Haiku) it is *very* *very* important to make it *incredibly* easy to get started with contributing. It's also important to tell contributors what they can work on instead of making them ask on the list because: * it's easier to just pick a task that you like (esp. important for one-time contributions) * at least in Haiku no developer really felt responsible for replying and often no developer knew what to reply, at all * many people will introduce themselves, ask for a task, and then vanish (maybe because you didn't mention a task of interest, maybe also because they suddenly feel a pressure to contribute) * if you can pick a task you can work in peace without feeling responsible for anything (you haven't promised anyone to work on it) * some contributors shy away from asking publicly on mailing lists (sometimes they speak privately to a team member which can only work if the developer is responsive and can keep him motivated) E.g., many Google Summer of Code projects had that problem with their students who only spoke to their assigned mentor. Those shy students were less likely to finish their work successfully (you had to force them to use the public tools, which often seemed to help). BTW, why is the mailing list configured such that replies don't go to the mailing list? That way, I always have to remember to either press "reply to all" which I might forget sometimes. Bye, Waldemar Kornewald _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
