+1
On 4/6/19 8:22 AM, 张铎(Duo Zhang) wrote:
OK, now we have the yetus set up for GitHub PR, and I've tried to use
GitHub PR to process several issues. For example HBASE-22174, Sean Busbey
approved on the PR, and I used the GitHub PR to commit to master, and then
cherry-picked the commit to other branches, and committed them using
command line. Worked pretty fine. The only problem is that I accidentally
clicked the default merge button and created a merge commit in the commit
history...
So I'm +1 on only allowing rebase merging, for squash merging, it is not a
big deal to let the author squash the commits before merging. And at least,
let's disable the default 'Create a Merge Commit' option...
Thanks.
Sean Busbey <bus...@apache.org> 于2019年1月10日周四 上午2:03写道：
sure thing. let me draft it up now.
On Wed, Jan 9, 2019 at 11:29 AM Andrew Purtell <andrew.purt...@gmail.com>
wrote:
According to the ticket the main repo and third-party repo have been
migrated. We are just waiting on site.
I'd appreciate it if we can send out that email now, because I'd like to
continue commiting toward 1.5.0. At least, a pointer to docs on how the
integration functions and the steps a committer needs to take to push and
pull changes would be appreciated.
On Jan 9, 2019, at 8:56 AM, Sean Busbey <bus...@apache.org> wrote:
I filed a ticket with INFRA:
https://issues.apache.org/jira/browse/INFRA-17597
The actual transition is supposed to only take a few minutes. Once it's
done we should send a NOTICE email to dev@hbase summarizing what has
changed and what folks will need to do different.
On 2019/01/08 19:07:30, Peter Somogyi <psomo...@apache.org> wrote:
I believe we reached consensus to migrate our remaining repositories
to
GitBox before the mandatory migration which will happen on 7th of
February.
Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty'
repositories that also require the same migration process.
From users' point of view they could still use git://
git.apache.org/hbase.git for read only access, only committers need
to
change the remote URL to the GitBox one. Jenkins jobs are already
using
the
GitHub URL for cloning the repository and I created a patch for the
documentation and website changes in HBASE-21685 that we can merge
after
the process is competed.
There's still outstanding work to do before we have good guidelines on
accepting pull requests on GitHub, but the GitBox migration doesn't
require
our committers to start working with PRs in a different way.
If there is no disagreement I'd kindly ask one of the PMC members to
reach
out to INFRA to perform the migration.
Thanks,
Peter
On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell <
andrew.purt...@gmail.com>
wrote:
Sounds good to me except squash merge at commit of PR shouldn’t be an
option it should be required except for good reason (and I don’t know
what
that would be )
On Dec 8, 2018, at 3:28 PM, Stack <st...@duboce.net> wrote:
On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <bus...@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 <st...@duboce.net> wrote:
On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <bus...@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
