On Jun 17, 2012, at 20:48 , Paul Davis wrote:
The only thing I see an issue with is the merge commit policy.
You'll find quite quickly that you'll have situations that require
merge commits with diff's to work properly. A traditional example is
bug fixes that reach back through many
bump.
On Mon, Jun 18, 2012 at 10:29 AM, Benoit Chesneau bchesn...@gmail.com wrote:
On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater nsla...@tumbolia.org wrote:
Devs,
A few of us met in Dublin recently, and we discussed the project roadmap.
Key takeaways from that meeting:
1. We'd like to
On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater nsla...@tumbolia.org wrote:
Devs,
A few of us met in Dublin recently, and we discussed the project roadmap.
Key takeaways from that meeting:
1. We'd like to proposed formal time-based releases
2. Branch and hack all you like, but if you want
Heya,
I'm in favour of the proposal. I recognise that there are a few things
that need to be refined, but I think what we have is good enough to get
going and refine as we go along.
With QA for example, it is up to the release master to judge whether a
release is good to go. If the community QA
On Jun 16, 2012, at 18:45 , Noah Slater wrote:
Devs,
A few of us met in Dublin recently, and we discussed the project roadmap.
Key takeaways from that meeting:
1. We'd like to proposed formal time-based releases
2. Branch and hack all you like, but if you want to ship something,
Thanks for the comments guys.
Bob was in the room when this proposal was drafted (literally) but Paul is
our other active release manager, so I want to wait for his review before I
comment on anything in the thread. I am also interested to hear what Jason
Smith thinks, and indeed, anyone else
The only thing I see an issue with is the merge commit policy.
You'll find quite quickly that you'll have situations that require
merge commits with diff's to work properly. A traditional example is
bug fixes that reach back through many release branches. If the RM
rejects anything that's not a
Devs,
A few of us met in Dublin recently, and we discussed the project roadmap.
Key takeaways from that meeting:
1. We'd like to proposed formal time-based releases
2. Branch and hack all you like, but if you want to ship something, you
have to submit a merge request to an active release
On Sat, Jun 16, 2012 at 6:45 PM, Noah Slater nsla...@tumbolia.org wrote:
1. We'd like to proposed formal time-based releases
Love it. In fact, I think I proposed it before. I think this will be a
much better way of making CouchDB administration easy.
Details of these proposals can be found
This is an excellent idea, more predictability is always a Good Thing,
regardless of how big each release is. Being able to schedule downtime for
upgrades on a predictable schedule is a massive tick.
Martin
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Saturday, 16 June 2012 at
On 16 June 2012 17:45, Noah Slater nsla...@tumbolia.org wrote:
1. We'd like to proposed formal time-based releases
http://wiki.apache.org/couchdb/Roadmap_Process
This is a big improvement, but... :)
If the QA is good enough, it would be a little better to have feature
releases every month
11 matches
Mail list logo
