Nope. But perhaps over the weekend or early next week?
On 7 June 2013 20:37, Randall Leeds wrote:
> On Fri, Jun 7, 2013 at 1:30 AM, Noah Slater wrote:
> > Randall, how do you fancy doing a release? I can mentor you. (I'm gonna
> do
> > the same for Dirkjan.)
> >
> > Would like to get a few mor
On Fri, Jun 7, 2013 at 1:30 AM, Noah Slater wrote:
> Randall, how do you fancy doing a release? I can mentor you. (I'm gonna do
> the same for Dirkjan.)
>
> Would like to get a few more eyeballs on the release procedure. Think this
> might help you as you drive the Git stuff also.
>
> Was planning
Randall, how do you fancy doing a release? I can mentor you. (I'm gonna do
the same for Dirkjan.)
Would like to get a few more eyeballs on the release procedure. Think this
might help you as you drive the Git stuff also.
Was planning to do a release today, but could pause that and walk you
throug
On Thu, Jun 6, 2013 at 4:36 AM, Garren Smith wrote:
> Bob and Benoit make sense. As long has we define clearly how our commit
> messages should be. I must admit as a newish committer I've taken some
> liberties with my commit messages purely because I'm not aware of a standard
> way of doing it
On Thu, Jun 6, 2013 at 12:39 PM, Noah Slater wrote:
> My concern with commit messages -> release notes is that we're human, and
> mistakes will happen. How easy will it be to go in and edit commit
> messages? If we can do that, then we can write a tool that generates the
> release notes, and put t
Bob and Benoit make sense. As long has we define clearly how our commit
messages should be. I must admit as a newish committer I've taken some
liberties with my commit messages purely because I'm not aware of a standard
way of doing it.
On 06 Jun 2013, at 1:17 PM, Jason Smith wrote:
> Agree
Agreed!
On Thu, Jun 6, 2013 at 5:48 PM, Robert Newson wrote:
> Ok, I think everyone is over-reading my suggestion to drive release
> notes from commit messages. I'm sure there will always be a manual,
> human step to convert the commit messages between two points into
> release notes, I'm just
Ok, I think everyone is over-reading my suggestion to drive release
notes from commit messages. I'm sure there will always be a manual,
human step to convert the commit messages between two points into
release notes, I'm just saying that if we are consistent with our
commit messages and take the ti
My concern with commit messages -> release notes is that we're human, and
mistakes will happen. How easy will it be to go in and edit commit
messages? If we can do that, then we can write a tool that generates the
release notes, and put the onus on committers to edit commit messages as
necessary un
On Thu, Jun 6, 2013 at 10:26 AM, Benoit Chesneau wrote:
> On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith wrote:
>> I agree with Jason and Bob, the simplest way is going to be the easiest for
>> us to implement.
>>
>> With us wanting to use commit messages in the release notes, could we not
>> mar
I kind of share Garren's question of whether commit messages can convert
into release notes. But I figured I'd let it it play out to see how it
works. What if somebody refactors code to remove some bloat?
I still like it, because the perfect is the enemy of the good. It will
still take manual effo
On Thu, Jun 6, 2013 at 9:58 AM, Garren Smith wrote:
> I agree with Jason and Bob, the simplest way is going to be the easiest for
> us to implement.
>
> With us wanting to use commit messages in the release notes, could we not
> mark specific commit messages e.g. [Release Notes] so that only spe
I agree with Jason and Bob, the simplest way is going to be the easiest for us
to implement.
With us wanting to use commit messages in the release notes, could we not mark
specific commit messages e.g. [Release Notes] so that only specific commit
messages get added into the release notes and ot
To a first approximation, I like Bob Newson's idea (option 1 in the
OP). It seems the most workable for a large distributed team of
volunteers.
I am probably a bad teammate, but I always find myself forgetting or
misunderstanding policies and changes to policies. So I like the
simplest, most intui
On 24 May 2013 19:51, Benoit Chesneau wrote:
>
> More useful than these links hat is your summary about this activity?
I'm not sure my summary would be useful to anyone. I don't understand the
issues. I care more about getting this resolved than the implementation
details. I just trust y'all to
On Fri, May 24, 2013 at 6:32 PM, Noah Slater wrote:
> Activity from elsewhere:
>
> http://markmail.org/message/5pxv3ni6qvc2k2jo
>
> http://markmail.org/message/czkylvo2wvbrrikj
>
> http://markmail.org/message/2ybvoo2yjwxmfwze
>
> http://markmail.org/message/ohjwjh6ri72yuagh
>
> http://markmail.org
Activity from elsewhere:
http://markmail.org/message/5pxv3ni6qvc2k2jo
http://markmail.org/message/czkylvo2wvbrrikj
http://markmail.org/message/2ybvoo2yjwxmfwze
http://markmail.org/message/ohjwjh6ri72yuagh
http://markmail.org/message/v767rozacnwowlpg
http://markmail.org/message/ftbd5qbv33iq7ux
On Tue, Apr 30, 2013 at 9:02 PM, Dave Cottlehuber wrote:
> On 30 April 2013 15:57, Noah Slater wrote:
>> snip
>
> Of note against rebasing merges, is this:
> http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
>
> TL;DR rebase gives a linear history but the timestam
On 30 April 2013 15:57, Noah Slater wrote:
> snip
Of note against rebasing merges, is this:
http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase
TL;DR rebase gives a linear history but the timestamps by default
remain the originals. i.e. your history now time travel
On 30 April 2013 08:09, Dave Cottlehuber wrote:
> On 30 April 2013 01:50, Noah Slater wrote:
> > As far as I understand it them, master becomes the place I cut release
> > candidates from. It is the place that is "ready to ship" at all points.
> > Which is a slight departure from how we have ope
On Tue, Apr 30, 2013 at 12:06 AM, Robert Newson wrote:
> If production branches follow that rule then there will be broken
> commits that won't build. A feature, or fix, will not land atomically,
> but in all its constituent parts. That's the thing we are striving to
> avoid.
>
Well a feature or
On 30 April 2013 01:50, Noah Slater wrote:
> As far as I understand it them, master becomes the place I cut release
> candidates from. It is the place that is "ready to ship" at all points.
> Which is a slight departure from how we have operated previous.
I like this, especially if we can work on
As far as I understand it them, master becomes the place I cut release
candidates from. It is the place that is "ready to ship" at all points.
Which is a slight departure from how we have operated previous.
If you commit a feature to master with breaking changes, then all that
happens it that in t
If production branches follow that rule then there will be broken
commits that won't build. A feature, or fix, will not land atomically,
but in all its constituent parts. That's the thing we are striving to
avoid.
Do I misunderstand you?
B.
On 29 April 2013 23:00, Benoit Chesneau wrote:
> imo p
imo production branches should only be rebased, no merge so you keep
the history easier for people asynchronously branching from
productions branch. merges can be really difficult to handle along the
time when you have a branch that differs a lot.
Also this is why the develop branch exist, so peop
I like the idea of +1's to merge from topic to production branch.
B.
On 29 April 2013 22:23, Dave Cottlehuber wrote:
> On 25 April 2013 23:57, Randall Leeds wrote:
>> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson wrote:
>>>
>>> If we enhance the #1 proposal to include a final rebase against m
On 25 April 2013 23:57, Randall Leeds wrote:
> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson wrote:
>>
>> If we enhance the #1 proposal to include a final rebase against master
>> before merge, then master will be truly linear. That will make for
>> easier reading, easier backporting and will en
yes, merge, don't cherry-pick. We'll only cherry-pick to backport fixes.
so, rebase before merging, but don't squash. We'll get ff merges for
single item branches and 'proper' merges for multiple item branches,
which sounds like what we're agreeing on.
I'd say development is on fix- and feature-
On Mon, Apr 29, 2013 at 6:59 AM, Robert Newson wrote:
> Bah, I meant: I'm +0 on single commits merging from topic to master withOUT
> a merge commit.
>
> On 29 April 2013 14:58, Robert Newson wrote:
>> Ok, my proposal is #1 from my original post with the refinement from
>> Randall which I think
Quite in phase of what I proposed 6 months ago:
http://markmail.org/thread/ec3okssflzbms4pw
- benoit
On Mon, Apr 29, 2013 at 3:48 PM, Noah Slater wrote:
> Does anybody have any other thoughts on this? We need to choose something
> as soon as possible.
>
>
> On 25 April 2013 23:01, Robert Newson
Bah, I meant: I'm +0 on single commits merging from topic to master withOUT
a merge commit.
On 29 April 2013 14:58, Robert Newson wrote:
> Ok, my proposal is #1 from my original post with the refinement from
> Randall which I think we can distill as "you must not flatten a commit
> set". If your
Ok, my proposal is #1 from my original post with the refinement from
Randall which I think we can distill as "you must not flatten a commit
set". If your topic branch is best represented as >1 commit, then it
must land on master as a merge commit. The other way to say it is that
no topic branch is
Does anybody have any other thoughts on this? We need to choose something
as soon as possible.
On 25 April 2013 23:01, Robert Newson wrote:
> Another point in favour of merge commits (non-ff) is that the branch
> merged to leaps forward atomically. It might not be appropriate to see
> the inter
On 25 April 2013 23:16, Randall Leeds wrote:
>
> If we are reliable about forward compatibility and breaking changes
>
That's the plan!
> In practice it's identical (keep around as many versions as makes
> sense for supporting real users), but the numbering does change.
>
Right, so we'd keep
On Thu, Apr 25, 2013 at 3:08 PM, Noah Slater wrote:
> Splitting this off to let the Git conversation continue
> without interruption.
>
>
> On 25 April 2013 22:54, Dale Harvey wrote:
>
>> The Roadmap looks good, I would worry that the point of semver is that you
>> dont need to support 1.0.X / 1
Not to the thread, I have spun off Dale's excellent point about release
branches into a new thread. I have done this because it doesn't effect this
conversion, and I want to keep us focused on Git workflow.
(It doesn't effect this conversation, because no matter what we decide,
we'll still want to
Splitting this off to let the Git conversation continue
without interruption.
On 25 April 2013 22:54, Dale Harvey wrote:
> The Roadmap looks good, I would worry that the point of semver is that you
> dont need to support 1.0.X / 1.1.X / 1.2.X and 1.3.X as they are all
> guaranteed to be forwar
Another point in favour of merge commits (non-ff) is that the branch
merged to leaps forward atomically. It might not be appropriate to see
the intermediate tree for a feature that consists of multiple commits.
B.
On 25 April 2013 22:59, Robert Newson wrote:
> "I'm not sure where this notion tha
"I'm not sure where this notion that bisecting with merge
commits is harder comes from."
>From personal experience, but I concede this might point to my
deficiency and not git's.
On 25 April 2013 22:57, Randall Leeds wrote:
> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson wrote:
>>
>> If we enh
On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson wrote:
>
> If we enhance the #1 proposal to include a final rebase against master
> before merge, then master will be truly linear. That will make for
> easier reading, easier backporting and will enable bisecting when
> spelunking for regressions, et
Speaking as someone who's used git-flow in a small-corporate context (and
not as someone who is likely to be contributing overmuch, so huge grains of
salt), I'd like to make a couple of observations:
- Git flow also presumes that the integration branch ("develop" according
to the defaults, though
On 25 April 2013 22:35, Robert Newson wrote:
> I'll toss this in too: https://sandofsky.com/blog/git-workflow.html
>
> In particular;
>
> "If you treat your public history as pristine, fast-forward merges are
> not only safe but preferable. They keep revision history linear and
> easier to follow
I'll toss this in too: https://sandofsky.com/blog/git-workflow.html
In particular;
"If you treat your public history as pristine, fast-forward merges are
not only safe but preferable. They keep revision history linear and
easier to follow"
I think this also addresses Paul's objections to merge c
Dale,
Take a look at the proposed roadmap process and let me know what you think.
http://wiki.apache.org/couchdb/Roadmap_Process
On 25 April 2013 22:03, Dale Harvey wrote:
> #1 is the procedure almost every project I have worked on follows, we do
> actually have an integration branch at mozil
#1 is the procedure almost every project I have worked on follows, we do
actually have an integration branch at mozilla but that is purely due to
the sheer size of the codebase and volume of changes, I see no reason why
CouchDB shouldnt be permanently releasable or why a release would be
'ongoing',
Thanks for kicking this off, Bob!
Option 1 would require us to change how we think about master. If a release
is ongoing (which will almost certainly be the case, month over month) then
work is going to need to be merged when it is okayed by the release manager.
In this scenario, to we might wan
46 matches
Mail list logo
