what gitbox / github protections and other options to ask for?

[Marshall Schor <ms...@schor.com>]

In looking at some other JIRA tickets for people moving from SVN to git, one
thing they seem to request is various kinds of "options". 

I haven't found a apache doc page that describes these, so I'm not sure what to
ask for, etc.

Here are some I've found:

1) ban force push to some branches (e.g. master and master-v2 branches)

2) setting commits mailing list to be the same as it is now (maybe the default?)

3) fixing pull requests to (a) disable "merge", and enable only "rebase and
merge" or "squash and merge"?

4) setting JIRA integration so that a commit message with a Jira number gets
linked in that Jira

I found this page http://apache.org/dev/svngit2jira.html which says you have to
file an INFRA Jira ticket to set this up.  I thought this was already set up but
I've noticed it doesn't always seem to be working, so perhaps it's a good idea
to request this again?  Or maybe it needs to be requested separately for the new
git repo?

I also found some config for setting some git option for something similar, in
some comments in some JIRA issues.  See
https://issues.apache.org/jira/browse/INFRA-12209, where it says: Jira
integration is also possible:

   JIRA ticket cross-posting is enabled when PRs are enabled, and as such,
   any reference to a JIRA ticket will cause the specified ticket to update with
   the github stuff. The default behavior is to add a link to the pull request
   and to create comments on the JIRA with the activity on the PR. This
   behavior can be changed by setting the 'apache.jira' option in the
   repository's settings; 'git config apache.jira OPTION', where OPTION is one
   of 'nofollow', 'linkonly', or 'worklog':
   - nofollow # completely disables updating JIRA
   - linkonly # adds the link to the PR, but does not add comments
   - worklog # adds the link to the PR and updates the JIRA worklog instead of
the comments

These look a bit different?

5) require a Jenkins job to pass before a pull request is pushed to master /
master-v2.


Any opinions on what we should request initially?

I guess I'm planning to ask INFRA for some advice -
  - on what other projects do here
  - is there a doc page somewhere which describes the alternatives, etc.

-Marshall

Re: what gitbox / github protections and other options to ask for?

[Richard Eckart de Castilho <re...@apache.org>]

Hi

> On 22. Aug 2019, at 22:25, Marshall Schor <ms...@schor.com> wrote:
> 
> Any reason not to protect *all* branches from force push?

You'll appreciate the freedom of being able to force-push into pull requests to rewrite their history, e.g. if you want to amend a bad commit comment or rebase a PR to a different branch or whatever.

> I see in my uima commits folder messages from rec@apache.org, which say things like:
> This is an automated email from the ASF dual-hosted git repository.
> 
> rec pushed a commit to branch 3.0.x
> in repository https://gitbox.apache.org/repos/asf/uima-uimafit.git
> ... and then details, including the message.
> 
> So it appears that commits are generating messages to the commits list.

Ok, good :)

> What is the reason for your view on rebase or squash?  What I vaguely understand
> is that if you have a git change process that branches, does work (possibly with
> many commits) and then eventually, does a merge of some kind with the base, that
> these things make the commit look like one thing (they loose the incremental
> history of what you were doing while working on the branch).  I guess some
> people like the main branch to not have all the start/stop/change-your-mind/ set
> of little commits, in the branch, preserved in the main. 
> 
> Is your comment "please don't *force* ..." mean you advocate we allow all styles
> of pull request merging?

I tend to like the merge-commit approach because it preserves the individual commits
and that means that the commit details apply at a finer granularity. If you squash
a large PR with many commits, you'll end up with a huge commit message and little clue
as to which parts of the code the commit comments actually apply do, e.g. when doing a
"blame" operation.

Cf. my earlier comments on merge vs squash vs rebase:

- http://mail-archives.apache.org/mod_mbox/uima-dev/201906.mbox/%3c5ABCD005-16FB-4424-AAAC-1A04661FFDCF@apache.org%3e
- http://mail-archives.apache.org/mod_mbox/uima-dev/201906.mbox/%3c33E10AEE-AAF4-4839-9A0D-B1DB17816F26@apache.org%3e

