You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2016/05/26 07:42:59 UTC
2.0 Code Freeze or branching 2.1?
Hey all,
last night on IRC Bob brought up a good point: we have ongoing
development going into our repos while we are trying to get 2.0 out the
door. It might be time to split these two.
Bob suggested a code freeze until we ship a first 2.0 beta. An
alternative would be to branch out 2.x.x and stabilise that, port any
fixes to master, where regular development can occur there.
Both alternatives have their pros and cons, but I like the aspect of a
code freeze that forces everyone to help get the release build stable.
That said, I fear that most folks would then just commit to their
personal or other corporate repos (hello Cloudant) and only sync to ASF
repos when the freeze is over, and not help out with the build.
E.g. I don’t want to force anyone into anything they don’t want to do
with an arbitrary policy, but I’d be in support of a code freeze if
people here would signal that it’d help them focus on a stable build
as opposed to new feature development.
What do you think?
Best
Jan
--
Re: 2.0 Code Freeze or branching 2.1?
Posted by Robert Newson <rn...@apache.org>.
For 2991, removing the ability to rename that db gets my +1. It, like _replicator, should be the same everywhere. It's only configurable so the test suite can use different (random) ones for each test.
Sent from my iPhone
> On 26 May 2016, at 21:44, Paul Davis <pa...@gmail.com> wrote:
>
> Derp! Thanks for the heads up. I'll try and take a crack at some of
> those issues tomorrow and next week. Monday is a holiday so I probably
> wont be around then.
>
>> On Thu, May 26, 2016 at 4:01 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> https://issues.apache.org/jira/browse/COUCHDB-2632?jql=project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC — via http://s.apache.org/couchdb-2.0 (from #couchdb-dev on IRC).
>>
>>
>> I’ve started work on https://issues.apache.org/jira/browse/COUCHDB-2991 and Sebastian Rothbucher continued it a little further (links in the ticket). Since its security related, I don’t want to punt this as “known issues”. Sorry it involves the JS tests, but they do encode that part of the behaviour pretty well and Cloudant tests don’t seem to cover this, as this came in post-BigCouch-merge.
>>
>> I’m off this Friday and weekend, but might be able to reply to mails. Otherwise I’m back on Monday and will try and help get this over the hump.
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>> On 26 May 2016, at 22:23, Paul Davis <pa...@gmail.com> wrote:
>>>
>>> Can someone remind me where the list of 2.0 blockers is?
>>>
>>>> On Thu, May 26, 2016 at 3:17 PM, Joan Touzet <wo...@apache.org> wrote:
>>>> Also +1, except for the work to get the Windows port running correctly.
>>>>
>>>> -Joan
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michelle Phung" <mi...@gmail.com>
>>>>> To: dev@couchdb.apache.org
>>>>> Sent: Thursday, May 26, 2016 7:23:46 AM
>>>>> Subject: Re: 2.0 Code Freeze or branching 2.1?
>>>>>
>>>>> +1
>>>>>
>>>>> - Michelle
>>>>>
>>>>>> On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I think that's better call feature/improvements freeze, since we
>>>>>> still
>>>>>> have to commit the code that includes bugfixes.
>>>>>>
>>>>>> +1
>>>>>> --
>>>>>> ,,,^..^,,,
>>>>>>
>>>>>>
>>>>>>> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
>>>>>>> <rn...@apache.org> wrote:
>>>>>>> +1 for code freeze.
>>>>>>>
>>>>>>> The only changes we will merge to master branches must contribute
>>>>>>> toward 2.0 actually shipping.
>>>>>>>
>>>>>>> I would also not make 2.x.x branches until 2.0 is GA. the first
>>>>>>> commit on all those branches should be the release itself.
>>>>>>> Subsequent commits are backported fixes from master only.
>>>>>>>
>>>>>>> Lets explicitly say that we'll take no work for future
>>>>>>> enhancements or fixes until 2.0 ships. We must get this out.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> in my opinion, everybody is interested to add new features on a
>>>>>>>> stable version of CouchDB. So with a code freeze, everybody is
>>>>>>>> asked to help get 2.0 shipped because then, new features can be
>>>>>>>> added with more focus and on a stable release.
>>>>>>>>
>>>>>>>> For me, this sounds better than branching even though, that some
>>>>>>>> people will work on their own repos.
>>>>>>>>
>>>>>>>> +1 for code freeze
>>>>>>>>
>>>>>>>> Side note: as I am not actively developing, my opinion should be
>>>>>>>> taken with low prio because there might be reasons from others
>>>>>>>> to prefer branching.
>>>>>>>>
>>>>>>>> Thanks to everyone making CouchDB 2.0 great!
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>> --
>>>>>>>> Andy Wenk
>>>>>>>> RockIt!
>>>>>>>>
>>>>>>>> Hamburg / Germany
>>>>>>>>
>>>>>>>> GPG public key:
>>>>>>>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>>>>>>>>
>>>>>>>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Hey all,
>>>>>>>>>
>>>>>>>>> last night on IRC Bob brought up a good point: we have ongoing
>>>>>>>>> development going into our repos while we are trying to get 2.0
>>>>>>>>> out the
>>>>>>>>> door. It might be time to split these two.
>>>>>>>>>
>>>>>>>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>>>>>>>>> alternative would be to branch out 2.x.x and stabilise that,
>>>>>>>>> port any
>>>>>>>>> fixes to master, where regular development can occur there.
>>>>>>>>>
>>>>>>>>> Both alternatives have their pros and cons, but I like the
>>>>>>>>> aspect of a
>>>>>>>>> code freeze that forces everyone to help get the release build
>>>>>>>>> stable.
>>>>>>>>>
>>>>>>>>> That said, I fear that most folks would then just commit to
>>>>>>>>> their
>>>>>>>>> personal or other corporate repos (hello Cloudant) and only sync
>>>>>>>>> to ASF
>>>>>>>>> repos when the freeze is over, and not help out with the build.
>>>>>>>>>
>>>>>>>>> E.g. I don’t want to force anyone into anything they don’t want
>>>>>>>>> to do
>>>>>>>>> with an arbitrary policy, but I’d be in support of a code freeze
>>>>>>>>> if
>>>>>>>>> people here would signal that it’d help them focus on a stable
>>>>>>>>> build
>>>>>>>>> as opposed to new feature development.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Best
>>>>>>>>> Jan
>>>>>>>>> --
>>
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Paul Davis <pa...@gmail.com>.
Derp! Thanks for the heads up. I'll try and take a crack at some of
those issues tomorrow and next week. Monday is a holiday so I probably
wont be around then.
On Thu, May 26, 2016 at 4:01 PM, Jan Lehnardt <ja...@apache.org> wrote:
> https://issues.apache.org/jira/browse/COUCHDB-2632?jql=project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC — via http://s.apache.org/couchdb-2.0 (from #couchdb-dev on IRC).
>
>
> I’ve started work on https://issues.apache.org/jira/browse/COUCHDB-2991 and Sebastian Rothbucher continued it a little further (links in the ticket). Since its security related, I don’t want to punt this as “known issues”. Sorry it involves the JS tests, but they do encode that part of the behaviour pretty well and Cloudant tests don’t seem to cover this, as this came in post-BigCouch-merge.
>
> I’m off this Friday and weekend, but might be able to reply to mails. Otherwise I’m back on Monday and will try and help get this over the hump.
>
> Best
> Jan
> --
>
>
>
>> On 26 May 2016, at 22:23, Paul Davis <pa...@gmail.com> wrote:
>>
>> Can someone remind me where the list of 2.0 blockers is?
>>
>> On Thu, May 26, 2016 at 3:17 PM, Joan Touzet <wo...@apache.org> wrote:
>>> Also +1, except for the work to get the Windows port running correctly.
>>>
>>> -Joan
>>>
>>> ----- Original Message -----
>>>> From: "Michelle Phung" <mi...@gmail.com>
>>>> To: dev@couchdb.apache.org
>>>> Sent: Thursday, May 26, 2016 7:23:46 AM
>>>> Subject: Re: 2.0 Code Freeze or branching 2.1?
>>>>
>>>> +1
>>>>
>>>> - Michelle
>>>>
>>>>> On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I think that's better call feature/improvements freeze, since we
>>>>> still
>>>>> have to commit the code that includes bugfixes.
>>>>>
>>>>> +1
>>>>> --
>>>>> ,,,^..^,,,
>>>>>
>>>>>
>>>>>> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
>>>>>> <rn...@apache.org> wrote:
>>>>>> +1 for code freeze.
>>>>>>
>>>>>> The only changes we will merge to master branches must contribute
>>>>>> toward 2.0 actually shipping.
>>>>>>
>>>>>> I would also not make 2.x.x branches until 2.0 is GA. the first
>>>>>> commit on all those branches should be the release itself.
>>>>>> Subsequent commits are backported fixes from master only.
>>>>>>
>>>>>> Lets explicitly say that we'll take no work for future
>>>>>> enhancements or fixes until 2.0 ships. We must get this out.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> in my opinion, everybody is interested to add new features on a
>>>>>>> stable version of CouchDB. So with a code freeze, everybody is
>>>>>>> asked to help get 2.0 shipped because then, new features can be
>>>>>>> added with more focus and on a stable release.
>>>>>>>
>>>>>>> For me, this sounds better than branching even though, that some
>>>>>>> people will work on their own repos.
>>>>>>>
>>>>>>> +1 for code freeze
>>>>>>>
>>>>>>> Side note: as I am not actively developing, my opinion should be
>>>>>>> taken with low prio because there might be reasons from others
>>>>>>> to prefer branching.
>>>>>>>
>>>>>>> Thanks to everyone making CouchDB 2.0 great!
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>> --
>>>>>>> Andy Wenk
>>>>>>> RockIt!
>>>>>>>
>>>>>>> Hamburg / Germany
>>>>>>>
>>>>>>> GPG public key:
>>>>>>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>>>>>>>
>>>>>>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>>
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> last night on IRC Bob brought up a good point: we have ongoing
>>>>>>>> development going into our repos while we are trying to get 2.0
>>>>>>>> out the
>>>>>>>> door. It might be time to split these two.
>>>>>>>>
>>>>>>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>>>>>>>> alternative would be to branch out 2.x.x and stabilise that,
>>>>>>>> port any
>>>>>>>> fixes to master, where regular development can occur there.
>>>>>>>>
>>>>>>>> Both alternatives have their pros and cons, but I like the
>>>>>>>> aspect of a
>>>>>>>> code freeze that forces everyone to help get the release build
>>>>>>>> stable.
>>>>>>>>
>>>>>>>> That said, I fear that most folks would then just commit to
>>>>>>>> their
>>>>>>>> personal or other corporate repos (hello Cloudant) and only sync
>>>>>>>> to ASF
>>>>>>>> repos when the freeze is over, and not help out with the build.
>>>>>>>>
>>>>>>>> E.g. I don’t want to force anyone into anything they don’t want
>>>>>>>> to do
>>>>>>>> with an arbitrary policy, but I’d be in support of a code freeze
>>>>>>>> if
>>>>>>>> people here would signal that it’d help them focus on a stable
>>>>>>>> build
>>>>>>>> as opposed to new feature development.
>>>>>>>>
>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Jan
>>>>>>>> --
>>>>>>
>>>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Jan Lehnardt <ja...@apache.org>.
https://issues.apache.org/jira/browse/COUCHDB-2632?jql=project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC — via http://s.apache.org/couchdb-2.0 (from #couchdb-dev on IRC).
I’ve started work on https://issues.apache.org/jira/browse/COUCHDB-2991 and Sebastian Rothbucher continued it a little further (links in the ticket). Since its security related, I don’t want to punt this as “known issues”. Sorry it involves the JS tests, but they do encode that part of the behaviour pretty well and Cloudant tests don’t seem to cover this, as this came in post-BigCouch-merge.
I’m off this Friday and weekend, but might be able to reply to mails. Otherwise I’m back on Monday and will try and help get this over the hump.
Best
Jan
--
> On 26 May 2016, at 22:23, Paul Davis <pa...@gmail.com> wrote:
>
> Can someone remind me where the list of 2.0 blockers is?
>
> On Thu, May 26, 2016 at 3:17 PM, Joan Touzet <wo...@apache.org> wrote:
>> Also +1, except for the work to get the Windows port running correctly.
>>
>> -Joan
>>
>> ----- Original Message -----
>>> From: "Michelle Phung" <mi...@gmail.com>
>>> To: dev@couchdb.apache.org
>>> Sent: Thursday, May 26, 2016 7:23:46 AM
>>> Subject: Re: 2.0 Code Freeze or branching 2.1?
>>>
>>> +1
>>>
>>> - Michelle
>>>
>>>> On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com>
>>>> wrote:
>>>>
>>>> I think that's better call feature/improvements freeze, since we
>>>> still
>>>> have to commit the code that includes bugfixes.
>>>>
>>>> +1
>>>> --
>>>> ,,,^..^,,,
>>>>
>>>>
>>>>> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
>>>>> <rn...@apache.org> wrote:
>>>>> +1 for code freeze.
>>>>>
>>>>> The only changes we will merge to master branches must contribute
>>>>> toward 2.0 actually shipping.
>>>>>
>>>>> I would also not make 2.x.x branches until 2.0 is GA. the first
>>>>> commit on all those branches should be the release itself.
>>>>> Subsequent commits are backported fixes from master only.
>>>>>
>>>>> Lets explicitly say that we'll take no work for future
>>>>> enhancements or fixes until 2.0 ships. We must get this out.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> in my opinion, everybody is interested to add new features on a
>>>>>> stable version of CouchDB. So with a code freeze, everybody is
>>>>>> asked to help get 2.0 shipped because then, new features can be
>>>>>> added with more focus and on a stable release.
>>>>>>
>>>>>> For me, this sounds better than branching even though, that some
>>>>>> people will work on their own repos.
>>>>>>
>>>>>> +1 for code freeze
>>>>>>
>>>>>> Side note: as I am not actively developing, my opinion should be
>>>>>> taken with low prio because there might be reasons from others
>>>>>> to prefer branching.
>>>>>>
>>>>>> Thanks to everyone making CouchDB 2.0 great!
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>> --
>>>>>> Andy Wenk
>>>>>> RockIt!
>>>>>>
>>>>>> Hamburg / Germany
>>>>>>
>>>>>> GPG public key:
>>>>>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>>>>>>
>>>>>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> last night on IRC Bob brought up a good point: we have ongoing
>>>>>>> development going into our repos while we are trying to get 2.0
>>>>>>> out the
>>>>>>> door. It might be time to split these two.
>>>>>>>
>>>>>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>>>>>>> alternative would be to branch out 2.x.x and stabilise that,
>>>>>>> port any
>>>>>>> fixes to master, where regular development can occur there.
>>>>>>>
>>>>>>> Both alternatives have their pros and cons, but I like the
>>>>>>> aspect of a
>>>>>>> code freeze that forces everyone to help get the release build
>>>>>>> stable.
>>>>>>>
>>>>>>> That said, I fear that most folks would then just commit to
>>>>>>> their
>>>>>>> personal or other corporate repos (hello Cloudant) and only sync
>>>>>>> to ASF
>>>>>>> repos when the freeze is over, and not help out with the build.
>>>>>>>
>>>>>>> E.g. I don’t want to force anyone into anything they don’t want
>>>>>>> to do
>>>>>>> with an arbitrary policy, but I’d be in support of a code freeze
>>>>>>> if
>>>>>>> people here would signal that it’d help them focus on a stable
>>>>>>> build
>>>>>>> as opposed to new feature development.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Best
>>>>>>> Jan
>>>>>>> --
>>>>>
>>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: 2.0 Code Freeze or branching 2.1?
Posted by Paul Davis <pa...@gmail.com>.
Can someone remind me where the list of 2.0 blockers is?
On Thu, May 26, 2016 at 3:17 PM, Joan Touzet <wo...@apache.org> wrote:
> Also +1, except for the work to get the Windows port running correctly.
>
> -Joan
>
> ----- Original Message -----
>> From: "Michelle Phung" <mi...@gmail.com>
>> To: dev@couchdb.apache.org
>> Sent: Thursday, May 26, 2016 7:23:46 AM
>> Subject: Re: 2.0 Code Freeze or branching 2.1?
>>
>> +1
>>
>> - Michelle
>>
>> > On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com>
>> > wrote:
>> >
>> > I think that's better call feature/improvements freeze, since we
>> > still
>> > have to commit the code that includes bugfixes.
>> >
>> > +1
>> > --
>> > ,,,^..^,,,
>> >
>> >
>> >> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
>> >> <rn...@apache.org> wrote:
>> >> +1 for code freeze.
>> >>
>> >> The only changes we will merge to master branches must contribute
>> >> toward 2.0 actually shipping.
>> >>
>> >> I would also not make 2.x.x branches until 2.0 is GA. the first
>> >> commit on all those branches should be the release itself.
>> >> Subsequent commits are backported fixes from master only.
>> >>
>> >> Lets explicitly say that we'll take no work for future
>> >> enhancements or fixes until 2.0 ships. We must get this out.
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> in my opinion, everybody is interested to add new features on a
>> >>> stable version of CouchDB. So with a code freeze, everybody is
>> >>> asked to help get 2.0 shipped because then, new features can be
>> >>> added with more focus and on a stable release.
>> >>>
>> >>> For me, this sounds better than branching even though, that some
>> >>> people will work on their own repos.
>> >>>
>> >>> +1 for code freeze
>> >>>
>> >>> Side note: as I am not actively developing, my opinion should be
>> >>> taken with low prio because there might be reasons from others
>> >>> to prefer branching.
>> >>>
>> >>> Thanks to everyone making CouchDB 2.0 great!
>> >>>
>> >>> Andy
>> >>>
>> >>> --
>> >>> Andy Wenk
>> >>> RockIt!
>> >>>
>> >>> Hamburg / Germany
>> >>>
>> >>> GPG public key:
>> >>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>> >>>
>> >>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>> >>>>
>> >>>> Hey all,
>> >>>>
>> >>>> last night on IRC Bob brought up a good point: we have ongoing
>> >>>> development going into our repos while we are trying to get 2.0
>> >>>> out the
>> >>>> door. It might be time to split these two.
>> >>>>
>> >>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>> >>>> alternative would be to branch out 2.x.x and stabilise that,
>> >>>> port any
>> >>>> fixes to master, where regular development can occur there.
>> >>>>
>> >>>> Both alternatives have their pros and cons, but I like the
>> >>>> aspect of a
>> >>>> code freeze that forces everyone to help get the release build
>> >>>> stable.
>> >>>>
>> >>>> That said, I fear that most folks would then just commit to
>> >>>> their
>> >>>> personal or other corporate repos (hello Cloudant) and only sync
>> >>>> to ASF
>> >>>> repos when the freeze is over, and not help out with the build.
>> >>>>
>> >>>> E.g. I don’t want to force anyone into anything they don’t want
>> >>>> to do
>> >>>> with an arbitrary policy, but I’d be in support of a code freeze
>> >>>> if
>> >>>> people here would signal that it’d help them focus on a stable
>> >>>> build
>> >>>> as opposed to new feature development.
>> >>>>
>> >>>> What do you think?
>> >>>>
>> >>>> Best
>> >>>> Jan
>> >>>> --
>> >>
>>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Joan Touzet <wo...@apache.org>.
Also +1, except for the work to get the Windows port running correctly.
-Joan
----- Original Message -----
> From: "Michelle Phung" <mi...@gmail.com>
> To: dev@couchdb.apache.org
> Sent: Thursday, May 26, 2016 7:23:46 AM
> Subject: Re: 2.0 Code Freeze or branching 2.1?
>
> +1
>
> - Michelle
>
> > On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com>
> > wrote:
> >
> > I think that's better call feature/improvements freeze, since we
> > still
> > have to commit the code that includes bugfixes.
> >
> > +1
> > --
> > ,,,^..^,,,
> >
> >
> >> On Thu, May 26, 2016 at 12:56 PM, Robert Newson
> >> <rn...@apache.org> wrote:
> >> +1 for code freeze.
> >>
> >> The only changes we will merge to master branches must contribute
> >> toward 2.0 actually shipping.
> >>
> >> I would also not make 2.x.x branches until 2.0 is GA. the first
> >> commit on all those branches should be the release itself.
> >> Subsequent commits are backported fixes from master only.
> >>
> >> Lets explicitly say that we'll take no work for future
> >> enhancements or fixes until 2.0 ships. We must get this out.
> >>
> >> Sent from my iPhone
> >>
> >>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> in my opinion, everybody is interested to add new features on a
> >>> stable version of CouchDB. So with a code freeze, everybody is
> >>> asked to help get 2.0 shipped because then, new features can be
> >>> added with more focus and on a stable release.
> >>>
> >>> For me, this sounds better than branching even though, that some
> >>> people will work on their own repos.
> >>>
> >>> +1 for code freeze
> >>>
> >>> Side note: as I am not actively developing, my opinion should be
> >>> taken with low prio because there might be reasons from others
> >>> to prefer branching.
> >>>
> >>> Thanks to everyone making CouchDB 2.0 great!
> >>>
> >>> Andy
> >>>
> >>> --
> >>> Andy Wenk
> >>> RockIt!
> >>>
> >>> Hamburg / Germany
> >>>
> >>> GPG public key:
> >>> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
> >>>
> >>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
> >>>>
> >>>> Hey all,
> >>>>
> >>>> last night on IRC Bob brought up a good point: we have ongoing
> >>>> development going into our repos while we are trying to get 2.0
> >>>> out the
> >>>> door. It might be time to split these two.
> >>>>
> >>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
> >>>> alternative would be to branch out 2.x.x and stabilise that,
> >>>> port any
> >>>> fixes to master, where regular development can occur there.
> >>>>
> >>>> Both alternatives have their pros and cons, but I like the
> >>>> aspect of a
> >>>> code freeze that forces everyone to help get the release build
> >>>> stable.
> >>>>
> >>>> That said, I fear that most folks would then just commit to
> >>>> their
> >>>> personal or other corporate repos (hello Cloudant) and only sync
> >>>> to ASF
> >>>> repos when the freeze is over, and not help out with the build.
> >>>>
> >>>> E.g. I don’t want to force anyone into anything they don’t want
> >>>> to do
> >>>> with an arbitrary policy, but I’d be in support of a code freeze
> >>>> if
> >>>> people here would signal that it’d help them focus on a stable
> >>>> build
> >>>> as opposed to new feature development.
> >>>>
> >>>> What do you think?
> >>>>
> >>>> Best
> >>>> Jan
> >>>> --
> >>
>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Michelle Phung <mi...@gmail.com>.
+1
- Michelle
> On May 26, 2016, at 6:34 AM, Alexander Shorin <kx...@gmail.com> wrote:
>
> I think that's better call feature/improvements freeze, since we still
> have to commit the code that includes bugfixes.
>
> +1
> --
> ,,,^..^,,,
>
>
>> On Thu, May 26, 2016 at 12:56 PM, Robert Newson <rn...@apache.org> wrote:
>> +1 for code freeze.
>>
>> The only changes we will merge to master branches must contribute toward 2.0 actually shipping.
>>
>> I would also not make 2.x.x branches until 2.0 is GA. the first commit on all those branches should be the release itself. Subsequent commits are backported fixes from master only.
>>
>> Lets explicitly say that we'll take no work for future enhancements or fixes until 2.0 ships. We must get this out.
>>
>> Sent from my iPhone
>>
>>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> in my opinion, everybody is interested to add new features on a stable version of CouchDB. So with a code freeze, everybody is asked to help get 2.0 shipped because then, new features can be added with more focus and on a stable release.
>>>
>>> For me, this sounds better than branching even though, that some people will work on their own repos.
>>>
>>> +1 for code freeze
>>>
>>> Side note: as I am not actively developing, my opinion should be taken with low prio because there might be reasons from others to prefer branching.
>>>
>>> Thanks to everyone making CouchDB 2.0 great!
>>>
>>> Andy
>>>
>>> --
>>> Andy Wenk
>>> RockIt!
>>>
>>> Hamburg / Germany
>>>
>>> GPG public key: https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>>>
>>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>>>
>>>> Hey all,
>>>>
>>>> last night on IRC Bob brought up a good point: we have ongoing
>>>> development going into our repos while we are trying to get 2.0 out the
>>>> door. It might be time to split these two.
>>>>
>>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>>>> alternative would be to branch out 2.x.x and stabilise that, port any
>>>> fixes to master, where regular development can occur there.
>>>>
>>>> Both alternatives have their pros and cons, but I like the aspect of a
>>>> code freeze that forces everyone to help get the release build stable.
>>>>
>>>> That said, I fear that most folks would then just commit to their
>>>> personal or other corporate repos (hello Cloudant) and only sync to ASF
>>>> repos when the freeze is over, and not help out with the build.
>>>>
>>>> E.g. I don’t want to force anyone into anything they don’t want to do
>>>> with an arbitrary policy, but I’d be in support of a code freeze if
>>>> people here would signal that it’d help them focus on a stable build
>>>> as opposed to new feature development.
>>>>
>>>> What do you think?
>>>>
>>>> Best
>>>> Jan
>>>> --
>>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Alexander Shorin <kx...@gmail.com>.
I think that's better call feature/improvements freeze, since we still
have to commit the code that includes bugfixes.
+1
--
,,,^..^,,,
On Thu, May 26, 2016 at 12:56 PM, Robert Newson <rn...@apache.org> wrote:
> +1 for code freeze.
>
> The only changes we will merge to master branches must contribute toward 2.0 actually shipping.
>
> I would also not make 2.x.x branches until 2.0 is GA. the first commit on all those branches should be the release itself. Subsequent commits are backported fixes from master only.
>
> Lets explicitly say that we'll take no work for future enhancements or fixes until 2.0 ships. We must get this out.
>
> Sent from my iPhone
>
>> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>>
>> Hi,
>>
>> in my opinion, everybody is interested to add new features on a stable version of CouchDB. So with a code freeze, everybody is asked to help get 2.0 shipped because then, new features can be added with more focus and on a stable release.
>>
>> For me, this sounds better than branching even though, that some people will work on their own repos.
>>
>> +1 for code freeze
>>
>> Side note: as I am not actively developing, my opinion should be taken with low prio because there might be reasons from others to prefer branching.
>>
>> Thanks to everyone making CouchDB 2.0 great!
>>
>> Andy
>>
>> --
>> Andy Wenk
>> RockIt!
>>
>> Hamburg / Germany
>>
>> GPG public key: https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>>
>>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>> Hey all,
>>>
>>> last night on IRC Bob brought up a good point: we have ongoing
>>> development going into our repos while we are trying to get 2.0 out the
>>> door. It might be time to split these two.
>>>
>>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>>> alternative would be to branch out 2.x.x and stabilise that, port any
>>> fixes to master, where regular development can occur there.
>>>
>>> Both alternatives have their pros and cons, but I like the aspect of a
>>> code freeze that forces everyone to help get the release build stable.
>>>
>>> That said, I fear that most folks would then just commit to their
>>> personal or other corporate repos (hello Cloudant) and only sync to ASF
>>> repos when the freeze is over, and not help out with the build.
>>>
>>> E.g. I don’t want to force anyone into anything they don’t want to do
>>> with an arbitrary policy, but I’d be in support of a code freeze if
>>> people here would signal that it’d help them focus on a stable build
>>> as opposed to new feature development.
>>>
>>> What do you think?
>>>
>>> Best
>>> Jan
>>> --
>>
>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Robert Newson <rn...@apache.org>.
+1 for code freeze.
The only changes we will merge to master branches must contribute toward 2.0 actually shipping.
I would also not make 2.x.x branches until 2.0 is GA. the first commit on all those branches should be the release itself. Subsequent commits are backported fixes from master only.
Lets explicitly say that we'll take no work for future enhancements or fixes until 2.0 ships. We must get this out.
Sent from my iPhone
> On 26 May 2016, at 09:10, Andy Wenk <an...@apache.org> wrote:
>
> Hi,
>
> in my opinion, everybody is interested to add new features on a stable version of CouchDB. So with a code freeze, everybody is asked to help get 2.0 shipped because then, new features can be added with more focus and on a stable release.
>
> For me, this sounds better than branching even though, that some people will work on their own repos.
>
> +1 for code freeze
>
> Side note: as I am not actively developing, my opinion should be taken with low prio because there might be reasons from others to prefer branching.
>
> Thanks to everyone making CouchDB 2.0 great!
>
> Andy
>
> --
> Andy Wenk
> RockIt!
>
> Hamburg / Germany
>
> GPG public key: https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>
>> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>>
>> Hey all,
>>
>> last night on IRC Bob brought up a good point: we have ongoing
>> development going into our repos while we are trying to get 2.0 out the
>> door. It might be time to split these two.
>>
>> Bob suggested a code freeze until we ship a first 2.0 beta. An
>> alternative would be to branch out 2.x.x and stabilise that, port any
>> fixes to master, where regular development can occur there.
>>
>> Both alternatives have their pros and cons, but I like the aspect of a
>> code freeze that forces everyone to help get the release build stable.
>>
>> That said, I fear that most folks would then just commit to their
>> personal or other corporate repos (hello Cloudant) and only sync to ASF
>> repos when the freeze is over, and not help out with the build.
>>
>> E.g. I don’t want to force anyone into anything they don’t want to do
>> with an arbitrary policy, but I’d be in support of a code freeze if
>> people here would signal that it’d help them focus on a stable build
>> as opposed to new feature development.
>>
>> What do you think?
>>
>> Best
>> Jan
>> --
>
Re: 2.0 Code Freeze or branching 2.1?
Posted by Andy Wenk <an...@apache.org>.
Hi,
in my opinion, everybody is interested to add new features on a stable version of CouchDB. So with a code freeze, everybody is asked to help get 2.0 shipped because then, new features can be added with more focus and on a stable release.
For me, this sounds better than branching even though, that some people will work on their own repos.
+1 for code freeze
Side note: as I am not actively developing, my opinion should be taken with low prio because there might be reasons from others to prefer branching.
Thanks to everyone making CouchDB 2.0 great!
Andy
--
Andy Wenk
RockIt!
Hamburg / Germany
GPG public key: https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
> On 26 May 2016, at 09:42, Jan Lehnardt <ja...@apache.org> wrote:
>
> Hey all,
>
> last night on IRC Bob brought up a good point: we have ongoing
> development going into our repos while we are trying to get 2.0 out the
> door. It might be time to split these two.
>
> Bob suggested a code freeze until we ship a first 2.0 beta. An
> alternative would be to branch out 2.x.x and stabilise that, port any
> fixes to master, where regular development can occur there.
>
> Both alternatives have their pros and cons, but I like the aspect of a
> code freeze that forces everyone to help get the release build stable.
>
> That said, I fear that most folks would then just commit to their
> personal or other corporate repos (hello Cloudant) and only sync to ASF
> repos when the freeze is over, and not help out with the build.
>
> E.g. I don’t want to force anyone into anything they don’t want to do
> with an arbitrary policy, but I’d be in support of a code freeze if
> people here would signal that it’d help them focus on a stable build
> as opposed to new feature development.
>
> What do you think?
>
> Best
> Jan
> --
>