On Thu, Mar 25, 2010 at 3:39 PM, Matthew Toseland <t...@amphibian.dyndns.org> wrote: > It has been suggested, after various troubles recently with code cleanup > patches, that a more traditionally git like workflow might work better - > where fewer people have direct access to the repository and most contributors > create a fork on github and then ask for it to be merged. > > This would avoid messy reverts and forced updates when something big and > messy goes in and then has to be reverted so as not to pollute the history > for later reviewers. It would avoid the need to have a policy that anyone > *other than me* who does a forced update loses their commit rights (because > forced updates make reviewing hard). It would allow me to skip not > immediately important changes more easily when releasing a new build. It > would encourage discussion of major disruptive code changes (e.g. cleanups) > before they go in, and so on. It is the model used by most projects using git. > > On the other hand, while network-wise it would be more decentralised, > work-wise it would be more centralised: Code would not go in unless I (or > another trusted core dev) merged it into the main repository.
I'm in favor. I don't think this adds centralization in any meaningful sense: you review all changes before they go into a build either way, right? It does mean that if you're behind on reviewing and merging, other devs need to pay attention to each other's branches and merge them into their own if they're relevant. I don't think this is a problem, though, and it doesn't add any more work for you. Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