Cheers,

-- Richard

Re: what gitbox / github protections and other options to ask for?

[Marshall Schor <ms...@schor.com>]

Hi,

Any reason not to protect *all* branches from force push?

I see in my uima commits folder messages from rec@apache.org, which say things like:
This is an automated email from the ASF dual-hosted git repository.

rec pushed a commit to branch 3.0.x
in repository https://gitbox.apache.org/repos/asf/uima-uimafit.git
... and then details, including the message.

So it appears that commits are generating messages to the commits list.

What is the reason for your view on rebase or squash?  What I vaguely understand
is that if you have a git change process that branches, does work (possibly with
many commits) and then eventually, does a merge of some kind with the base, that
these things make the commit look like one thing (they loose the incremental
history of what you were doing while working on the branch).  I guess some
people like the main branch to not have all the start/stop/change-your-mind/ set
of little commits, in the branch, preserved in the main. 

Is your comment "please don't *force* ..." mean you advocate we allow all styles
of pull request merging?

Thanks for responding! -Marshall

On 8/22/2019 3:53 PM, Richard Eckart de Castilho wrote:
>> On 22. Aug 2019, at 20:53, Marshall Schor <ms...@schor.com> wrote:
>>
>> Here are some I've found:
>>
>> 1) ban force push to some branches (e.g. master and master-v2 branches)
> Any "main" branches should be protected from force commits. I think we should be
> protecting master and define some convention like that maintenance 
> branches always start with "maintenance/", e.g. "maintenance/2.10.x"
> or something like that to avoid having to ask for protection of a new branch
> after every feature release.
>
>> 2) setting commits mailing list to be the same as it is now (maybe the default?)
> I don't remember anymore if they send commit notifications to the dev list by default,
> but doesn't hurt to ask.
>
>> 3) fixing pull requests to (a) disable "merge", and enable only "rebase and
>> merge" or "squash and merge"?
> Please don't force rebase or squash.
>
>> 4) setting JIRA integration so that a commit message with a Jira number gets
>> linked in that Jira
> I thought they (INFRA) do that by default... for uimaFIT, I didn't set any options
> as far as I remember. Maybe I should have...?
>
>> 5) require a Jenkins job to pass before a pull request is pushed to master /
>> master-v2.
> A Jenkins job to build pull requests should be set up, yes. And merges to the
> protected branches should be prevented unless Jenkins is good.
>
> Cheers,
>
> -- Richard

Re: what gitbox / github protections and other options to ask for?

[Richard Eckart de Castilho <re...@apache.org>]

> On 22. Aug 2019, at 20:53, Marshall Schor <ms...@schor.com> wrote:
> 
> Here are some I've found:
> 
> 1) ban force push to some branches (e.g. master and master-v2 branches)

Any "main" branches should be protected from force commits. I think we should be
protecting master and define some convention like that maintenance 
branches always start with "maintenance/", e.g. "maintenance/2.10.x"
or something like that to avoid having to ask for protection of a new branch
after every feature release.

> 2) setting commits mailing list to be the same as it is now (maybe the default?)

I don't remember anymore if they send commit notifications to the dev list by default,
but doesn't hurt to ask.

> 3) fixing pull requests to (a) disable "merge", and enable only "rebase and
> merge" or "squash and merge"?

Please don't force rebase or squash.

> 4) setting JIRA integration so that a commit message with a Jira number gets
> linked in that Jira

I thought they (INFRA) do that by default... for uimaFIT, I didn't set any options
as far as I remember. Maybe I should have...?

> 5) require a Jenkins job to pass before a pull request is pushed to master /
> master-v2.

A Jenkins job to build pull requests should be set up, yes. And merges to the
protected branches should be prevented unless Jenkins is good.

Cheers,

-- Richard