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 >
