fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Geiss <markus.ge...@live.de>
Subject Re: Single thread per topic please (was RE: [DISCUSS] Git procedure and branching model)
Date Fri, 01 Jan 2016 16:54:18 GMT
The started thread turned into a topic covering multiple things,
branching (including release and versioning), general workflow,
and the contributor question.

For me the suggestion, to raise awareness of a topic here at the
mailing list, but run the conversation at Confluence makes total
sense. I directly have a context, and can see/ read all comments
pretty easy.

For me it is more complicated to look at different location to
gather all information. If a topic is related to either a wiki
page or or an JIRA issue it feels more natural to have all in one
place instead of looking at multiple sources, e.g. looking at the
JIRA issue and skimming the mail thread to find all information
needed.

Best,

Markus

.::YAGNI likes a DRY KISS::.

On 01/01/2016 05:25 PM, Ross Gardler wrote:
> For inclusiveness I recommend all discussion happens here in a new, targeted, thread
on dev.
>
> The mail below has 4 or 5 different topics covered and is posted to a thread which is
doesn't directly relate to any of those topics. Furthermore it encourages further discussion
in a different location. This makes it difficult for people, as community members, to know
whether they want to skip, speed read or carefully review its content.
>
> Please ensure you use a single location for all communications to avoid a splintering
of the community.
>
> Ross
>
> ---Original Message-----
> From: Myrle Krantz [mailto:mkrantz@mifos.org]
> Sent: Wednesday, December 30, 2015 9:42 PM
> To: dev@fineract.incubator.apache.org
> Subject: Re: [DISCUSS] Git procedure and branching model
>
> Hi all, Hi Greg,
>
> With respect to adding committers, I've created a first draft proposal
> here:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fBecoming%2ba%2bCommitter&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PzmS%2fmQSBlnGTlJmIR%2bQ4GhDh%2bb2IBBsNnpLVLKIl80%3d
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fStabilizing%2ba%2brelease&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ien0%2btld6UOzQsa3a98Yoj0LaSfbrAB67z%2bECvr%2fsTE%3d
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fVersioning&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=svdPVCT8hpZEOC4AXN480oBqDiZgzKSD90DwahIZlIE%3d
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fBecoming%2ba%2bCommitter&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PzmS%2fmQSBlnGTlJmIR%2bQ4GhDh%2bb2IBBsNnpLVLKIl80%3d
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fStabilizing%2ba%2brelease&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ien0%2btld6UOzQsa3a98Yoj0LaSfbrAB67z%2bECvr%2fsTE%3d
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fFINERACT%2fVersioning&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=svdPVCT8hpZEOC4AXN480oBqDiZgzKSD90DwahIZlIE%3d
>
> Greetings from little Lüxheim, Germany
> Myrle
>
>
> *Myrle Krantz*
> Solutions Architect
> RɅĐɅЯ, The Mifos Initiative
> mkrantz@mifos.org | Skype: https://na01.safelinks.protection.outlook.com/?url=mkrantz.mifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nYBhfrXHGHzVvY9ZK74YXyeejRWkNgfdQaPeswMZe%2b0%3d
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmifos.org&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NHgwnlwyYKGoiPoaILVnK3FIhgMVos2lzXsDsHEXRTw%3d
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ffacebook.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7xF%2f24QFMOBcCx3h2WS%2f6%2bkyUy1AlFW4MxyzvsTrxRk%3d>
 <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.twitter.com%2fmifos&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mjrwFaanZPZbwpnwL5Ko6E4wwWkapVD7N2SBWy1PWC4%3d>
>
>
> 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:
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsvn.ap
>> ache.org%2frepos%2fasf%2fsubversion%2fbranches%2f1.9.x%2fSTATUS&data=0
>> 1%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d311621c
>> b3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I9Qh3ziBSp5aDj9bSSxn6k
>> iPid1InwRnDsKE%2fblOi8c%3d
>>
>> 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:
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsubver
>> sion.apache.org%2fdocs%2fcommunity-guide%2freleasing.html%23release-st
>> abilization&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b4
>> 4ef940ea08d311621cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xj3g
>> zf%2feMJsNzBKxlb7H7oR5aWGJy6eVdPxwvuGRi6E%3d
>>
>> The Apache HTTP Server has a similar file:
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsvn.ap
>> ache.org%2frepos%2fasf%2fhttpd%2fhttpd%2fbranches%2f2.4.x%2fSTATUS&dat
>> a=01%7c01%7cRoss.Gardler%40microsoft.com%7c79b309e6e4b44ef940ea08d3116
>> 21cb3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=k6Z8Ujsq2o8QAdpXNln
>> R2I7UCcz5%2fGLceig2yQY2mqM%3d
>>
>> but it isn't as well-documented, thus my pointer to Subversion.
>>
>>> ...
>>
>> Cheers,
>> -g
>>

Mime
View raw message