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" just some examples of the side effects/problems with this activity : 1- the french translation was 100% done. I just updated the .po file : 192 fuzzy (chain changes) and 45 untranslated strings. And I keep the translation update really often. I'm afraid other translators will have a very bad surprise, seeing 20 or 25% of the stuff they already did has to be redone, because each change in the template will result in 2- I see some new features like patron images, tagging, serialsadditem at subscription level[1], move to yui 2.5.1 (from 2.31.), new sysprefs by dozens, important changes in the DB structure (the great new permission/sub permission, the old_issues table). Important code refactoring/cleaning. All those great. Undoubtfully. But the risk to introduce some unexpected bugs where things were working previously is really BIG. Just 2 examples : one patch of me troubled kados, because he broke something in another page : the problem was directly introduced by a change in API (C4::Dates.pm). I was not wrong with my patch, I just discovered a larger problem (that atz has fixed iirc). the patch to add a new way to introduce issuing rules resulted in the unexpected bug #2000. [1] yes, I know, this patch is mine. but with the release being so delayed, I was tired to delay this patch & have decided to send it. 3- I see some gui changes, done by owen, that are great. but such changes can be done forever, things will never be perfect (and one will find something awful when someone else will say it's great :-\ ). 4- Joshua, you've announced the alpha for jan, 4. beta for feb, 1st and stable for march, 1st. We are almost may 1st, and still no stable version released. I would be interested to know how many commits were related to true "bugfixes" and how many were related to "improvement/cleaning/new features". I would say it's 30% / 70% (numbers not calculated scientifically ;-) ) In french we says "better is sometimes enemy of good". I think we are facing this situation : "better" is now our biggest enemy. So, I request/propose the following decision to be taken : - we didn't have had an irc meeting for a long time, it's time to plan one. - no changes in the code, except true bugfixes. "imperfection" fixes will be for later. - no more changes in templates except true spelling problems (or true bugfixes, of course), to let time to i18n teams to do their job. - create a branch, as soon as possible, to have ppl doing improvements on the dev branch, and bugfixes on the 3.0 branch. That's how we did for 2.0 and 2.2. I released a version once every 3 month or something like that. I agree we didn't had a company like LibLime doing 125/130 commits every month. (http://git.koha.org/gitstat/chart.php?chart_parameter1=3&chart_parameter_ver=R_2-2-9&submit=1&chart_parameter2_year=2008&chart_parameter2_month=4&submit=1&showcount=10), but 3.0 will never be ready if we continue like that. And with git, it should be "easy" for ppl wanting to have an hacked version of 3.0, with a backported improvement from the dev branch to be done. I'm sure, because I have some patches for some of our customers, that we haven't commited to the main repo (some of them will never be, some of them will be for 3.2, probably) Joshua, you probably have a different opinion than mine, as RM. But as previous RM, I had to write my thoughts. I hope you'll understand my opinion and agree on most of it. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
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"
For the most part, I agree. I think we've really strayed from the timetable, and I agree with Paul's observation that we're seeing a lot of new stuff and not a lot of bug fixing. I think there comes a time when we have to stop and evaluate whether the features that are getting added are really necessary to make Koha 3.0 a good solid package, and whether they're getting added because we've got customers asking for them. We all know this is a difficult issue--we've been through all this before with previous releases.
3- I see some gui changes, done by owen, that are great. but such changes can be done forever, things will never be perfect
Of course I disagree with anything referring to myself ;-)
And with git, it should be "easy" for ppl wanting to have an hacked version of 3.0, with a backported improvement from the dev branch to be done.
I agree. So let's have a meeting and see if we can arrive at a game plan! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Mon, Apr 28, 2008 at 1:05 PM, Paul POULAIN <paul.poulain@free.fr> 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 patches@koha.org, 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 jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
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 patches30@koha.org (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 > patches@koha.org, 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
The only think I could easily live with is a new report (as reporting means only reading things). This time, I disagree with Paul :) We must think about
Hi everybody, Here are my thoughts on the topic. They are not based on Koha-specific development, but on my past experiences as software developer manager. 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. Now, which bugs must/should be fixes? 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. 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. 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. translation/documentation. If we want to be able to ship Koha in the next few month (< 3), we must stop implementing ANY features, cosmetic one included. It's now time to kill bugs and stabilize Koha.
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). I doubt that we can release another version 2 months after a major release. We should plan as much as possible what will be part of the next releases.
This planing should included: - What major features will be included in this release (on a client point of view) - How long will it take to implement them - Who is responsible of that feature. Only once this evaluation is done that we can give an educated guess on a possible release date. Once those major features are implemented, we then must start stabilize the version for the 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. Of course, nothing prevent anyone to use the latest git in production at anytime. Remember that at the moment, we must all focused on SHIPPING Koha! It's been at least 2 YEARS since I read about the 3.0 release. It doesn't really make sense in term of software development. 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) Wow, I didn't expect to write so much stuff, but I think that I was inspired :) Have a good day! Eric Paul POULAIN wrote:
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 patches30@koha.org (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 patches@koha.org, 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 ;-)
Hi, On Tue, Apr 29, 2008 at 1:51 PM, Eric Bégin <Eric.Begin@inlibro.com> 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 galen.charlton@liblime.com p: 1-888-564-2457 x709
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
On Fri, May 2, 2008 at 5:32 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
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. Agreed.
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 like the idea proposed by someone, of having the release manager 'retire' and take over as release maintainer; stepping aside for the next release manager. So that would mean I'd be the release maintainer for 3.0 ;-).
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... This question has come up before. The ultimate question is, who is the Koha
This leaves open the question of who should be release manager of 3.2. I believe Galen would be in the best position of all of us to take over the role right now: 1. he only works on programming Koha, doesn't have to worry about any business or other concerns 2. he knows the code inside and out 3. he's demonstrated over the past months that he's very careful and takes both MARC21 and UNIMARC concerns into consideration 4. he has vast experience with library standards Certainly up for more discussion, but those are the top reasons I believe he'd be the best candidate for 3.2 RM. project for? Some projects, take the Linux Kernel for example, the project is designed primarily for distribution packagers to create operating systems that can be used by users (Debian, Fedora, etc.). Other projects, for example, Firefox, are downloaded and used directly by users. The Koha project has examples of both types of 'users'. I think that, especially since we have a lot of direct users downloading and installing Koha, it's especially important that we package it in a way that is usable by the greater community; and that any features that are developed are actually usable by non-programmers.
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. Perhaps. However, do they use authority control? Do they use IndependentBranches? Do they use LDAP and SIP2?
There are definitely libraries running on Koha 3.0 beta, no question. And no doubt the core functions work bug-free enough; however, that's no reason to assume that 3.0-stable should be released. When we put out a stable release, we are telling the community that the features advertised can be used by them.
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 Perhaps Ryan can expand on this..
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 well, if not added to 3.0, it will force us to put it live for several customers, who can't wait for 3.2 to have it. This will mean that LibLime customers won't be running the exact code as the release. It's a lot of extra overhead for us to maintain two branches, but perhaps it's necessary.
Since the code is already mostly written, and will be heavily tested, I don't see any harm in adding it.
f. changes to support linking icons to authorized values
I definetly would not add that to 3.0 Done already. It was the counter to the itemtype icons added a while back. Most US libraries find item-type icons to be useless. They are more interested in linking icons to bib-level information like audience, format, etc.
g. cleaning up names of system preferences, to do as a single DB update
I definetly would not add that to 3.0 I think we could negotiate on this point. However, I'll just point out that if we delay this change until 3.2, all of the 3.0 libraries will have to learn a whole new set of vocabulary for system preferences -- it could be pretty confusing.
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
<snip>
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
In most U.S. libraries, if a borrower returns an item after the library has closed on Monday, but before it opens on Tuesday, the item is treated as though it was returned Monday. The item is usually placed into a 'drop box', which is available when the library is closed. This is coded and tested, but needs to be merged. The accountlines table will store the last increment of an overdue fine so it can be removed when returning an item with 'dropbox mode' enabled. I do have some significant patches to Overdues.pm in addition to the dropbox patch; I have encountered some problems with holidays calendar corrections on fines calculations. Will submit these patches by late Thursday. -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
Ryan Higgins a écrit :
In most U.S. libraries, if a borrower returns an item after the library has closed on Monday, but before it opens on Tuesday, the item is treated as though it was returned Monday. The item is usually placed into a 'drop box', which is available when the library is closed.
OK, gotcha. we have the same thing in France. I was looking for "drop box" to be a computer term, not a "physical" box ;-) thanks -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Joshua Ferraro a écrit :
imho, we need a "Release Maintainer" that will be responsible for deciding wether a patch has to be backported or not. I like the idea proposed by someone, of having the release manager 'retire' and take over as release maintainer; stepping aside for the next release manager. So that would mean I'd be the release maintainer for 3.0 ;-).
I've nothing against that personnaly. I'm just wondering whether you'll have the time needed for that. In fact, I think you're already doing too much things (LibLime CEO, translation manager, Release Manager, ...). sometimes, we need 4 or 5 days to have a patch applied (or rejected). Even if the amount of time needed will decrease, I just wanted to ask. Note that I don't apply for this role, as we (BibLibre) are already overwhelmed. We (BibLibre) hope that hdl will be able to dedicate a little bit more time in the next months for community role. For instance, the role of QA manager means almost nothing in real life. I'm sorry about that, we should speak of how to introduce the QA role in the git process.
This leaves open the question of who should be release manager of 3.2. I believe Galen would be in the best position of all of us to take over the role right now: 2. he knows the code inside and out I agree
3. he's demonstrated over the past months that he's very careful and takes both MARC21 and UNIMARC concerns into consideration I agree
4. he has vast experience with library standards I agree
You can add 5. he's a nice guy always available on #irc & very community oriented.
1. he only works on programming Koha, doesn't have to worry about any business or other concerns
That's the only point I have questions about. (see later in this mail)
Certainly up for more discussion, but those are the top reasons I believe he'd be the best candidate for 3.2 RM.
I don't see anyone else to propose atm anyway.
As I said, 6 or 7 libraries here are running 3.0 live. All of them are happy with it. Perhaps. However, do they use authority control? yes
Do they use IndependentBranches? yes
Do they use LDAP and SIP2? no.
e. a change to borrowers to support alternate IDs - RFC to come
I definetly would not add that to 3.0 well, if not added to 3.0, it will force us to put it live for several customers, who can't wait for 3.2 to have it. This will mean that LibLime customers won't be running the exact code as the release. It's a lot of extra overhead for us to maintain two branches, but perhaps it's necessary.
Since the code is already mostly written, and will be heavily tested, I don't see any harm in adding it.
my experience show me 2 things : - there are *always* consequences you don't imagine when you code something. - that's the best way to never have a stable release. Look at your mails 5 months ago. You've announced that you'll just ad "this and that" (mail on koha-devel when releasing alpha or beta). Now you must add another feature for another customer. In 2 months, there will be another one. And you can be sure every addition will result in a new unstability. I bet whatever you want (for both new customer need & unstability) Some months ago, you told me "LibLime has decided to deploy only official version of Koha to hit customers". I was very happy with this news. I'm not sure anymore that i'm so happy. The risk, with this decision and the pressure your customers put on you will be to have no more a time based release or a feature based release, but a "LibLime Customer needs" based release. Which would be a real problem for our (BibLibre) business, and for the community as well. And, to say my deepest thought, I think this will result in never releasing a stable version at all. Releasing a stable version means "stop running". Another way to say that : you wrote you planned to release 3.0 in march, and 3.2 in june. aren't you planing in fact to release directly the 3.2 in june (I mean a version numbered 3.0 with all the features you planned to include in 3.2 previously) On the other hand, having a LibLime version of Koha and an official version will be a shame as well, as I understand you don't have so much ressources to put on doing things twice & maintaining 2 releases. My feeling (as BibLibre CEO), is that there are 2 cases : - very time pressuring customers : have a specific release with the feature they want without waiting for an official release. And include in the proposal the fee to reintroduce the feature in official version later. - other consumers : be cheaper, and tell them the feature will be available in version X, that will be ready in Y months. That's how we plan to do for our 3 large projects I spoke of in my previous mail : the features will be in an independant git branch, that we will synch in koha official asap, but after the customer deployment. (and the git repo being available to anyone interested. The git repo with the new acquisition module -announced here in january- should have been opened for weeks now, but I couldn't find time to do it. sorry & shame on me)
f. changes to support linking icons to authorized values I definetly would not add that to 3.0 Done already. It was the counter to the itemtype icons added a while back. Most US libraries find item-type icons to be useless. They are more interested in linking icons to bib-level information like audience, format, etc.
I agree it has already be done... And it has broken something !!! Authorized_valued can't be edited anymore. hdl has submitted a patch yesterday if I don't mind. sorry to be hard on that, but almost everytime we add a feature those times, we introduce some kind of unstability !
g. cleaning up names of system preferences, to do as a single DB update I definetly would not add that to 3.0 I think we could negotiate on this point. However, I'll just point out that if we delay this change until 3.2, all of the 3.0 libraries will have to learn a whole new set of vocabulary for system preferences -- it could be pretty confusing.
I agree on the point you point. But I think it's less important that going to stability. And i'm also really sure it's impossible to fix that without introducing many problems. Really sure -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Hi Paul, On Wed, May 7, 2008 at 11:10 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
On the other hand, having a LibLime version of Koha and an official version will be a shame as well, as I understand you don't have so much ressources to put on doing things twice & maintaining 2 releases.
It's not our intention to maintain a LibLime version of Koha - I agree that we don't have the resources to do that, nor any desire to do so: we're committed to the community, consensus version of Koha. What I have in mind is that LibLime may need to make a 3.1-features branch in git (and perhaps create a public LibLime git repo so that people can see work we do that may not be ready yet for integration into consensus Koha) to tide us over for some immediate developments. Such a branch would be as short-lived as possible, and would be merged into the upcoming 3.2 line of development as soon as possible. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton a écrit :
What I have in mind is that LibLime may need to make a 3.1-features branch in git (and perhaps create a public LibLime git repo so that people can see work we do that may not be ready yet for integration into consensus Koha) to tide us over for some immediate developments. Such a branch would be as short-lived as possible, and would be merged into the upcoming 3.2 line of development as soon as possible.
I fully agree, and that's whay I said (or wanted to say, in case I was not clear enough !) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
"Joshua Ferraro" <jmf@liblime.com> wrote: [...]
I like the idea proposed by someone, of having the release manager 'retire' and take over as release maintainer; stepping aside for the next release manager. So that would mean I'd be the release maintainer for 3.0 ;-).
This leaves open the question of who should be release manager of 3.2. I believe Galen would be in the best position of all of us to take over the role right now: [...]
Sorry for posting before reaching the end of the thread but I'd much prefer the next RM to be from a different enterprise and country from the last, to preserve the strengths of Koha past. There seem to be IMO at least 5 businesses trying to grow the Koha world, so if 2 of them (LibLime and BibLibre) are happy to alternate for now, that would be great. It maybe also increases the incentive for those two to "encourage" faster releases? Snowed under, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
MJ Ray a écrit :
Sorry for posting before reaching the end of the thread but I'd much prefer the next RM to be from a different enterprise and country from the last, to preserve the strengths of Koha past.
I think it's a very good idea and, as BibLibre, fully agree with it.
There seem to be IMO at least 5 businesses trying to grow the Koha world, so if 2 of them (LibLime and BibLibre) are happy to alternate for now, that would be great.
That's the main question : does someone candidate for this ? MJ, do you have someone in mind ?
It maybe also increases the incentive for those two to "encourage" faster releases?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Hi, On Mon, May 12, 2008 at 4:08 PM, MJ Ray <mjr@phonecoop.coop> wrote:
"Joshua Ferraro" <jmf@liblime.com> wrote: [...]
This leaves open the question of who should be release manager of 3.2. I believe Galen would be in the best position of all of us to take over the role right now: [...]
Sorry for posting before reaching the end of the thread but I'd much prefer the next RM to be from a different enterprise and country from the last, to preserve the strengths of Koha past. There seem to be IMO at least 5 businesses trying to grow the Koha world, so if 2 of them (LibLime and BibLibre) are happy to alternate for now, that would be great. It maybe also increases the incentive for those two to "encourage" faster releases?
Since my name's been mentioned as a possible RM for 3.2, I'd like to make my case. I've been working in library software for nine years and am familiar with library practices, particularly with respect to metadata. I've made a lot of contributions to Koha in the past six months, both in terms of code and participation on the mailing lists and IRC channel. As Joshua mentioned, I currently work on nothing but Koha, spending perhaps three quarters of my time on development and bugfixing and a quarter on customer migration projects. While I do some travel, mostly to conferences, I would be able to devote more time to RM duties. I am committed to helping move the project to more frequent releases. I agree with MJ's point - Koha is not a "benevolent dictator" sort of project, nor limited to any one view of library practice, so I suggest establishing a position of a secondary RM - someone who works with the primary RM to integrate patches, would do testing and signoffs of complicated patches, and, importantly, is designated to step in to keep the flow of patches going when the RM is away. This would have several advantages: if I become RM, while I do not and will not have the level of travel that Joshua does, I do attend some library conferences and have been known to take the odd vacation. Having additional coverage would be useful no matter who is RM, of course - we shouldn't require that the RM be available 365 days a year. Secondly, the secondary RM (or perhaps, co-RM, depending on how much time that person spends) clearly should not come from the same employer as the RM, and should have as much of different background as possible. E.g., if I'm chosen to be RM, an ideal secondary RM would be non-USian or would work a library instead of a support vendor. Personally, I would be happy to work with somebody from BibLibre (or to be a secondary RM to somebody from BibLibre), particularly since I know that both LibLime and BibLibre have ideas for large projects. This is not to say that LibLime and BibLibre are the only current sources for candidates for the RM position; I do feel that the RM should be somebody who's actively and publicly working on Koha and is familiar with the 3.x codebase. Similarly, to spread out the workload, I think it would be a good idea to have more than one designated QA position, i.e., one or more people who are designated to do testing and sign off on patches. Over the next few days, I will start sending out RFCs regarding what LibLime is working on or plans to work on, particularly with respect to features to be targeted for 3.2, 3.4, and perhaps 3.6. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton a écrit :
As Joshua mentioned, I currently work on nothing but Koha, spending perhaps three quarters of my time on development and bugfixing and a quarter on customer migration projects.
The only point I could note is that for instance you're hired by LibLime. So you could/will/may/... face conflicts : community want "that" and LibLime want "this". How will you deal with that problem. The best solution would be, I agree with joshua that suggested it, to have a collective pot that could let us have a RM independant from any vendor. How large should be the pot ? Who could put some money on it ?
While I do some travel, mostly to conferences, I would be able to devote more time to RM duties.
mmm... do you mean you plan to do RM tasks mostly when at airport ?
I am committed to helping move the project to more frequent releases.
++
I agree with MJ's point - Koha is not a "benevolent dictator" sort of project, nor limited to any one view of library practice, so I suggest establishing a position of a secondary RM - someone who works with the primary RM to integrate patches, would do testing and signoffs of complicated patches, and, importantly, is designated to step in to keep the flow of patches going when the RM is away.
++, although that would need a *huge* coordination between the 2 RMs, which i'm not sure can be achieved.
Similarly, to spread out the workload, I think it would be a good idea to have more than one designated QA position, i.e., one or more people who are designated to do testing and sign off on patches.
hdl is supposed to do some things about that, but it has not become something tangible yet.
Over the next few days, I will start sending out RFCs regarding what LibLime is working on or plans to work on, particularly with respect to features to be targeted for 3.2, 3.4, and perhaps 3.6.
+++ (at the end of May, we should know if we won the huge RFP we are waiting for. We will publish some RFCs as well is we won, for sure !) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Hi to all, I have installed Koha 3 beta 2 with all new fix availables on git. I use debian I have installed koha in 'dev' mode Until now all is working. During test I have found a new perl module required (only for test): HTML::Scrubber It is used in C4::Scrubber.pm It isn't listed in Makefile.PL, so during the configuration is not asked to install it Bye Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)
Thanks for reporting this. I have sent a patch to correct Makefile.PL. -- Joe Atzberger On Wed, May 14, 2008 at 9:21 AM, Zeno Tajoli <tajoli@cilea.it> wrote:
Hi to all,
I have installed Koha 3 beta 2 with all new fix availables on git. I use debian I have installed koha in 'dev' mode
Until now all is working. During test I have found a new perl module required (only for test): HTML::Scrubber It is used in C4::Scrubber.pm It isn't listed in Makefile.PL, so during the configuration is not asked to install it
Bye Zeno Tajoli
Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Another dependency I have seen on my recent installation on Debian Etch is for Image::Magick. It is better to do an apt-get install of perlmagick. John +-----------------------------------------------------------------+ John Chadwick, Ed.D. Information Technology Manager New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 Phone: 505-476-9740 Cell: 505-629-8116 Fax: 505-476-9761 john.chadwick@state.nm.us http://www.nmstatelibrary.org -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Zeno Tajoli Sent: Wednesday, May 14, 2008 7:21 AM To: koha-devel@lists.koha.org Subject: [Koha-devel] a new perl dependence Hi to all, I have installed Koha 3 beta 2 with all new fix availables on git. I use debian I have installed koha in 'dev' mode Until now all is working. During test I have found a new perl module required (only for test): HTML::Scrubber It is used in C4::Scrubber.pm It isn't listed in Makefile.PL, so during the configuration is not asked to install it Bye Zeno Tajoli Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @) _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
Hi, On Tue, May 13, 2008 at 3:56 PM, Paul POULAIN <paul.poulain@free.fr> wrote:
Galen Charlton a écrit :
As Joshua mentioned, I currently work on nothing but Koha, spending perhaps three quarters of my time on development and bugfixing and a quarter on customer migration projects.
The only point I could note is that for instance you're hired by LibLime. So you could/will/may/... face conflicts : community want "that" and LibLime want "this". How will you deal with that problem.
Of course, that issue would affect any RM who is working for a Koha support vendor, and even an RM working for a library wouldn't necessarily be 100% immune to getting conflicts about features wanted by that particularly library. But it is a fair question. Approaches I would take include: * More and better communication about LibLime's proposed enhancements. * Continuing Koha's use of sysprefs to guard optional features - this may not be the ideal mechanism, but it does make it possible to compromise on some features and let those who are interested in a particular feature to maintain it. * Where appropriate, implementing a drastic change in the form of a separate OSS project that can integrate with Koha, such as Biblios or the acquisitions client that LibLime is working on (and if I remember correctly, the new acquisitions client that BibLibre is writing). * Where there are disputes about fundamental Koha architecture, discuss them and compromise. One thing to keep in mind is that LibLime's clients generally pay for specific features - nobody thus far (and I predict, ever :) ), is likely to specifically want to pay LibLime to rewrite Koha in Erlang or anything drastic like that.
The best solution would be, I agree with joshua that suggested it, to have a collective pot that could let us have a RM independant from any vendor. How large should be the pot ? Who could put some money on it ?
An independent RM, perhaps somebody working for a library that uses Koha, would be great -- it would reinforce a notion that libraries are ultimately the owners of the Koha project. However, I must admit that I see many practical problems finding such a person quickly. Who would it be? Being RM requires a large time commitment - is there somebody out there working at a library who is familiar enough with the code, well known enough to the developers, and able to get permission from their employer? If the vendors were to pitch in to offer financial support, could that money be readily given to the person without creating unsupportable conflicts of interest? Would we need to get a Koha project foundation up and running first to accomplish it? Of course, somebody could offer to RM as a "spare time" project, and perhaps would be in a position to accept financial support as a sort of second job. if so, great. Is anybody volunteering? The one thing I don't think we should do is attempt to "hire" a RM from outside of the community - for that person to have credibility, he or she really must know Koha, be actively contributing to it or have made significant contributions to the past, and ideally have a direct interest in the success of the project, either by using Koha or supporting Koha users.
While I do some travel, mostly to conferences, I would be able to devote more time to RM duties.
mmm... do you mean you plan to do RM tasks mostly when at airport ?
To emphasize, while I do some travel, I do not do a *lot* of it, and certainly much less than Joshua does. Suggesting that I would be "plan[ning] to do RM tasks mostly when at airport" is incorrect. Of course, there would be times when I'm not available, which is one reason why I proposed the notion of a secondary RM.
I agree with MJ's point - Koha is not a "benevolent dictator" sort of project, nor limited to any one view of library practice, so I suggest establishing a position of a secondary RM - someone who works with the primary RM to integrate patches, would do testing and signoffs of complicated patches, and, importantly, is designated to step in to keep the flow of patches going when the RM is away.
++, although that would need a *huge* coordination between the 2 RMs, which i'm not sure can be achieved.
It would require some coordination, but not necessarily a huge amount of it. The overall development plans should be communicated via koha-devel RFCs and the staff wiki anyway, and those should be what the RMs base their decisions on. Sure, it's possible that the RMs will occasionally disagree about a patch, but that's to be expected, really, and would be worked out as such issues occur. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
Galen Charlton a écrit :
Hi, * More and better communication about LibLime's proposed enhancements.
++
* Where appropriate, implementing a drastic change in the form of a separate OSS project that can integrate with Koha, such as Biblios or the acquisitions client that LibLime is working on
The acquisitions client that LibLime is working on ??? I don't remember hearing anything about a new acq client before this mail. Could you explain a little bit more ? Isn't there a risk to overlap with what we are working on atm ?
* Where there are disputes about fundamental Koha architecture, discuss them and compromise. One thing to keep in mind is that LibLime's clients generally pay for specific features - nobody thus far (and I predict, ever :) ), is likely to specifically want to pay LibLime to rewrite Koha in Erlang or anything drastic like that.
I'm sure I won't have any problem with that too. The client want a feature, he isn't interested how it is writen.
Of course, somebody could offer to RM as a "spare time" project, and perhaps would be in a position to accept financial support as a sort of second job. if so, great. Is anybody volunteering?
meaningfull silence from "anybody"...
The one thing I don't think we should do is attempt to "hire" a RM from outside of the community - for that person to have credibility, he or she really must know Koha, be actively contributing to it or have made significant contributions to the past, and ideally have a direct interest in the success of the project, either by using Koha or supporting Koha users.
I agree it's not a good solution as well. Cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
On Mon, May 12, 2008 at 5:08 PM, MJ Ray <mjr@phonecoop.coop> wrote:
"Joshua Ferraro" <jmf@liblime.com> wrote: [...]
I like the idea proposed by someone, of having the release manager 'retire' and take over as release maintainer; stepping aside for the next release manager. So that would mean I'd be the release maintainer for 3.0 ;-).
This leaves open the question of who should be release manager of 3.2. I believe Galen would be in the best position of all of us to take over the role right now: [...]
Sorry for posting before reaching the end of the thread but I'd much prefer the next RM to be from a different enterprise and country from the last, to preserve the strengths of Koha past. This is a wonderful idea. What enterprises from which countries have resources to devote a person at least part-time to this position?
There seem to be IMO at least 5 businesses trying to grow the Koha world, so if 2 of them (LibLime and BibLibre) are happy to alternate for now, that would be great. It maybe also increases the incentive for those two to "encourage" faster releases? Also a great idea. I'm all for fast releases so long as the software is
Do we need to look at collectively throwing some money into a pot and hiring a community person to do these kinds of community roles? It's a very large burden for any one organization to take on. production quality. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
"Joshua Ferraro" <jmf@liblime.com> wrote:
On Mon, May 12, 2008 at 5:08 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Sorry for posting before reaching the end of the thread but I'd much prefer the next RM to be from a different enterprise and country from the last, to preserve the strengths of Koha past. This is a wonderful idea. What enterprises from which countries have resources to devote a person at least part-time to this position? [...]
I thought BibLibre were offering, but I guess from Paul's later message that I misunderstood. TTLLP's Koha effort is currently in turbulence, mainly due to the 3.0 target dates mystery, but I will seek one-off funds (grants, escrowed bounties and so on) if this idea is generally well-regarded, either for us to pay someone for a fixed term or to contribute to a community pot. The related thing is: what targets does the community have for an RM? Furthermore, how do we find those targets (Paul's consultation seemed to work well, as far as it went) and how do we reward them for hitting them? (Paul's consultation outcome looks forgotten.) Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
Just to review today/tonight patches (depending on your TZ ;-) ): * 5 strings to update. 4 of them being just a : added at the end. Just a ":" Remember what it means for translation : - run tmpl_process3.pl update - wait until it's done (10 seconds on my core duo) - open kbabel - find and fix the 5 strings - re-run tmpl_process3.pl, this time with "install" pragma - commit the changes for public release This having to be done for each language ! * imo bug 2047 commits should not have been validated now : it's an improvement. cheers -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
sorry, but 1 other example of "better enemy of good" : the patches for #2047 breaks scanindex searches, that badly fails : Can't call method "field" on an undefined value at /home/paul/koha.dev/frantiq/C4/Biblio.pm line 3123. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
Paul POULAIN a écrit :
sorry, but 1 other example of "better enemy of good" : the patches for #2047 breaks scanindex searches, that badly fails : Can't call method "field" on an undefined value at /home/paul/koha.dev/frantiq/C4/Biblio.pm line 3123.
(patch on the way for this one, but mayber still another side effect I haven't seen...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19
participants (10)
-
Chadwick, John, DCA -
Eric Bégin -
Galen Charlton -
Joe Atzberger -
Joshua Ferraro -
MJ Ray -
Owen Leonard -
Paul POULAIN -
Ryan Higgins -
Zeno Tajoli