On Mon, Apr 28, 2008 at 1:05 PM, Paul POULAIN <[EMAIL PROTECTED]> wrote: > Hello, > > I begin to be really troubled by all those new features added in the > main trunk... > > I think we really should stop hacking koha that much & work only on > stabilizing things. And by stabilizing I mean "stop adding anything new, > strictly, really strictly, just fix things that have to be fixed" Hi Paul et al,
First off, as usual, you raise excellent points. I think there are a few questions that we should ask ourselves directly: Is Koha 3.0 stable enough to be released? If not, what must be fixed before it's ready? This question has to do with what we are saying when we 'release' software as 'stable'. My assumption is that the reason to release is that the software is ready to be deployed in production environments; it symbolizes a point at which we believe that the implemented features are usable, and that the software is ready to be put into 'maintenance' mode, where only bugfixes and security patches are to be applied. Presumably the users of that version will expect to get some mileage out of a stable release, as opposed to running something that is in 'beta' mode, where bugs are expected to turn up on a regular basis. We also assume that the DB is stable, and that documentation and installation/upgrade procedures are in place. Assuming we're all on the same page there, how to proceed? There are clearly blocker bugs on bugzilla, for some of these, a bugfix might look a lot like a rewrite of much of the functionality. (XXX bugs in bugzilla, give stats). Should that be done in 3.0 or a future version? If in a future version, do we back-port those bugfixes to the 3.0 version? Who is responsible for maintaining that 3.0 version, for how long, etc. Obviously, as you've alluded to, none of us can just work on bugfixing. Many of us also have new features that we must create, which brings us to the next question: why would we want them to go into 3.<futurenumber> instead of 3.0, since 3.0 isn't stable; and assuming that I agree it should go into 3.2, how do I get it there? How is the process managed? Until now, with the 3.x repository, Small features have been added in conjunction with major bug fixes, primarily because we haven't been able to afford the maintenance overhead of maintaining two Koha branches; we may be at a point where this is now possible given existing community resources; or perhaps we can arrive at an alternative to running more than one branch or head of Koha. Clearly, while we have a very well-thought-out process for installing and upgrading koha, as well as releasing from a HEAD branch, we do not have, and have not defined, what the process becomes when we branch that needs to be specified/defined before we jump in with a final release and start adding stuff to a 3.1 or 3.2 branch. It may be ovious to git experts and previous RMs what the process is for branching, then working in the new environment with branches, but most of our developers, myself included, haven't had experience with that, so we need to document it just like we did with the wiki page on git_usage. In fact, we should actually do some dry runs with branching i.e., make a copy of the git repo, set up brances, run through scenarios involving dealing with bugfixes and enhancement patches On the other hand, can we get away with tagging releases for a few more releases until things stabilize? That is, can we just say that we work against MAIN/HEAD and tag releases, and all bugfixes and new features go into the next version? How about managing patch submissions? Lets say you develop against rel_3_0-stable ... and you submit a patch to [EMAIL PROTECTED], how do patch maintainers know it's for rel_3_0-stable and not MAIN/HEAD/ (maybe git takes care of this for us, I don't know). Maybe we simply don't accept patches for rel_3_0-stable or perhaps we have a separate mailing list. How will these decisions affect the upgrade process for users that expect the 'stable' release to be stable (if we release 3.2 in two months for instance). People may intentionally not want new features. These are just a few of the issues surrounding this topic that I've been able to come up with, I'm sure others can come up with more. Also, I think this issue is currently too large to hash out on #koha, particularly if we get all of the active developers invovled. I would prefer that we not immediately jump to an IRC meeting, but instead give people a few days to discuss over email and hopefully reach consensus. With any luck, the IRC meeting will end up being more of a confirmation and discussion of a decision made over koha-devel. So ... let the discussions begin! Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS [EMAIL PROTECTED] |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
