hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSS] move to gitbox
Date Sat, 08 Dec 2018 23:28:52 GMT
On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <busbey@apache.org> wrote:

> The move to gitbox doesn't require us to only accept github PRs. Given
> the current rate of contributions via patches on JIRA vs GitHub PRs, I
> wouldn't want to push for that now.
>
> The change does make it easier for us to start encouraging PR
> submissions, because committers will be able to directly merge from
> the GitHub UI.
>
> I'd recommend we try to keep this as a small incremental change. That
> would mean:
>
> * committers ensure there's an associated JIRA for release note and
> precommit checks (that can be just by pinging the contributor to go
> make one)
> * backports are still handled by the committer if they're simple and
> the contributor if there's a problem. I think saying "open a new PR to
> backport to branch FOO" is perfectly reasonable since it's analogous
> to when we ask contributors to attach a branch specific patch.
> * committers ensure the pushed commit has a message that follows our
> current practice (which would mean looking out for the "helpful"
> subject wrapping)
> * Squash merge is an option when the committer goes to accept the PR.
> the contributor is free to either push additional commits or squash on
> their branch when working through reviews, I don't think we need to
> weigh in on how contributors choose which of those works best for
> them.
>
> That way we can also incrementally improve how well we handle PR
> submissions by better documenting expectations and building up
> additional tooling (e.g. having our precommit feedback go directly to
> the PR instead of being tied to a JIRA)
>

This seems reasonable to me. Andrew's strawman would be too radical a
change.
Thanks,
S


> On Fri, Dec 7, 2018 at 12:09 PM Stack <stack@duboce.net> wrote:
> >
> > On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <busbey@apache.org> wrote:
> >
> > > Hi folks!
> > >
> > > Per the email from infra "[NOTICE] Mandatory relocation of Apache git
> > > repositories on git-wip-us.apache.org" ( https://s.apache.org/0sfe )
> it
> > > looks like the future of interacting directly with PRs is coming sooner
> > > rather than later.
> > >
> > > I think we should move to gitbox ASAP rather than wait for the crunch.
> If
> > > we hit a rough spot we're more likely to get some help when things
> aren't
> > > busy. Maybe we wait until our open RCs close so that folks that need
> to tag
> > > those releases don't need to update their workflow first?
> > >
> > > Presuming everyone still agrees that we get value out of JIRA, I think
> we
> > > need update our committer guidelines to expressly remind folks to
> check on
> > > things like commit messages before merging PRs, as well as to ensure
> folks
> > > use the "squash and merge" option to keep the git history less
> complicated.
> > > Probably a good time to add text about the importance of backporting,
> since
> > > there isn't a github UI for doing that.
> > >
> >
> >
> > Sounds good.
> >
> > Use this thread to list what needs documentation? (Agree with the "Need
> to
> > sort all of this out and provide clarity now before a switch over." from
> > Andrew).
> >
> > What should the commit be like? Should be like now? What about that ugly
> > bleed that happens when the first line is too long and gets dumped into
> the
> > textbox below ... which then becomes the log IIRC.
> >
> > When do we do the squash merge? Is that the committer who does this after
> > rounds of review?
> >
> > I like Andrew's list.
> >
> > On the 'You can't fix a branch-1 issue where the code is different in
> > branch-2 and up by opening a PR against master', this is a prob. at least
> > with our current 'process'. We don't do a JIRA per push because it is
> just
> > a bunch of busy work. Do we have to do this now (any alternatives?)
> >
> > Thanks for starting this up Sean,
> > S
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message