Am 2017-05-10 um 21:31 schrieb Bindul Bhowmik:
On Wed, May 10, 2017 at 1:25 PM, sebb <seb...@gmail.com> wrote:
It would be helpful to document this on the Wiki and/or website
On 10 May 2017 at 20:22, Oleg Kalnichevski <ol...@apache.org> wrote:
On Wed, 2017-05-10 at 21:06 +0200, Michael Osipov wrote:
Hi folks,
given that Oleg finally took up the chance migrating core and client
to
a Git-based repo, we should agree how we are going to work with in
conformance with a good Git practice to avoid chaos on master. I'd
like
to provide an example first why a common practive is so necessary to
make life easier for us (committers) and as well as for our users
reading a beatiful log understanding what we do and why we do it.
Example: as you might know, there are about ten committers for Maven
and
we already use Git for quite some time, but did not really embrance
it's
workflow. It finally ended in having people constantly working on
master
pushing fixes for fixes and reverts for reverts (including myself),
rendering master unreadable and unusable. We agreed for a reset on
master (we actually skipped 3.4.0 for that reason) (INFRA did) and
went
through every single ticket wether it should be on 3.5.0 or not and
why.
The approach we have taken is that for every single ticket a branch
MNG-xxxx is created by a dev, pushed to origin. Jenkins will
automatically run all ITs. After that has happened you ask for a
review
on dev@ and leave room for discussion. There are oftern cases you
don't
see. Having an extra pair of eyes is helpful. This flow works very
well
because we now have a single-commit-per-issue, fully working, no
fiddling.
My proposal:
1. Branch off master (git checkout -b HTTPCORE-XXXX master)
2. Work on your issue. Create as many commits as you want
3. Polish it
4. Squash it/fix it up
5. Ask for a review if you are uncertain
6. merge back to master, but avoid merge commits which are just
noise
for a single merge (rebase your branch onto mater)
7. Never rewrite (rebase) history on master because you will break
others. Infact, you can't because it is a protective branch. Only
INFRA
can do.
8. Take care of a proper commit message, these references are good:
* https://chris.beams.io/posts/git-commit/
* https://github.com/erlang/otp/wiki/Writing-good-commit-messages
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.
9. If in doubt, ask for help and give people a couple of days to
react.
10. When you close the issue, put a link to your commit to create a
direct relation between issue and solution.
11. If this change comes for a PR on GitHub, don't steal authorship,
let
the reporter polish his work and amend the message at the end with
"This
closes #xy" and push.
Something else I forgot?
What do you think?
Michael
PS: I know this is work, but it pays off really quick
+1
All makes sense to me. Pretty much every should happen on a dev
(feature) branch and later merged to the release branch (like 4.3.x,
4.4.x, trunk).
I would still ask for master being mutable (rewritable) or abandon the
concept of a master branch as inapplicable in favor of a release branch
such as 5.0.x.
Oleg
Looking at examples from the Maven project, should there be a
multi-branch build be setup on Jenkins using a Jenkinsfile and changes
merged into master (or a maintenance branch for old releases) only
when the build succeeds? For maven, the build is maven-3.x-jenkinsfile
[1] and the config at Jenkinsfile [2].
This can also be extended to automatically build pull requests, there
are projects on builds.a.o which seem to suggest that is supported.
Bindul
[1] https://builds.apache.org/job/maven-3.x-jenkinsfile/
[2]
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=Jenkinsfile;h=b6c7e19ba74352acc513e10ff9dc8cc9f4fcc1f8;hb=HEAD
This is what we do and would really like to see for every Java-based
Apache project. Given that HttpClient is essential for the entire
ecosystem (Mavon Wagon) I'd be really greatful to the person who is able
to write us such a Jenkinsfile.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
