On Thu, Oct 20, 2011 at 7:44 PM, Robert Newson rnew...@apache.org wrote:
This is the second release vote for Apache CouchDB 1.1.1
Changes since round 1;
* Fix object sealing with SpiderMonkey 1.7.0
* Update CHANGES/NEWS to reflect COUCHDB-1129
* Fix JavaScript CLI test runner
We encourage
On Fri, Oct 21, 2011 at 8:51 AM, Benoit Chesneau bchesn...@gmail.com wrote:
+0 . tests doesn't pas on 0SX lion . I think at least READMe should be
s/doesn't/don't
tests (js+ check + signature) are ok on other platforms tested
(freebsd 8.2 osx 10.6) .
with erlang R14B03 R14B04
On Oct 20, 2011, at 9:03 PM, Paul Davis wrote:
Your argument here and the earlier argument about branches being
temporary tags confuses me. Both are nothing more than pointers at
hashes. This is just a social distinction. This entire thread is
considering social distinctions about community
+1
On 21 October 2011 05:06, Paul Davis paul.joseph.da...@gmail.com wrote:
On Thu, Oct 20, 2011 at 7:26 PM, Noah Slater nsla...@tumbolia.org wrote:
Hey,
On advice from Gavin McDonald, I'd like to suggest that we lock down the
wiki to a list of pre-approved users. To get approved to make
On Fri, Oct 21, 2011 at 2:26 AM, Noah Slater nsla...@tumbolia.org wrote:
Hey,
On advice from Gavin McDonald, I'd like to suggest that we lock down the
wiki to a list of pre-approved users. To get approved to make edits, you
would submit a request to one of the mailing lists or to one of the
Hi,
My 2c from the gallery. I'm not involved in CouchDB, so just making
general observations from the perspective of other Apache projects
interested in using Git.
On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
As Noah points out, there are ASF procedural issues
+0
OS X 10.7.2
Erlang R14B
make distcheck is fine
only two tests fail this time, changes and cookie_auth
On Oct 20, 2011, at 1:44 PM, Robert Newson wrote:
This is the second release vote for Apache CouchDB 1.1.1
Changes since round 1;
* Fix object sealing with SpiderMonkey 1.7.0
*
On Thursday, 20 October 2011, Robert Newson rnew...@apache.org wrote:
This is the second release vote for Apache CouchDB 1.1.1
Changes since round 1;
* Fix object sealing with SpiderMonkey 1.7.0
* Update CHANGES/NEWS to reflect COUCHDB-1129
* Fix JavaScript CLI test runner
We encourage
On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
My 2c from the gallery. I'm not involved in CouchDB, so just making
general observations from the perspective of other Apache projects
interested in using Git.
On Fri, Oct 21, 2011 at 5:51 AM, Paul Davis
If other projects jumped off a cliff, would couch? I, for one, say no.
B.
On 21 October 2011 17:33, Paul Davis paul.joseph.da...@gmail.com wrote:
On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Hi,
My 2c from the gallery. I'm not involved in CouchDB, so just
On Oct 21, 2011, at 12:33 PM, Paul Davis wrote:
On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Hi,
My 2c from the gallery. I'm not involved in CouchDB, so just making
general observations from the perspective of other Apache projects
interested in using
I'll also note that 'git pull --tags' will update any tags that have
changed, despite what the man page for git-tags actually says.
B.
On 21 October 2011 17:39, Robert Dionne dio...@dionne-associates.com wrote:
On Oct 21, 2011, at 12:33 PM, Paul Davis wrote:
On Fri, Oct 21, 2011 at 4:28 AM,
FWIW, I don't think this isn't going to work for us.
I will post a full explanation later today when I have some free time.
On Fri, Oct 21, 2011 at 5:33 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
On Fri, Oct 21, 2011 at 4:28 AM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
Hi,
My
To JIRA you mean?
On Fri, Oct 21, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.comwrote:
On Fri, Oct 21, 2011 at 2:26 AM, Noah Slater nsla...@tumbolia.org wrote:
Hey,
On advice from Gavin McDonald, I'd like to suggest that we lock down the
wiki to a list of pre-approved users. To
Actually, I think I'm going to give this a -1 without testing it.
We still haven't ratified how releases are meant to work with Git, so I
don't see that we can make a release at the present time. We need to agree
on how we're going to do this, and document it in both the release procedure
and
On Friday, October 21, 2011, Noah Slater nsla...@tumbolia.org wrote:
To JIRA you mean?
yes
On Fri, Oct 21, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Fri, Oct 21, 2011 at 2:26 AM, Noah Slater nsla...@tumbolia.org
wrote:
Hey,
On advice from Gavin McDonald, I'd like
Just to clarify, I reached this conclusion after seeing:
http://wiki.apache.org/couchdb/Release_procedure?action=diffrev1=66rev2=67
It occurred to me that we're attempting to release without documenting what
we're doing first. The documentation above is incomplete. Our official
release procedure
Sounds good to me.
On Fri, Oct 21, 2011 at 5:55 PM, Benoit Chesneau bchesn...@gmail.comwrote:
On Friday, October 21, 2011, Noah Slater nsla...@tumbolia.org wrote:
To JIRA you mean?
yes
On Fri, Oct 21, 2011 at 10:27 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Fri, Oct 21, 2011
On Oct 21, 2011, at 18:53 , Noah Slater wrote:
Actually, I think I'm going to give this a -1 without testing it.
We still haven't ratified how releases are meant to work with Git, so I
don't see that we can make a release at the present time. We need to agree
on how we're going to do this,
That ignores the number of releases performed prior to the creation of
that page. The release tarball contains the right stuff. Since the
process is not fully automated and has never been fully documented, I
don't think your -1 is fair.
However, it seems the recent addition of help to couchjs is
On Oct 21, 2011, at 18:57 , Noah Slater wrote:
Sounds good to me.
Open a JIRA to get a wiki account sounds very bad to me.
I understand we gotta get the spam under control, but asking
people to sign up in two places and put a potentially long
manual setup process will kill almost any
On Fri, Oct 21, 2011 at 12:06 PM, Jan Lehnardt j...@apache.org wrote:
On Oct 21, 2011, at 18:57 , Noah Slater wrote:
Sounds good to me.
Open a JIRA to get a wiki account sounds very bad to me.
I understand we gotta get the spam under control, but asking
people to sign up in two places and
On Fri, Oct 21, 2011 at 8:20 AM, Dave Cottlehuber d...@muse.net.nz wrote:
On Thursday, 20 October 2011, Robert Newson rnew...@apache.org wrote:
This is the second release vote for Apache CouchDB 1.1.1
Changes since round 1;
* Fix object sealing with SpiderMonkey 1.7.0
* Update CHANGES/NEWS
On Fri, Oct 21, 2011 at 10:05, Robert Newson rnew...@apache.org wrote:
That ignores the number of releases performed prior to the creation of
that page. The release tarball contains the right stuff. Since the
process is not fully automated and has never been fully documented, I
don't think
All,
I'm aborting round 2 because of the lack of basename() on Windows.
Round 3 to follow.
nslater: Can we decide now if we're sticking with (approximately) the
release procedure we've been following so far or whether we have to
nail down all the git things and document before round 3 can
On Fri, Oct 21, 2011 at 6:04 PM, Jan Lehnardt j...@apache.org wrote:
I think the silent consensus to not change the procedure for stable
branches
and ongoing votes.
Could you clarify?
And I don't buy the incomplete wiki documentation missing the git and
still
having the SVN commands in
On Fri, Oct 21, 2011 at 6:05 PM, Robert Newson rnew...@apache.org wrote:
That ignores the number of releases performed prior to the creation of
that page. The release tarball contains the right stuff. Since the
process is not fully automated and has never been fully documented, I
don't think
On Fri, Oct 21, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
nslater: Can we decide now if we're sticking with (approximately) the
release procedure we've been following so far or whether we have to
nail down all the git things and document before round 3 can begin?
The actual
Yeah, I don't think we need a Procedure™ in place for this.
Basically, as long as a wiki admin adds you to the contributor list, you're
good to go. How you reach out to that admin, or how they find out about your
request, is unimportant. We should present plenty of options for people to
contact
On Oct 21, 2011, at 9:43 AM, Robert Newson wrote:
I'll also note that 'git pull --tags' will update any tags that have
changed, despite what the man page for git-tags actually says.
dustinnmb:/tmp/test 695% mkdir upstream
dustinnmb:/tmp/test 696% cd upstream/
dustinnmb:/tmp/test/upstream
I wonder what the demography is of contributors. Are they all contributors and
list members, or is there a reasonable portion of users that just walk by, fix
something and walk on.
On Oct 21, 2011, at 7:58 PM, Noah Slater wrote:
Yeah, I don't think we need a Procedure™ in place for this.
On Fri, Oct 21, 2011 at 10:28 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:
I'd say that's a perfectly valid use of tags. An official release
should be backed by a tag, but there's no requirement for the reverse.
Using tags for release candidates or other milestones should also be
fine. It
On Fri, Oct 21, 2011 at 7:04 PM, Dustin Sallings dus...@spy.net wrote:
IMO, simplicity and conventions win here. Tags should be treated as
immutable pointers to commits that had some meaning and should be named and
labeled meaningfully as well. Branches are pointers to works in progress.
Yes, quite reasonable.
My take on tagging was to follow what we did with SVN with only minor
changes to account for git. So I shall describe it.
First, I create a signed tag for the release, with its intended final
release value. In this case, exactly the string '1.1.1'. Then I build
artifacts
Most productive edits come from regular contributors or members of the
community. Most drive-by edits come from spammers. In fact, there are some
spammers with genuine accounts, who make very purposeful and directed edits
to inject links inconspicuously.
On Fri, Oct 21, 2011 at 7:06 PM, Pepijn de
Can you post this over on the tagging thread? :)
On Fri, Oct 21, 2011 at 7:13 PM, Robert Newson rnew...@apache.org wrote:
Yes, quite reasonable.
My take on tagging was to follow what we did with SVN with only minor
changes to account for git. So I shall describe it.
First, I create a
+1 on Noah's non-Procedure.
B.
On 21 October 2011 19:14, Noah Slater nsla...@tumbolia.org wrote:
Most productive edits come from regular contributors or members of the
community. Most drive-by edits come from spammers. In fact, there are some
spammers with genuine accounts, who make very
Dustin,
/tmp/bar $ git --version
git version 1.7.6.1
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/foo
- [tag update] 1.0-
On 21 October 2011 19:14, Paul Davis paul.joseph.da...@gmail.com wrote:
On Fri, Oct 21, 2011 at 8:20 AM, Dave Cottlehuber d...@muse.net.nz wrote:
On Thursday, 20 October 2011, Robert Newson rnew...@apache.org wrote:
This is the second release vote for Apache CouchDB 1.1.1
Changes since round
From the other thread, reposted here on Noah's suggestion;
My take on tagging was to follow what we did with SVN with only minor
changes to account for git. So I shall describe it.
First, I create a signed tag for the release, with its intended final
release value. In this case, exactly the
Hmmm ... that's all well and good, but I envision more confusion ensuing in the
case where we have multiple possible values for '1.1.1' floating around the
internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2', and
eventually one single immutable '1.1.1'. Best,
Adam
On Oct
Sorry for the self-reply, but I read the thread of Bob's comment and I see that
he dismissed my concern as irrelevant. Well, fine then :) If you want to
solve this by fiat and say that users are not allowed to rely on their local
copies of our signed tags as authoritative then these debates
On Oct 21, 2011, at 20:17 , Robert Newson wrote:
+1 on Noah's non-Procedure.
I claim that non-Procedure, good sir.
Cheers
Jan
--
B.
On 21 October 2011 19:14, Noah Slater nsla...@tumbolia.org wrote:
Most productive edits come from regular contributors or members of the
community.
On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/foo
- [tag update] 1.0-
Can we do something like this:
On Fri, Oct 21, 2011 at 8:42 PM, Dustin Sallings dus...@spy.net wrote:
On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3
On Oct 21, 2011, at 3:42 PM, Dustin Sallings wrote:
On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100%
On Oct 21, 2011, at 21:26 , Adam Kocoloski wrote:
Hmmm ... that's all well and good, but I envision more confusion ensuing in
the case where we have multiple possible values for '1.1.1' floating around
the internet than I do in the case where we have '1.1.1-rc1', '1.1.1-rc2',
and
On Oct 21, 2011, at 21:51 , Adam Kocoloski wrote:
On Oct 21, 2011, at 3:42 PM, Dustin Sallings wrote:
On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta
... Okay. Not sure what happened there. So, uh...
Can we do something like this:
It's the first round of voting, so we tag to:
vote/X.Y.X-1
This vote fails, so we move on to the second round of voting, and we tag to:
vote/X-Y.X-2
This vote passes, so we copy the tag to:
On Fri, Oct 21, 2011 at 7:29 PM, Robert Newson rnew...@apache.org wrote:
The arguments in the other thread about immutable tags are laudable
but irrelevant. The tags in our source control system are not the
source of truth for our releases. The presence of the release on the
Apache mirrors is.
On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski kocol...@apache.org wrote:
Good suggestion on the -vote1 suffix instead of -rc1. Gets my vote. Best,
It sounds trivial, but I think it's important to namespace these instead of
using suffixes.
On Oct 21, 2011, at 21:57 , Noah Slater wrote:
On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski kocol...@apache.org wrote:
Good suggestion on the -vote1 suffix instead of -rc1. Gets my vote. Best,
It sounds trivial, but I think it's important to namespace these instead of
using
On Oct 21, 2011, at 3:57 PM, Noah Slater wrote:
On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski kocol...@apache.org wrote:
Good suggestion on the -vote1 suffix instead of -rc1. Gets my vote. Best,
It sounds trivial, but I think it's important to namespace these instead of
using
On Fri, Oct 21, 2011 at 8:57 PM, Noah Slater nsla...@tumbolia.org wrote:
On Fri, Oct 21, 2011 at 8:54 PM, Adam Kocoloski kocol...@apache.orgwrote:
Good suggestion on the -vote1 suffix instead of -rc1. Gets my vote.
Best,
It sounds trivial, but I think it's important to namespace these
On Fri, Oct 21, 2011 at 9:03 PM, Adam Kocoloski kocol...@apache.org wrote:
Sure, that works. It makes little difference to me. Why do you think it's
important?
It's important for the list of tags people see in the repository.
Compare:
vote/1.1.1/1
vote/1.1.1/2
vote/1.1.1/3
vote/1.2.0/1
On Fri, Oct 21, 2011 at 2:42 PM, Dustin Sallings dus...@spy.net wrote:
On Oct 21, 2011, at 11:25 AM, Robert Newson wrote:
/tmp/bar $ git pull --tags
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking
On Oct 21, 2011, at 4:07 PM, Noah Slater wrote:
On Fri, Oct 21, 2011 at 9:03 PM, Adam Kocoloski kocol...@apache.org wrote:
Sure, that works. It makes little difference to me. Why do you think it's
important?
It's important for the list of tags people see in the repository.
Compare:
On Oct 21, 2011, at 12:57 PM, Noah Slater wrote:
It sounds trivial, but I think it's important to namespace these instead of
using suffixes.
The only practical difference is the grep you use when looking for
stuff, IMO. I think it will be unambiguous, but a bit less consistent with
On Fri, Oct 21, 2011 at 1:26 PM, Dave Cottlehuber d...@muse.net.nz wrote:
On 21 October 2011 19:14, Paul Davis paul.joseph.da...@gmail.com wrote:
On Fri, Oct 21, 2011 at 8:20 AM, Dave Cottlehuber d...@muse.net.nz wrote:
On Thursday, 20 October 2011, Robert Newson rnew...@apache.org wrote:
This
On 21 October 2011 19:56, Noah Slater nsla...@tumbolia.org wrote:
On Fri, Oct 21, 2011 at 6:23 PM, Robert Newson rnew...@apache.org wrote:
nslater: Can we decide now if we're sticking with (approximately) the
release procedure we've been following so far or whether we have to
nail down all
Hi,
On Fri, Oct 21, 2011 at 6:33 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
Are there projects that do this version incrementing when a vote
fails? That's an idea I haven't heard before.
I learned it from httpd (there's plenty of version number gaps at
Here's another suggestion.
In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.
When the release passes the votes, we create the tag, with its final
name, against that commit id, and push it at the same time we upload
the artifact to
On 21 October 2011 22:20, Dustin Sallings dus...@spy.net wrote:
On Oct 21, 2011, at 12:57 PM, Noah Slater wrote:
It sounds trivial, but I think it's important to namespace these instead of
using suffixes.
The only practical difference is the grep you use when looking for
stuff,
On 21 October 2011 23:47, Dave Cottlehuber d...@muse.net.nz wrote:
My 2c;
* This is a long-lived project. At 3+ releases/year + votes this will
over time get quite long. Some cleaning would be good.
Sorry this wasn't correct. I'm not proposing any git rewriting, rather
that adding tags for
Great minds, etc.
On 21 October 2011 22:50, Dave Cottlehuber d...@muse.net.nz wrote:
On 21 October 2011 23:47, Dave Cottlehuber d...@muse.net.nz wrote:
My 2c;
* This is a long-lived project. At 3+ releases/year + votes this will
over time get quite long. Some cleaning would be good.
Sorry
On Oct 21, 2011, at 2:23 PM, Robert Newson wrote:
In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.
When the release passes the votes, we create the tag, with its final
name, against that commit id, and push it at the same
On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson rnew...@apache.org wrote:
Here's another suggestion.
In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.
When the release passes the votes, we create the tag, with its final
name,
The only annoying factor is that I can no longer delete the 1.1.1 tag
(I have deleted it before);
~/source/couchdb $ git push origin :refs/tags/1.1.1
remote: env: python: No such file or directory
So, unless someone else can delete it, it will hang around until I
change it to its final value. I
On Fri, Oct 21, 2011 at 11:14 PM, Robert Newson rnew...@apache.org wrote:
The only annoying factor is that I can no longer delete the 1.1.1 tag
This seems odd.
I thought there was always a way to undo things in Git?
So, unless someone else can delete it, it will hang around until I
change
The command should work, it seems like a server-side bug. As I said, I
deleted the round 1 1.1.1 tag and made a new one for round 2, so it's
worked before (and quite recently).
Is it just me?
B.
On 21 October 2011 23:19, Noah Slater nsla...@tumbolia.org wrote:
On Fri, Oct 21, 2011 at 11:14 PM,
On Oct 21, 2011, at 6:06 PM, Noah Slater wrote:
On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson rnew...@apache.org wrote:
Here's another suggestion.
In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.
When the release
On Oct 21, 2011, at 4:52 PM, Adam Kocoloski wrote:
`git describe` would read something like 1.1.0-N-deadbeef, where N is the
number of commits since the last tag. On .0 releases it would probably just
be the commit hash since the commit would not be a descendant of any tags.
It's a neat
On Sat, Oct 22, 2011 at 1:25 AM, Dustin Sallings dus...@spy.net wrote:
It would be terribly unfortunate if there was no trackable lineage between
releases. If version 1.2 does not contain version 1.1, then what does it
contain?
I don't follow this comment at all. 1.2 does not necessarily
On Oct 21, 2011, at 8:25 PM, Dustin Sallings wrote:
On Oct 21, 2011, at 4:52 PM, Adam Kocoloski wrote:
`git describe` would read something like 1.1.0-N-deadbeef, where N is the
number of commits since the last tag. On .0 releases it would probably just
be the commit hash since the
On Oct 21, 2011, at 5:42 PM, Noah Slater wrote:
I don't follow this comment at all. 1.2 does not necessarily have everything
1.1 has in it. They may even diverge when we get down to the bugfix version.
Releases are tagged from release branches which are split from trunk.
Sometimes we apply
A VAR or system integrator's perspective:
On Sat, Oct 22, 2011 at 2:54 AM, Noah Slater nsla...@tumbolia.org wrote:
... Okay. Not sure what happened there. So, uh...
Can we do something like this:
It's the first round of voting, so we tag to:
vote/X.Y.X-1
Please reconsider semantic
On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater nsla...@tumbolia.org wrote:
On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson rnew...@apache.org wrote:
Here's another suggestion.
In all vote emails, we include the commit id that the release
artifacts were built from, but create no tag at all.
I
On Sat, Oct 22, 2011 at 4:31 AM, Jason Smith j...@iriscouch.com wrote:
That sounds like a tag by another name. I hope that official ASF
releases could have corresponding persistent, unchanging Git tags; and
also that moments of significance (release votes) would be reflected
in the
I am torn now.
If being able to tell from Git at what point a release branch was cut for a
vote (even if that vote failed) is important then I suggest we go with my
vote/ and release/ prefix idea, and that a release branch is tagged once
for the vote, and then a second time when it passes. Does
On Sat, Oct 22, 2011 at 5:08 AM, Noah Slater nsla...@tumbolia.org wrote:
I'm sorry, but I m
This was actually my client messing things up, but I think I prefer it like
this, so I won't correct it.
On Fri, Oct 21, 2011 at 20:31, Jason Smith j...@iriscouch.com wrote:
On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater nsla...@tumbolia.org wrote:
On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson rnew...@apache.org
wrote:
Here's another suggestion.
In all vote emails, we include the commit
On Fri, Oct 21, 2011 at 21:34, Randall Leeds randall.le...@gmail.comwrote:
On Fri, Oct 21, 2011 at 20:31, Jason Smith j...@iriscouch.com wrote:
On Sat, Oct 22, 2011 at 5:06 AM, Noah Slater nsla...@tumbolia.org
wrote:
On Fri, Oct 21, 2011 at 10:23 PM, Robert Newson rnew...@apache.org
wrote:
On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater nsla...@tumbolia.org wrote:
I am torn now.
If being able to tell from Git at what point a release branch was cut for a
vote (even if that vote failed) is important then I suggest we go with my
vote/ and release/ prefix idea, and that a release
On Fri, Oct 21, 2011 at 21:38, Jason Smith j...@iriscouch.com wrote:
On Sat, Oct 22, 2011 at 10:56 AM, Noah Slater nsla...@tumbolia.org
wrote:
I am torn now.
If being able to tell from Git at what point a release branch was cut for
a
vote (even if that vote failed) is important then I
On Oct 21, 2011, at 9:08 PM, Noah Slater wrote:
Because 1.1 might have features in it that 1.2 does not. Or 1.1 might have a
security problem that 1.2 does not. As Adam points out, there are many small
changes to files such as CHANGES or acinclude.in that are never
forward-ported. This kind
85 matches
Mail list logo
