My suggestion implies some prior steps to commit a change.
If we use the forking model (via the mirror) a pull request will be
reviewed prior to the merge into the Apache Git Repo.
If we call a release we will create a new branch for it, e.g. v1.0.0.
This will prevent unwanted commits to fly in the release, but allows the
ongoing development to proceed. The release branch will be reviewed
prior to voting, so we can validate its functionality.
Hope this clarifies my suggestion.
Best,
Markus
.::YAGNI likes a DRY KISS::.
On 12/29/2015 09:29 AM, Adi Raju wrote:
Need some more clarity.
If we use CTR, how do we control the release timelines. I mean, if we get a
commit at the last minute or commits with partial fix/regressions, wouldn't
this create issues with release timeline?
Am I right to assume, release RTC process starts X days before planned
release date, so that issues identified can be fixed?
Do we allow releases to be made with known bugs?
Regards,
Adi
-----Original Message-----
From: Markus Geiß [mailto:[email protected]]
Sent: 25 December 2015 20:51
To: [email protected]
Subject: RE: [DISCUSS] Git procedure and branching model
The ASF doesn't create personal repositories, so the Forking Workflow
isn't available. I'd recommend just using branches within the main repo.
Just to be clear, I was talking about the general approach for
contributions, I guess the usual way is to fork the mirror and send pull
requests ... the 'real' git repo is handled in a different.
It's good that we agree on the Gitflow branching model, though.
Which doc? I need to fix it :-)
Here you'll find the blue print for the email:
http://www.apache.org/foundation/voting.html#LazyConsensus ... a similar
sentence can be found here too:
http://www.apache.org/foundation/glossary.html#LazyConsensus ... (and even
http://community.apache.org/committers/lazyConsensus.html states 'express
support or objections') ; o)
Best,
Markus
.::YAGNI likes a DRY KISS::.
Date: Thu, 24 Dec 2015 17:03:22 -0600
Subject: Re: [DISCUSS] Git procedure and branching model
From: [email protected]
To: [email protected]
Which doc? I need to fix it :-)
On Thu, Dec 24, 2015 at 2:19 PM, <[email protected]> wrote:
thanks for the feedback ... I think jira issues are simply a good
way of organizing work ... you see what is going on w/out reading a
bunch email threads.
The sample commit message I've used was directly copied from the ASF
documentation ... but I'm fine doing a commit instead of pre calling
it out that makes totally more sense to me.
Cheers
Markus
::: YAGNI likes a DRY KISS :::
On Thu, Dec 24, 2015 at 11:54 AM -0800, "Roman Shaposhnik" <
[email protected]> wrote:
On Thu, Dec 24, 2015 at 9:02 AM, Greg Stein <[email protected]> wrote:
Feature branches should be created using the name of the JIRA
issue
which
is to be solved.
If you discuss a feature on the dev@ list, then why create a JIRA
issue?
The community already knows a feature is going to be developed. No
need
to
create an issue for it.
I disagree. I find JIRA a much more flexible tool for tracking on
going work on the project. JIRA allows me things like registering
for notifications, integration with GH pull requests, etc. that are
simply too tedious to do using pure mailing list workflow.
Now, I agree with you that fixing a one liner probably shouldn't
require JIRA -- everything else just use JIRA as your community TODO
list.
In fact, enter *ideas* into JIRA, keep things marked for newbies, etc.
etc.
This is, again, where JIRA shines over mailing list -- if somebody
new comes to the community and asks how she or he can help -- it is
much easier to point a JIRA query that would give you exact list of
issues than a pointer to mailing list discussions or wiki.
Meta: JIRA is busy-work, if used for features.
Not always. I fine it useful, for example, to track evolution of a
proposals or blueprints. And yes, certain feaatures will require
those documents to get buy-in from the community.
I suggest to use the CTR[5] (commit then review) model for code
modifications, and RTC[6] (review then commit) for package
releases. We should not mismatch review with a code review. A
code review should be
done
based on the pull request and prior to commit the changes into
the main repository. Once this process has finished, a vote based
on lazy
consensus
is initiated with a message like "This solves issue
FINERACT-1234, if no-one objects within three days, I'll assume
lazy consensus and commit
it."
That is not CTR. Commit straight away. Don't wait. "This looks
good to
me.
<commit>"
You use the term "object", but that isn't quite right. Commit the
change.
Others can review. If they have *issues* with the change, then you
begin
a
discussion. Not an objection.
The goal is to *fix* what was committed. Not to object to it, and
roll it back. When the commit lands in the repository, then review
happens (CTR).
And based on the review, further changes can be applied.
Remember: this is version control. There is no reason to "object".
There
is
no reason to vote. Everything goes into version control with the
lowest barrier possible. Let people directly commit to a branch,
or even to the "develop" main branch. Why not? If it breaks something,
then fix it.
Worst
case, it can always be backed out.
TRUST each other to commit working code, and fixes, and new features.
Trust
is a huge issue. Please don't erect barriers. Please don't control
the repository via JIRA. Let people write and commit code. Give
them room,
and
let them work. Contributions are *always* a bonus, and very rarely
a
harm.
So optimize for the former.
Huge +1 to the above!
Thanks,
Roman.
