octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Release 4.2 Kickoff


From: Rik
Subject: Release 4.2 Kickoff
Date: Mon, 27 Jun 2016 09:13:25 -0700

6/27/16

All,

I've created the 4.2 release checklist to organize our activities
(http://wiki.octave.org/4.2.0_Release_Checklist).  The corresponding bug
list is http://wiki.octave.org/Bug_Fix_List_-_4.2_Release.

The first activities are all based on identifying what needs to be fixed
before the release can happen:

1) 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:

2) Review patch tracker/bug list for any patches submitted that may be
included before release
    Completion Date:

3) 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:

Consider the first item done with my Request for Comments e-mail.  Any
outstanding problems should be reported to the bug list so that we have a
record of them and can properly sort them based on importance.

The 4.2 bug fix list needs to be populated after reviewing the bug tracker
and patch tracker (item #3).  Unfortunately I am quite busy at work
presently and will have to take a less active role this release.  But, we
have three new Octave maintainers--Avinoam, Lachlan, and Pascal--who have
expressed willingness to help with sorting and prioritizing bugs.  For
them, and everyone else, the page
http://wiki.octave.org/Bug_Fix_List_-_4.2_Release is on the wiki so anyone
may edit it.  I have used the following categories:

Bugs marked as Crash
Bugs marked Configuration and Build System
Bugs with severity >= 4
Bugs marked as regressions
Bugs marked GUI
Bugs related to Windows OS
Other Bugs

The 4.0 release had a special focus on the GUI and support for Windows.  It
may be that those two categories should not be used for this release, and
instead the most important bugs from those categories should be placed in
one of the other classifications.  I would suggest taking two weeks, to
July 8th, to accomplish the first three release tasks, before moving on to
the much harder bit of fixing the identified bugs.

Happy coding,
Rik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]