Patches are indeed a pain, so I would also be happy to work with CTR in general.
> Good thing you brought this up. I think we should go with CTR. We have > already experienced problems with patches that gets outdated very fast. > Manual rebasing is time wasting, error prone and extremely boring :) . > > // Roger > > > On Aug 2, 2011, at 2:36 PM, Emmanuel Lecharny wrote: > >> Hi guys, >> >> now that you have commit access, I think it's a better solution to apply >> your modification directly in the code base. Attaching patches to JIRA >> is good, but it forces someone to apply them. >> >> If you'd like to discuss a proposed patch, then the best is to attach >> the patch to a mail and start a discussion. >> >> Now, it's up to you. In fact, you have two options when it comes to >> commits : >> - c-t-r (commit-then-review) >> - r-t-c (review then-commit) >> >> The first option is considered as the standard politic at Apache. Most >> of the project just let people commit, then eventually review the >> patches. It assumes than a -1 (veto) on a commit requires a reverse and >> a discussion should then be started. Vetoing a commit is not an insult, >> it's just a way to say that there might be an issue with the commit. >> >> The second option is used in mature projects (like httpd) which simply >> can't accept a breakage. I'm not sure that deft is old nor stable enough >> :) >> >> Keep in mind that what is important here is to ease the development >> process, and as it seems you are very active, one way to avoid conflicts >> (I mean, code breakage, not fights between people ;) is to split the >> code in modules, with committers working on separate modules. In other >> words, decoupling. >> >> This is just an advice, again, your choice :) >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> > >
