So quickly on this, how would we define our process within JIRA? * In Progress - Working on issue, or applying a submitted patch. * Resolved - Committed, and ready for review. Perhaps add a comment to the JIRA "Ready for review". * Closed - Reviewed with at least one +1, and no -1 votes.
How would that be? Just so we know and can avoid confusion. Johnathan On Tue, 2011-08-02 at 13:46 +0100, [email protected] wrote: > 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 > >> > > > > > >
