Thanks for the info.
I'll give this a go and document what I did in case there are problems or if it
can help someone else.
Susan
From: Dan Debrunner <[email protected]>
To: "[email protected]" <[email protected]>;
"[email protected]" <[email protected]>
Sent: Monday, March 7, 2016 5:34 PM
Subject: Re: Process for committing files
> On Monday, March 7, 2016 4:52 PM, "[email protected]"
> <[email protected]> wrote:
> I believe I have gotten my repository for apache incubator-quarks set up
> correctly.
Great!
> It appears we don't have github integration yet, so would it be best to wait
> for that to happen before we commit any changes?
There's no reason to wait for github integration to start committing to the
repo.
> Also, should we open a JIRA issue prior to committing any changes?
It's probably a judgement call, small changes probably don't always need a
JIRA, don't want to create undue overhead.
Features should have issues, so that the feature is developed "on-list", not
just a code dump at some point with no foreknowledge of what was being worked
on.
Bug-fixes should have an issue so they can be tracked.
> If we are
> not waiting for GitHub integration if someone else has already made a pulland
> can reply with an example git sequence of commands, that would be helpful.
It's standard git, so what I did was create a branch in my local clone, make
the changes in the branch, commit and push the change to the origin. That will
create a message on the commit mailing list with the changes, e.g.
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca776b905473f45a9bb0018f95bf6dd8a%40git.apache.org%3E
<time passes - see below>
Then, in my local clone, I merged the change into master and pushed.
git checkout master
git merge quarks-3
git push
That also created a message on the commit list:
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3C3f93c68d5fe041d98e53e53393ed9458%40git.apache.org%3E
As a committer you have the right to commit to the repo, but between the push
and the merge is the time frame where anyone can give feedback before the code
is committed to the repo in the master branch (thus used by/affects everyone).
Again it's a judgement call on how long that period is, order of 72+ hours for
major or controversial changes, but less time for minor changes or those
expected to be generally accepted.
By developing "on-list" you can potentially shorten the 72 hours by effectively
making big changes uncontroversial by letting others see progress as you go, by
working incrementally and pushing frequently to your branch. Then feedback is
given as you go along so the final merge is pretty much what most folk are
expecting. You can always ask for feedback on the dev list, pointing people to
the branch or commit messages.
Of course people can still give feedback after the commit, including a -1 vote
to back out a change (with a valid technical reason).
This is "commit-then-review" style, I believe it's the most efficient, remember
it's all under SCM, so any change can always be backed out.
Dan.
