Galen Charlton a écrit : >> 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.
I think we also have to separate a bug that results in an "unworking feature" from a bug resulting in an "data corruption". For a "data corruption bug", even a workaround is not acceptable. Let me give you an (small & fixed) example : the renew button. There was a place were it was not working well : the renew counter was incremented, but the renew date didn't change. Not blocking, as there are at least 2 other ways to do a renewal. Bug blocking because the offending button result in data corruption (although small) In this case, I prefer an "internal server error" without data corruption to such a behaviour !!! > 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. imho, we need a "Release Maintainer" that will be responsible for deciding wether a patch has to be backported or not. >> 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. what about version number. We are supposed to be numbered like linux kernel : odd numbers = unstable, even numbers = stable. so why couldn't we release 3.1.x every month/almost stable milestone/when the RM think it's worth and release 3.even.x twice a year ? It's an important question that LibLime and BibLibre will have -for sure- to answer : when a feature is ready in git, but not officially released, should we have specific branches for that specific customer of just say "it's almost ready, but you'll have to wait for next official release". Depending on the case (sponsored dev, signed timeline...) I think the answers will differ. but the question is VERY important (that's the businessman who speaks) Let's me explain : atm, BibLibre has 3 major projects. One started, 2 waiting for customer decision. If both reaches the "contract" phase : - that's very good news, we will have to hire 3 or 4 more people... - those customers have must-respect timelines (at least for one of them). - those projects will require the developpment of many new things. will we : - work on a specific branch, then merge - work on main branch directly, at the price of a risk with the timeline ? I don't see clearly the answer to this question. If ppl from LibLime have an idea about this ... joshua, that's probably something we can speak of in Lyon, in june. We have to organize the future of Koha in 2 ways : - coordinate the community & help anyone that want to be involved - coordinate our businesses projects. We are 2 major companies (I mean BibLibre is a major one ;-) ), we will have to find how to coordinate our businesses. LibLime has won WALDO and announced that "WALDO has commissioned LibLime to substantially enhance Koha to meet the requirements of academic libraries" BibLibre has announced a new acquisition system, that is underway (see mail here some months ago) How to deal with those projects, the coordination of our businesses, and the community aspect of all of this... >> Only one thing left: who should put the seal of approval about when Koha >> is ready? I think it's : - the Release Manager - the Community general opinion As I said, 6 or 7 libraries here are running 3.0 live. All of them are happy with it. > 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. I prefer consensus. And I think the consensus will be quickly reached if we branch, and stop working like mad on patches. every morning, I spend between 10mn and 1 hours to look at patches, do some testing... because I know that sometimes some patches can break some things. > 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 OK > b. possible changes to biblioitems to remove call number fields - > this was briefly discussed on #koha, but a general RFC is needed maybe OK. Although i'll wait for RFC. I think what we have now can be kept as is and just unused ? > c. one change to accountlines to implement dropbox returns I still don't have understood that it is, even after some kados explanations on #koha > 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. agree > e. a change to borrowers to support alternate IDs - RFC to come I definetly would not add that to 3.0 > f. changes to support linking icons to authorized values I definetly would not add that to 3.0 > g. cleaning up names of system preferences, to do as a single DB update I definetly would not add that to 3.0 > 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. <snip> agreed -- 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
