|
On 12/12/2018 10:17 PM, John W. Eaton
wrote:
On
12/11/18 6:20 PM, Rik wrote:
I want less traumatic too, but everyone is
going to code right up until we
say "pencils down" and do a code freeze. I just don't see us
changing
human nature. Rather than trying to limit the scope to small
bugs (a
subjective criteria), maybe we should just move the code freeze
sooner so
it gives us more time to test and verify things.
Fair enough. Are there any critical blocking bugs? Should be
pick a date to freeze and merge default to stable? My time will
also be very limited between about December 21 and January 2.
I kicked the process off. There is now a 5.0 Release checklist at
https://wiki.octave.org/5.0.0_Release_Checklist.
The first four items are:
- Update gnulib to latest version
- Must occur first as it could resolve existing, or create
new, bug reports
- Completion Date:
- File bug reports for all outstanding bugs known, but not
reported
- Put out a general call for reports on Octave-Maintainers
and Octave-Help list
- Completion Date:
- Review patch tracker/bug list for any patches submitted that
may be included before release
- Completion Date:
- Identify Bugs which *must* be fixed prior to release
- Review bugs on tracker for possible inclusion in list
- Review bugs and update to correct category, such as Patch
submitted
- Completion Date:
I always forget how to update gnulib so if you could take care of
that it would be great.
We're currently on items 2 and 3. We still need to decide on a
final date for accepting new code. After that date, we start item
#4 which is triaging the bugs to figure out which ones we need to
fix. It's at that point where we would uncover any blockers.
I have promised Juan that I would work on bringing the movfun code
into core Octave this weekend. There is also a bug regarding bias
in randi that I want fixed. I could be ready as soon as Sunday,
12/16 to move to step 4. But, if we want to give people a bit more
notice we could wait a week until Friday, 12/21.
--Rik
|