On Tue, May 30, 2017 at 11:55 AM, Oleg Kalnichevski <[email protected]> wrote:
> On Tue, 2017-05-30 at 11:34 -0700, Gary Gregory wrote: > > On Tue, May 30, 2017 at 9:13 AM, Michael Osipov <[email protected]> > > wrote: > > > > > Am 2017-05-29 um 22:54 schrieb Gary Gregory: > > > > > > > On Mon, May 29, 2017 at 12:54 PM, Philippe Mouawad < > > > > [email protected]> 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 > Oleg > > PS: this is why I prefer writing code. > > > > > > > > > > > Michael > > > > > > > > > On Mon, May 29, 2017 at 9:51 PM, Michael Osipov <[email protected] > > > 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: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Cordialement. > > > > > Philippe Mouawad. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
