fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <mkra...@mifos.org>
Subject Re: [DISCUSS] Git procedure and branching model
Date Wed, 30 Dec 2015 21:42:11 GMT
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
mkrantz@mifos.org | 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 <gstein@gmail.com> wrote:

> On Tue, Dec 29, 2015 at 10:12 AM, Markus Geiss <markus.geiss@live.de>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message