On Tue, Dec 29, 2015 at 10:12 AM, Markus Geiss wrote:
> Looks like attachments won't work, so let me try to explain in
> words. ; o)
>
> We use the branch develop for ongoing new feature, enhancements,
> and bug fixe development. Aside from really small changes
> (like a typo), a developer/contri
Looks like attachments won't work, so let me try to explain in
words. ; o)
We use the branch develop for ongoing new feature, enhancements,
and bug fixe development. Aside from really small changes
(like a typo), a developer/contributor creates a feature branch
for his development effort. Once he
Sometimes an image is worth a thousand words. Please find attached two
images that visualize the workflow I was talking about. The workflows
are not on a detail level, they simply provide an overview.
Best,
Markus
.::YAGNI likes a DRY KISS::.
On 12/29/2015 04:11 PM, Markus Geiss wrote:
I th
+1
Best,
Markus
.::YAGNI likes a DRY KISS::.
On 12/29/2015 04:04 PM, Greg Stein wrote:
On Tue, Dec 29, 2015 at 2:29 AM, Adi Raju
wrote:
...
Do we allow releases to be made with known bugs?
In my 30 years of professional software experience ... YES.
There are always bugs in the softwa
I think we're talking about the same thing here.
Just one exception, I'd suggest a code review based on agreed coding
standards to keep the code clean and in line with what is needed.
I see a difference between a committer, who has the right to pull in
changes directly, without an agreement b
On Tue, Dec 29, 2015 at 2:29 AM, Adi Raju
wrote:
>...
> Do we allow releases to be made with known bugs?
>
In my 30 years of professional software experience ... YES.
There are always bugs in the software that gets released. Some known, some
unknown. If there are *known* bugs, then the communit
I'm not sure if I'm reading Markus' post correctly, so let me throw out
some specific commentary...
CTR implies that any committer can push any change, any time. Unilaterally,
without prior consent. That change can come from a pull request, or it can
arrive from original work. Doesn't matter. A co
Hey all,
hope this finds you well. : o)
I need to adjust the permissions once again. Looks like a spambot was
able to create an account at the Apache Confluence page and has created
a page where you can buy cheap Nike shoes.
I will revoke all permissions from the confluence-users and add you
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
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 da
10 matches
Mail list logo
