fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <mkra...@mifos.org>
Subject Re: Single thread per topic please (was RE: [DISCUSS] Git procedure and branching model)
Date Mon, 04 Jan 2016 14:19:48 GMT
Hey Ross,

I think you're overestimating my contribution there.  All I did was scrape
the thread and put the stuff I thought should be captured into wiki pages.
I agree that we should stick to one topic per thread.  I was a little
annoyed that the original thread seemed to lack focus and that was why I
did what I did.  You probably couldn't see that content in the thread from
where you were looking though.  It wasn't quoted in the email that I
responded to.  It was earlier in the thread, and working on getting lost.

The part of your mail that we likely actually disagree on is the use of
confluence.

I think we've already demonstrated that conversations in a mailing thread
tend to meander.  That has it's place.  It's even necessary for creative
work.  But when I'm looking for a concrete result, I believe it helps when
the object under consideration is right there where the discussion occurs.
I like the fact that confluence improves the locality of these kinds of
conversations.

I also believe that in some cases it is important when new people join a
project for them to be able to follow why certain decisions were made the
way they were.  If the conversation is attached to the decision
documentation, it's much easier to find. And if no conversation is
attached, it's easy for new people to see that there wasn't much
consideration put into a given decision.  This also helps newbies avoid
emotional mine fields.  (Have you ever joined a project as a newcomer and
asked about a specific decision only to have it blow up unexpectedly in
your face because people have discussed it long enough to be emotional
about it?  I have...)

I suggest anyone who wants to stay up-to-date on the topic addressed on a
certain wiki page add themselves as a watcher to the page.  This has
another advantage too: those who *aren't* interested in a certain topic can
avoid e-mails on that topic.  I know what it's like to be overwhelmed by
e-mails, and I like the way confluence helps me to manage that burden.  I
try to be respectful of others time, by scoping my communications
respectfully.

I appreciate your input as mentor, but on this one, unless the community
speaks up and asks for something different of me, I will continue to use
confluence for conversations in certain cases (and JIRA in others).

I sure hope someone else from the community speaks up though, one way or
the other.  Right now, I'm really wondering where everyone is.

Greets from Germany,
Myrle Krantz


*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 Fri, Jan 1, 2016 at 5:25 PM, Ross Gardler <Ross.Gardler@microsoft.com>
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message