Code Freeze

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Code Freeze

Rik-4
12/20/18

jwe,

I know you are going to have limited availability starting on the 21st.  I
propose that before you go on holiday we stop new feature coding for the
5.0 release, and move solely to bug fixing.  The only concrete action for
that being your merge of the default branch on to the stable branch.  The
new bug reports have already been trending this direction with several
about the build system and the test suite.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

John W. Eaton
Administrator
On 12/20/18 11:45 AM, Rik wrote:

> I know you are going to have limited availability starting on the 21st.  I
> propose that before you go on holiday we stop new feature coding for the
> 5.0 release, and move solely to bug fixing.  The only concrete action for
> that being your merge of the default branch on to the stable branch.  The
> new bug reports have already been trending this direction with several
> about the build system and the test suite.

I'm fine with doing the merge of default to stable whenever you think it
is time.  If you are ready now, I can do it today.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Rik-4
On 12/20/2018 09:58 AM, John W. Eaton wrote:

> On 12/20/18 11:45 AM, Rik wrote:
>
>> I know you are going to have limited availability starting on the 21st.  I
>> propose that before you go on holiday we stop new feature coding for the
>> 5.0 release, and move solely to bug fixing.  The only concrete action for
>> that being your merge of the default branch on to the stable branch.  The
>> new bug reports have already been trending this direction with several
>> about the build system and the test suite.
>
> I'm fine with doing the merge of default to stable whenever you think it
> is time.  If you are ready now, I can do it today.

Yes, let's get on with it.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

nrjank
> > I'm fine with doing the merge of default to stable whenever you think it
> > is time.  If you are ready now, I can do it today.
>
> Yes, let's get on with it.
>
> --Rik
>

It may be late but I'll toss this out there:  Are there any GSoC
projects that are at the state where they could be considered for
inclusion in 5.0 if they haven't been rolled in already?

Assuming it's a bit late to insert that question, perhaps it would be
worth adding that review as part of any regular release process to
minimize those that could sit and go stale.

nick j.

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Doug Stewart-4


On Thu, Dec 20, 2018 at 2:13 PM Nicholas Jankowski <[hidden email]> wrote:
> > I'm fine with doing the merge of default to stable whenever you think it
> > is time.  If you are ready now, I can do it today.
>
> Yes, let's get on with it.
>
> --Rik
>

It may be late but I'll toss this out there:  Are there any GSoC
projects that are at the state where they could be considered for
inclusion in 5.0 if they haven't been rolled in already?

Assuming it's a bit late to insert that question, perhaps it would be
worth adding that review as part of any regular release process to
minimize those that could sit and go stale.

nick j.


How about the  
Pandey SudeepamCommand line suggestion

I think it is stable and not too intrusive.



--
DASCertificate for 206392

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Rik-4
In reply to this post by nrjank
On 12/20/2018 10:53 AM, Nicholas Jankowski wrote:

>>> I'm fine with doing the merge of default to stable whenever you think it
>>> is time.  If you are ready now, I can do it today.
>> Yes, let's get on with it.
>>
>> --Rik
>>
> It may be late but I'll toss this out there:  Are there any GSoC
> projects that are at the state where they could be considered for
> inclusion in 5.0 if they haven't been rolled in already?
>
> Assuming it's a bit late to insert that question, perhaps it would be
> worth adding that review as part of any regular release process to
> minimize those that could sit and go stale.

Reviewing open patches is on the list.  See item 3 at
https://wiki.octave.org/5.0.0_Release_Checklist.

There is no specific callout for GSoC projects, but if there is patch
report filed then they will get reviewed.

--Rik


>
> nick j.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

John W. Eaton
Administrator
In reply to this post by Rik-4
On 12/20/18 1:35 PM, Rik wrote:

> On 12/20/2018 09:58 AM, John W. Eaton wrote:
>> On 12/20/18 11:45 AM, Rik wrote:
>>
>>> I know you are going to have limited availability starting on the 21st.  I
>>> propose that before you go on holiday we stop new feature coding for the
>>> 5.0 release, and move solely to bug fixing.  The only concrete action for
>>> that being your merge of the default branch on to the stable branch.  The
>>> new bug reports have already been trending this direction with several
>>> about the build system and the test suite.
>>
>> I'm fine with doing the merge of default to stable whenever you think it
>> is time.  If you are ready now, I can do it today.
>
> Yes, let's get on with it.

OK, I merged default to stable and set the version number there to
5.0.1.  With the new version numbering scheme described in
etc/HACKING.md, this version indicates the stabilization period leading
up to the 5.1.0 release.

It's too late for any big chunks of code to be added to the stable version.

I have also bumped the version on default to 6.0.0 (active development
period leading up to the 6.1.0 release), so this is also the appropriate
time to make major changes on default.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Rik-4
On 12/20/2018 02:47 PM, John W. Eaton wrote:

