[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-commons-dev
Subject:    Re: [VOTE] Git Guidelines (2)
From:       Philippe Mouawad <philippe.mouawad () gmail ! com>
Date:       2017-05-30 19:08:18
Message-ID: CAH9fUpZVzbNmbYci3Qt09qedQ8FdWa2kk8P6GpoUuGoJUmOJUw () mail ! gmail ! com
[Download RAW message or body]


On Tue, May 30, 2017 at 8:55 PM, Oleg Kalnichevski <olegk@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 <michaelo@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.mouawad@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'?
>
+1

>
> 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.
>
> Oleg
>
> PS: this is why I prefer writing code.
>
+1

>
> >
> >
> > >
> > > Michael
> > >
> > >
> > > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov <michaelo@apache.or
> > > g>
> > > > > wrote:
> > > > >
> > > > > Am 2017-05-24 um 19:11 schrieb Michael Osipov:
> > > > > >
> > > > > > Hi folks,
> > > > > > >
> > > > > > > I am re-casting this vote for the previously discussed Git
> > > > > > > guidelines
> > > > > > > for all committers to make life easier for everyone. If the
> > > > > > > vote
> > > > > > > passes,
> > > > > > > every committer must abide to this.
> > > > > > >
> > > > > > > The guidelines:
> > > > > > > = Typical Issue Workflow =
> > > > > > >
> > > > > > >  1. Branch off a release branch (e.g., 4.4.x, 5.0.x)
> > > > > > > ({{{git checkout
> > > > > > > -b
> > > > > > > <release branch>/<JIRA id> master}}}) where {{{<JIRA id>}}}
> > > > > > > being the
> > > > > > > JIRA issue you have assigned to yourself, e.g., HTTPCORE-
> > > > > > > 123 or
> > > > > > > HTTPCLIENT-689. Exmaple: {{{git checkout -b 4.4.x/HTTPCORE-
> > > > > > > 123
> > > > > > > 4.4.x}}}.
> > > > > > >  1. Work on your issue and create as many commits as you
> > > > > > > want/need
> > > > > > >  1. Polish it, squash it or fix it up into a single commit
> > > > > > >  1. Ask for a review if you are uncertain
> > > > > > >  1. Take care of a proper commit message (good reads:
> > > > > > > [[https://chris.beams.io/posts/git-commit/|1]] and
> > > > > > > [[https://github.com/erlang/otp/wiki/Writing-good-commit-me
> > > > > > > ssages|2]]
> > > > > > > ):
> > > > > > > Put the title of the JIRA issue, e.g., [HTTPCORE-123]
> > > > > > > Memory leak in
> > > > > > > response, in the first line, followed by an explanation why
> > > > > > > you did
> > > > > > > take
> > > > > > > this approach. The ticket desc contains the issue, your
> > > > > > > commit message
> > > > > > > contains the solution. If in doubt, ask for help and give
> > > > > > > people a
> > > > > > > couple of days to react.
> > > > > > >  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
> > > > > > >  1. When you close the issue, put a link to your commit to
> > > > > > > create a
> > > > > > > direct relation between issue and solution.
> > > > > > >
> > > > > > > =  Side Notes =
> > > > > > >
> > > > > > >  1. Never rewrite (rebase) history on master or any other
> > > > > > > long-lived
> > > > > > > branch because you will break others. Only the release
> > > > > > > manager is
> > > > > > > entitled to clean up history upto 72 hours after a commit
> > > > > > > if it is
> > > > > > > absolutely necessary
> > > > > > >  1. If a change comes for a PR on GitHub:
> > > > > > >    * Apply the same above rules
> > > > > > >    * Don't steal authorship
> > > > > > >    * Let the reporter polish his work
> > > > > > >    * Amend the message at the end with "This closes/fixes
> > > > > > > #xy" and
> > > > > > > push.
> > > > > > >
> > > > > > >
> > > > > > > Link: https://wiki.apache.org/HttpComponents/GitGuidelines
> > > > > > >
> > > > > > > Vote is open until 2017-05-29 00:00 Etc/UTC.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > vote is over and no one except Oleg and me has voted.
> > > > > >
> > > > > > What now? Will chaos reign our Git repos?
> > > > > >
> > > > > >
> > > > > > Michael
> > > > > >
> > > > > >
> > > > > > -----------------------------------------------------------
> > > > > > ----------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > > > > For additional commands, e-mail: dev-help@hc.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Cordialement.
> > > > > Philippe Mouawad.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.


[prev in list] [next in list] [prev in thread] [next in thread]