[
https://issues.jboss.org/browse/JBIDE-24439?page=com.atlassian.jira.plugi...
]
Nick Boldt commented on JBIDE-24439:
------------------------------------
Once again, it was decided that protected branches are not (yet) a good idea, because:
* for urgent changes we need a workaround (eg. Andre being owner of openshift repo, so
doesn't have to wait for PR review)
* owners might not have the discipline to wait for PR reviews
* PR reviews may not be effective since we have a small team and limited shared SME
knowledge (eg., Rob is the only SME for server adapters, so others doing review isn't
so useful)
Instead, we've decided to push on having the integration tests run more frequently to
catch regressions like [1] faster.
[1]
https://github.com/jbosstools/jbosstools-server/commit/1a58a4d54097e4d927...
Block PRs for merge untill the Jenkins build is successful (protected
branches)
-------------------------------------------------------------------------------
Key: JBIDE-24439
URL:
https://issues.jboss.org/browse/JBIDE-24439
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build
Affects Versions: 4.5.0.AM1
Reporter: Nick Boldt
Assignee: Jeff MAURY
Fix For: LATER
As discussed in this thread [1], we'd like to implement *Protected Branches* and
*Required Status Checks* [2] for some jbosstools-* projects.
[1]
http://lists.jboss.org/pipermail/jbosstools-dev/2017-May/011948.html
[2]
https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
We will therefore need to document some requirements in jbosstools-devdoc about how to
properly submit PRs when version-bumping is required:
{quote}Make sure if your PR requires a version bump that the PR includes TWO commits. One
for the change, and one for the version bump. That way the pair of commits can be built in
the PR build and verify it works, AND when cherry picking the commit across branches, you
can pick only the change and not the version-bump commit too.
{quote}
And we need to decide if we want to do what Fuse Tools does and require that PRs be
reviewed before they can be merged, if we're ready to have that additional overhead on
every PR.
[~jeffmaury] as project lead can you state which project(s) you'd like to see changed
in github, and which ones should be changed as such:
* jbosstools-_____
** Protected Branch = master
** Required Status Check(s) = ....? (which checks do we want)
** PR reviews required = [true/false]
From that list of projects / requirements, we can then create subtask JIRAs to track the
workj & the changes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)