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?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl
