Joshua Ferraro a écrit : > First off, as usual, you raise excellent points.
Thanks to say that. > I think there > are a few questions that we should ask ourselves directly: > > Is Koha 3.0 stable enough to be released? Here in France, if I don't mind, we have 6 libraries running live with Koha 3.0beta2 > If not, what must > be fixed before it's ready? which does not mean there are no more bugs. but none of them can't be "workaround-ed". > 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. I agree. Even if we had previously seen that the term (BibLibre, french) of "useable" is not the same than your (LibLime, USA). > 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. Important point the DB. The 2nd one being the API. Previously, I had decided to release 2.0 and 2.2 after something like 3 1.9.x release without any change in the DB or in the API. > 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. I would add that some of them could have a status lowered to "normal" by an easy workaround that would not solve the problem on the long term, but give us a solution for the short term. > (XXX bugs in bugzilla, give stats). bugs.koha.org tells me : - 302 bugs - 14 BLOckings - 8 CRItical - 12 MAJors - lots or NORmal, MINor, TRIvials, and ENHancement requests I suspect some of the BLO/CRI/MAJ one are already solved or have an acceptable workaround that could lower their severity. for example : 1621 and 1719 ( => XSLT), 2022... > 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. see my opinion below about that > 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, atm, our (BibLibre) most common daily work is deploying the v3 for our customers (& writing answers to RFPs) > 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; because that's the best way to have a never stable software !!! > 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 I don't consider that the features i've pointed are "small". And even a small feature is a risk for stability. The only think I could easily live with is a new report (as reporting means only reading things). When a code write something in the DB, there is a risk. When an API changes, there is a risk. > 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. I think so. > 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 my proposal (summarized) : git-branch koha30 => to create a branch koha for koha 3.0, that is for strict bugfixes only for developpers : - have a git repo from git.koha.org (say in ~/head) - clone the local repo himself : git clone ~/head ~/stable - cd ~/stable - git checkout -b koha30 origin/koha30 => to have ~/head reflect the stable version work on HEAD : as usual work on koha30 : - cd ~/stable - git pull to update the stable version (in case a patch came from official repo - do your stuff & commit it - git-format-patch git-send-email [EMAIL PROTECTED] (new mailbox) The question is : how to work with patches that could go to the other branch... the answer is ... cherry pick. the HEAD Release Manager should be responsible for applying a patch from 3.0 to head if needed. Or the 3.0 Release Maintainer. Cherry picking patch from HEAD to 3.0 should almost never happend imo. > 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? I don't understand what you say here. > > 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. I vote for a specific mailbox & 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). good question. Your opinion ? I don't have a definitive one I think > People may > intentionally not want new features. ??? > 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. I agreed, so I started the discussion ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
