Hi, On Tue, Apr 29, 2008 at 1:51 PM, Eric Bégin <[EMAIL PROTECTED]> wrote: > The main point of tagging a version as Beta is that features complete. > This doesn't mean that there are no bugs. Beta versions still have > bugs, knowned and unknowned. However, the goal of a development team is > to kill those bugs as soon as possible to ship an official release.
A *good* official release - hopefully we can optimize for both speed and quality (at the expense of sleep?) over the next few weeks. ;) > The first thing is to revise their severity. I agree with Paul's when > he says that if there is a workaround, it should not be a blocking, > critical or a major bug. If, at release time, there are important KNOWN > bugs in Koha with workarounds, they should be list in the Known issues > section. While I think the principle proposed here is OK, we should exercise judgment about whether any given workaround is suitable - a workaround that is obvious to the user and requires little extra extra effort to implement is one thing. A known workaround that imposes an unusually large amount of time or effort to use should not justify lowering a bug's severity. > Blocking, Critical and Major bugs must be fix if there is no workaround. > Other bugs (normal, minor, trivial & enhancement) have to be fix only if > there are no major impact on Koha. If there is a risk of making any > part of Koha unstable, I suggest that this bug is pushed to the next > point-release (in our case 3.1). > In that case, it is the role of each and every developers to define the > risks of a fix. > The role of the Release manager and the QA manager to decide if the bug > fix worth to be implemented vs the risk of making Koha unstable. One issue we have to think about is *measuring* stability. Courtesy of Andy, we now have a testing framework that permits us to write unit tests that can act on a test database. As bugs get fixed, particularly for the 3.0 release, I encourage all developers to write and submit regression tests to accompany each bugfix. If anybody has questions about how to write test cases that use Test::Class and the KohaTest framework, please contact me or Andy via e-mail or on #koha. > Every bugs fixed in 3.0 should also be fixed in 3.1. Thanks to git to > make it easy. > > I'm against bugs' backporting. If a bug is found after the release, it > can be fixe either with a patch or in the next point release, depending > of the bug's severity. Of course, if someone wants to fix it in its > library, he can do it using git. I disagree, at least in the general case - some bugfixes we can and should backport to 3.0, at least for as long as 3.0 is considered to be maintained. In particular, security bugfixes must be readily available, and not just as patches floating around koha.org. That being said, I of course do not advocate making a policy of backporting new features or minor bugfixes. In any event, we can postpone making final decisions about maintaining 3.0 after its release. > I really think that we should try to have an official release every 4 or > 6 months, which is 2 or 3 releases a year. If a feature is added later > on and it didn't fit the next release schedule, it's just to bad. It > will have to wait the next release. I agree that increase the frequency of releases is a good idea. However, I object to setting release schedules in stone - we must find a balance between shipping often and shipping when ready. > Only one thing left: who should put the seal of approval about when Koha > is ready? > > Usually, this is the role of the QA Manager, which is now Henri-Damien > if my memory serves me well. (btw, the Koha 3.0 Roadmap still show Chris > C. as QA manager) I think the QA manager could reasonably have a *veto* over declaring a general release. However, I don't think the QA manager should be able to unilaterally *declare* the release -- that should be the decision of the RM and QA jointly along with a consensus (or at least preponderance) of the active developers. What's the way forward? Here's my proposal: 1. Announce a freeze on the database schema and new features for the end of next week. There are a few things LibLime would like to slip in now to help clear our immediate queue, including: a. a few changes to import_batches and friends to improve record overlay - I will submit a patch for this later today b. possible changes to biblioitems to remove call number fields - this was briefly discussed on #koha, but a general RFC is needed c. one change to accountlines to implement dropbox returns d. a change to labels. As noted earlier today, this module appears to need a lot of QA effort to prepare it for 3.0. e. a change to borrowers to support alternate IDs - RFC to come f. changes to support linking icons to authorized values g. cleaning up names of system preferences, to do as a single DB update h. any other DB schema changes that other developers are working on right now. 2. Upon freezing of the database schema, start a 3.1 branch for new work to be added between now and when we start formally planning 3.2. I'm using "branch" advisedly - I don't yet have a clear picture of exactly how we should set it up in git. However, I think it is important that 3.1 exist so that we can keep a linear stream of database schema changes. 3. Put the 3.0 branch into bugfix-only mode. Focus our energy on the release. Besides clearing the bugzilla queue, areas LibLime is especially interested in making sure are stable for 3.0 include SIP2 support, LDAP integration, security issues (e.g., scrubbing and/or escaping of HTML tags in patron comments and the like), reports, OPAC RSS feeds, and fully testing the 2.2 to 3.0 upgrade process. 4. Release 3.0. 5. Plan 3.2. As far as I know, we're using even revision numbers for release intended for production, so the 3.1 line of development would end up becoming 3.2 at some point. Step 3 will need to be planned in more detail, of course, and tied to specific dates. Regards, Galen -- Galen Charlton Koha Application Developer LibLime [EMAIL PROTECTED] p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
