On Thursday 25 March 2010 19:39:50 Matthew Toseland 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. > > Thoughts? > I have updated the website to reflect the new workflow. I am not going to revert anyone's commit rights in the near future, but you should consider making your changes in your own forked repo and then posting a pull request.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