> On 12/20/18 1:35 PM, Rik wrote:
>> On 12/20/2018 09:58 AM, John W. Eaton wrote:
>>> On 12/20/18 11:45 AM, Rik wrote:
>>>
>>>> I know you are going to have limited availability starting on the
>>>> 21st.  I
>>>> propose that before you go on holiday we stop new feature coding for the
>>>> 5.0 release, and move solely to bug fixing.  The only concrete action for
>>>> that being your merge of the default branch on to the stable branch.  The
>>>> new bug reports have already been trending this direction with several
>>>> about the build system and the test suite.
>>>
>>> I'm fine with doing the merge of default to stable whenever you think it
>>> is time.  If you are ready now, I can do it today.
>>
>> Yes, let's get on with it.
>
> OK, I merged default to stable and set the version number there to
> 5.0.1.  With the new version numbering scheme described in
> etc/HACKING.md, this version indicates the stabilization period leading
> up to the 5.1.0 release.
>
> It's too late for any big chunks of code to be added to the stable version.
>
> I have also bumped the version on default to 6.0.0 (active development
> period leading up to the 6.1.0 release), so this is also the appropriate
> time to make major changes on default.
>
Yay!  Exciting to be moving towards a release.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Rik-4
In reply to this post by John W. Eaton
On 12/20/2018 02:47 PM, John W. Eaton wrote:

> On 12/20/18 1:35 PM, Rik wrote:
>> On 12/20/2018 09:58 AM, John W. Eaton wrote:
>>> On 12/20/18 11:45 AM, Rik wrote:
>>>
>>>> I know you are going to have limited availability starting on the
>>>> 21st.  I
>>>> propose that before you go on holiday we stop new feature coding for the
>>>> 5.0 release, and move solely to bug fixing.  The only concrete action for
>>>> that being your merge of the default branch on to the stable branch.  The
>>>> new bug reports have already been trending this direction with several
>>>> about the build system and the test suite.
>>>
>>> I'm fine with doing the merge of default to stable whenever you think it
>>> is time.  If you are ready now, I can do it today.
>>
>> Yes, let's get on with it.
>
> OK, I merged default to stable and set the version number there to
> 5.0.1.  With the new version numbering scheme described in
> etc/HACKING.md, this version indicates the stabilization period leading
> up to the 5.1.0 release.
>
> It's too late for any big chunks of code to be added to the stable version.
>
> I have also bumped the version on default to 6.0.0 (active development
> period leading up to the 6.1.0 release), so this is also the appropriate
> time to make major changes on default.
>

I took care of the other post-release tasks (item #15 at
https://wiki.octave.org/5.0.0_Release_Checklist#5.0.0_Release_Tasks). 
Specifically, I removed deprecated functions, deprecated graphics
properties, and moved the old NEWS file into etc/ and started a new NEWS file.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

John W. Eaton
Administrator
On 12/21/18 1:37 AM, Rik wrote:

> I took care of the other post-release tasks (item #15 at
> https://wiki.octave.org/5.0.0_Release_Checklist#5.0.0_Release_Tasks).
> Specifically, I removed deprecated functions, deprecated graphics
> properties, and moved the old NEWS file into etc/ and started a new NEWS file.

Thanks.  Are you also looking at removing the C++ functions deprecated
in 4.4?  If not, I would be glad to do it.  I just don't want to
duplicate effort.  I just counted and there are 227(!!) spread across
70(!!) files.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Michael Godfrey
I have been away, but have just checked on a few bugs for fixing in the 5.0 release:
These may already be in some list but...

   Bug #
1. 55029     pause             hangs (at least in Fedora 29)

2. 55072     printf              documentation of printf is pretty useless.
                                       It recursively refers to itself.

3. 55028     print()            segfaults for multiple print commands in a file.
                                       (at least in Fedora 28/29)

I will try to isolate #55028, but it seems to depend on a lot of context.
And, it was fixed several months ago, but (maybe depending on Fedora
version) is broken again now. I can only test on Fedora 29.

Obviously, seg faults are pretty discouraging for users, so there should
be a general rule that all known seg faults should be, if at all possible,
fixed for a release.
Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

Rik-4
In reply to this post by John W. Eaton
On 12/20/2018 10:55 PM, John W. Eaton wrote:

> On 12/21/18 1:37 AM, Rik wrote:
>
>> I took care of the other post-release tasks (item #15 at
>> https://wiki.octave.org/5.0.0_Release_Checklist#5.0.0_Release_Tasks).
>> Specifically, I removed deprecated functions, deprecated graphics
>> properties, and moved the old NEWS file into etc/ and started a new NEWS
>> file.
>
> Thanks.  Are you also looking at removing the C++ functions deprecated in
> 4.4?  If not, I would be glad to do it.  I just don't want to duplicate
> effort.  I just counted and there are 227(!!) spread across 70(!!) files.
>
> jwe
>

Wow, had no idea it was that large.  Please go ahead, I'm working on other
bugs.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Code Freeze

John W. Eaton
Administrator
On 12/21/18 12:26 PM, Rik wrote:
> On 12/20/2018 10:55 PM, John W. Eaton wrote:

>> Thanks.  Are you also looking at removing the C++ functions deprecated in
>> 4.4?  If not, I would be glad to do it.  I just don't want to duplicate
>> effort.  I just counted and there are 227(!!) spread across 70(!!) files.

> Wow, had no idea it was that large.  Please go ahead, I'm working on other
> bugs.

OK.  It may not happen immediately, but I will work on it.

jwe