On 05/31/2017 12:34 AM, Gary Gregory wrote:
On Tue, May 30, 2017 at 11:55 AM, Oleg Kalnichevski <ol...@apache.org>
wrote:
On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote:
On Tue, May 30, 2017 at 9:13 AM, Michael Osipov <micha...@apache.org>
wrote:
Am 2017-05-29 um 22:54 schrieb Gary Gregory:
On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad <
philippe.moua...@gmail.com> wrote:
Hello,
I'm not committer still, my 2 cents:
[x] +1 Committers must abide to these Git guidelines while
working on the
code
Except for this one:
=> 1. Request the release manager to merge your banch back to
the
release
branch and make sure that this merge won't incur a merge commit
IMO, this creates a contention on release manager.
I'm not a fan of that one. That seems like:
- a bottleneck for all waiting for the RM to merge.
- an additional burden to the RM
The text is in contradiction of itself IMO: While "Guidlines" is
in the
title, the boy includes "every committer must abide..." which is
does not
feel like a "guideline". As soon as you enter the "MUST"
territory, do you
need to define what happens if you do not "abide" by the "MUSTs"?
If these are really guidelines, then all of this is the preferred
way but
all committers are allowed to diverge to get things done.
Gary, why didn't you speak up earlier?
Obviously, I was was busy.
I made serveral attempts for the points?
We can rename it to Git Rules if you want, so this will be
mandatory for
all committers. Btw, you recommended to rename to Git Guidelines...
Changing the title to "Guidelines" while keeping the intent of strict
rules
is misleading. My hope was that my point about using the term
'guidelines'
would trickle down to the actual text, which was obvious to me, and I
was
clearly off by not stating my intentions more clearly. I do not
believe
that more process and stricter rules will benefit this project,
especially
by creating a bottleneck around the RM. But hey, that's just me.
Since you
have done (AFAICT) and are currently are doing the bulk of the heavy
lifting, I am willing to working within your worldview. Sure, I'd
like to
see my contributions flow (pun intended) more fluidly (I'm on fire
today)
into the code base, but I am happy to live within the confines this
our
community defines.
Gary
Gary, Michael, et al
What if we relax this statement a little by saying that 'a committer
prepares a dev branch, asks RM for a review, and if RM fails to respond
or merge the branch within a, say, 48h window, merges the dev branch
to release branches'?
We also say that committers should follow these guidelines to avoid
conflicts instead of abiding them as strict rules?
Those guidelines that should be strict can be expressed as 'MUST avoid
merge commit', and so on.
That sounds good. I would probably widen the RTC time window to maybe 72
hours, (like a VOTE) to give the RM a little more elbow room. We all get
busy ;-)
Gary
+1
72h sounds better
asankha
--
Asankha C. Perera
AdroitLogic, https://www.adroitlogic.com
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
