Which doc? I need to fix it :-) On Thu, Dec 24, 2015 at 2:19 PM, <[email protected]> wrote:
> > > thanks for the feedback ... I think jira issues are simply a good way of > organizing work ... you see what is going on w/out reading a bunch email > threads. > > > The sample commit message I've used was directly copied from the ASF > documentation ... but I'm fine doing a commit instead of pre calling it out > that makes totally more sense to me. > > > Cheers > > > Markus > > > ::: YAGNI likes a DRY KISS ::: > > > > > > > On Thu, Dec 24, 2015 at 11:54 AM -0800, "Roman Shaposhnik" < > [email protected]> wrote: > > > > > > On Thu, Dec 24, 2015 at 9:02 AM, Greg Stein <[email protected]> wrote: > >> Feature branches should be created using the name of the JIRA issue > which > >> is to be solved. > >> > > > > If you discuss a feature on the dev@ list, then why create a JIRA issue? > > The community already knows a feature is going to be developed. No need > to > > create an issue for it. > > I disagree. I find JIRA a much more flexible tool for tracking on going > work > on the project. JIRA allows me things like registering for > notifications, integration > with GH pull requests, etc. that are simply too tedious to do using pure > mailing > list workflow. > > Now, I agree with you that fixing a one liner probably shouldn't > require JIRA -- everything > else just use JIRA as your community TODO list. > > In fact, enter *ideas* into JIRA, keep things marked for newbies, etc. etc. > This is, again, where JIRA shines over mailing list -- if somebody new > comes to the community and asks how she or he can help -- it is much > easier to point a JIRA query that would give you exact list of issues > than a pointer to mailing list discussions or wiki. > > > Meta: JIRA is busy-work, if used for features. > > Not always. I fine it useful, for example, to track evolution of a > proposals > or blueprints. And yes, certain feaatures will require those documents > to get buy-in from the community. > > >> I suggest to use the CTR[5] (commit then review) model for code > >> modifications, and RTC[6] (review then commit) for package releases. We > >> should not mismatch review with a code review. A code review should be > done > >> based on the pull request and prior to commit the changes into the main > >> repository. Once this process has finished, a vote based on lazy > consensus > >> is initiated with a message like "This solves issue FINERACT-1234, if > >> no-one objects within three days, I'll assume lazy consensus and commit > it." > >> > > > > That is not CTR. Commit straight away. Don't wait. "This looks good to > me. > > <commit>" > > > > You use the term "object", but that isn't quite right. Commit the change. > > Others can review. If they have *issues* with the change, then you begin > a > > discussion. Not an objection. > > > > The goal is to *fix* what was committed. Not to object to it, and roll it > > back. When the commit lands in the repository, then review happens (CTR). > > And based on the review, further changes can be applied. > > > > Remember: this is version control. There is no reason to "object". There > is > > no reason to vote. Everything goes into version control with the lowest > > barrier possible. Let people directly commit to a branch, or even to the > > "develop" main branch. Why not? If it breaks something, then fix it. > Worst > > case, it can always be backed out. > > > > TRUST each other to commit working code, and fixes, and new features. > Trust > > is a huge issue. Please don't erect barriers. Please don't control the > > repository via JIRA. Let people write and commit code. Give them room, > and > > let them work. Contributions are *always* a bonus, and very rarely a > harm. > > So optimize for the former. > > Huge +1 to the above! > > Thanks, > Roman. >
