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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20100417/f4da4e24/attachment.pgp>
