Hi Myrle, Great work! Have left some comments on the different docs.
Thanks, Sander van der Heyden On Wed, Dec 30, 2015 at 10:42 PM, Myrle Krantz <[email protected]> wrote: > Hi all, Hi Greg, > > With respect to adding committers, I've created a first draft proposal > here: > https://cwiki.apache.org/confluence/display/FINERACT/Becoming+a+Committer > > All interested should feel free to discuss. A new thread in @dev is one > way to conduct the discussion. Another approach is to use the commenting > function in confluence. Using the later, would keep the discussion close > to its content, and provide additional context for anyone reading the > document who wishes to understand how it evolved. > > After reading the release-stabilization section of the SVN release process, > I like many aspects of it. It's clear that it has been built out of a lot > of experience. But I still don't see any advantage to using a STATUS file > over using the JIRA ticket. If I use JIRA tickets with appropriately set > release flags, and well-formulated searches, they should cover the use > cases that the STATUS file seems to address, and more. Using the SVN > process as a starting point, I've created a first draft proposal for the > FINERACT release process which replaces the STATUS file with JIRA tickets > here: > https://cwiki.apache.org/confluence/display/FINERACT/Stabilizing+a+release > > I've also created a first draft proposal for release versioning, also based > on the SVN versioning, and on Markus' proposal. You can find the > versioning proposal here: > https://cwiki.apache.org/confluence/display/FINERACT/Versioning > > I'm also considering adding confluence documents with more detailed > descriptions of what constitutes a critical bug, or a risky change. If > anyone has input on these topics (or would like to start a document), > please speak up. > > Please discuss and edit all three confluence documents. They are not > mine. They are ours. Here they are listed again: > https://cwiki.apache.org/confluence/display/FINERACT/Becoming+a+Committer > https://cwiki.apache.org/confluence/display/FINERACT/Stabilizing+a+release > https://cwiki.apache.org/confluence/display/FINERACT/Versioning > > Greetings from little Lüxheim, Germany > Myrle > > > *Myrle Krantz* > Solutions Architect > RɅĐɅЯ, The Mifos Initiative > [email protected] | Skype: mkrantz.mifos.org | http://mifos.org > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > > On Tue, Dec 29, 2015 at 11:10 PM, Greg Stein <[email protected]> wrote: > > > On Tue, Dec 29, 2015 at 10:12 AM, Markus Geiss <[email protected]> > > wrote: > > > > > Looks like attachments won't work, so let me try to explain in > > > words. ; o) > > > > > > We use the branch develop for ongoing new feature, enhancements, > > > and bug fixe development. Aside from really small changes > > > (like a typo), a developer/contributor creates a feature branch > > > for his development effort. Once he is done with his work, he > > > prepares and sends a Pull Request. > > > > > > > Alright... I think here is the disconnect. I'd suggest just not > > naming/labeling these people. Everybody is a "developer" and a > > "contributor", so using those terms is ambiguous. > > > > From our standpoint, we just see Pull Requests from those without commit > > rights. > > > > For those *with* commit rights, they are trusted to commit to the > "develop" > > branch at-will. They are *also* trusted to do large-ish or questionable > > work on a branch first, and ask the community if they agree with that > work > > for merging. They are also trusted to do large and approved feature work > in > > an incremental fashion on the develop branch, if that doesn't interfere > > with its stability. > > > > IMO, people will be watching the develop branch, and its continuous > > integration / builds, and ignore all other branches. It is kind of > natural > > human behavior. Thus, to get the most eyes, reviews, and testing: it > should > > be done on the develop branch. > > > > > > > A committer is doing a review of the changes, and if necessary, > > > comments on the Pull Request suggestion some changes. Once the > > > Pull Request is in line with our code conventions, the committer > > > pulls this changes into the 'real' repo, is running a build to > > > assure tests won't fail, and commits them. No need for any > > > voting, he has earned the right to do so, and this is good. > > > > > > > Yup. > > > > Let's hope the Pull Requests are minimal ... make those people committers > > early and often :-) ... this *is* source control. They can't really hurt > > anything, hmm? Fix it forward, or roll it back. > > > > ... this should be a new thread: how does this community want to add new > > committers? It should be discussed "soon", so there is a known process > for > > when somebody arrives. > > > > > > > If a release is to be made, the self-appointed Release Manager > > > creates a new branch from develop, named after the release, and > > > assures that all tests are running, all needed documentation is > > > in place, and the ASF policies are fulfilled. During this period, > > > the ongoing development can happen as described above, no need > > > to stop others on working for the project. During this phase, it > > > is feasible and sometimes needed to pull bug fixes, or additional > > > features from the develop branch into the release, that's fine. > > > > > > Agreed! > > > > Here is a sample of the STATUS file that I was talking about: > > http://svn.apache.org/repos/asf/subversion/branches/1.9.x/STATUS > > > > That is a good process for cherry-picking changes into the release > branch. > > Ignore the first half-dozen paragraphs about timing and whatnot, but this > > section gives a "how to" on a STATUS file: > > > > > > > http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization > > > > The Apache HTTP Server has a similar file: > > http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS > > > > but it isn't as well-documented, thus my pointer to Subversion. > > > > >... > > > > Cheers, > > -g > > >
