fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [DISCUSS] Git procedure and branching model
Date Tue, 29 Dec 2015 22:10:54 GMT
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