Koha 3.0 Stable Release Plan
Hi folks, I've done an audit of the outstanding bugs in Bugzilla and have found 39 are marked as blocker, major, or critical: http://tinyurl.com/5hysmf There are an additional 157 marked 'normal': http://tinyurl.com/5apjsy Galen and I discussed the blocker, major, critical issues and concluded we could address them with a concerted effort before Monday, June 16th. I'd like to set that as the date for releasing 3.0-stableRC1, then do a string freeze, to allow translators to wrap up any changes to translations, and then a final 3.0-stable on July 1. I do request that those of you using and programming Koha take a look at the outstanding bugs in both categories, and flesh out any issues in more detail where you can -- and if you feel a bug in the 'normal' category should be prioritized, please speak out. Thanks to everyone who's contributed, even in small ways, to the major improvements to this new version of Koha. 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
Personally I think all system preference bugs should have a high priority (even though they aren't all labeled as such). I say this because many people are installed Koha without professional help - if we have preferences that do nothing or don't work right it will cause problems for these people. Here's my list of reported system preference bugs: 1913 opaclargeimage - doesn't do anything 1923 OPACDisplayExtendedSubInfo - doesn't do anything 1943 OPACViewOthersSuggestions does not appear to work 1945 URLLinkText does not appear to do anything 1947 OPACSubscriptionDisplay depreciated? 1948 LibraryName has wrong description 1960 sortbynonfiling depreciated 2115 OpacMaintenance depreciated 2116 Disable_Dictionary Syspref depreciated 2117 opacbookbag should have the term 'cart' in the description 2118 virtualshelves should say 'list' in the description 2119 suggestion syspref is free text and should be y/n 2142 maxItemsInSearchResults No longer used -- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ On Wed, May 21, 2008 at 9:22 AM, Joshua Ferraro <jmf@liblime.com> wrote:
Hi folks,
I've done an audit of the outstanding bugs in Bugzilla and have found 39 are marked as blocker, major, or critical:
There are an additional 157 marked 'normal':
Galen and I discussed the blocker, major, critical issues and concluded we could address them with a concerted effort before Monday, June 16th. I'd like to set that as the date for releasing 3.0-stableRC1, then do a string freeze, to allow translators to wrap up any changes to translations, and then a final 3.0-stable on July 1.
I do request that those of you using and programming Koha take a look at the outstanding bugs in both categories, and flesh out any issues in more detail where you can -- and if you feel a bug in the 'normal' category should be prioritized, please speak out.
Thanks to everyone who's contributed, even in small ways, to the major improvements to this new version of Koha.
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi, I've noticed differences between English and French syspref: /installer/data/mysql/en/mandatory/sysprefs.sql /installer/data/mysql/fr-FR/1-Obligatoire/unimarc_standard_systemprefs.sql I've done a script which identified those differences. Variables available in 'en' but unavailable in 'fr-FR': 1. acquisitions 2. finescalendar 3. marcflavour - should be added to 'fr-FR' 4. opacmaintenance - should be removed (and in admin/systempreferences.pl) 5. opacmainuserblock - must be added to 'fr-FR' (that's from this syspref I've began noticing those differences) 6. opacuserjs 7. patronsperpage - should be added to 'fr-FR' 8. previousissuesdefaultsortorder - should be added to 'fr-FR' 9. sortbynonfiling - to be removed 10. specifyduedate 11. todaysissuesdefaultsortorder - should be added to 'fr-FR' Variables available in 'fr-FR' but unavailable in 'en': 1. amazondevkey - to be removed 2. authdisplayhierarchy - used in authorities/detail.pl and opac/opac-authoritiesdetail.pl 3. hidebiblionumber - to be removed (and in admin/systempreferences.pl) 4. readinghistory - used in several places: should be added to 'en'? 5. receivebackissues - to be removed (and in admin/systempreferences.pl) -- Frédéric
On Fri, May 23, 2008 at 1:40 AM, Frederic Demians <frederic@tamil.fr> wrote:
I've noticed differences between English and French syspref:
Hi Frédéric Thanks for doing that investigation. I opened up bug 2156 for this. <http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2156> -Andy
Galen and I discussed the blocker, major, critical issues and concluded we could address them with a concerted effort before Monday, June 16th. I'd like to set that as the date for releasing 3.0-stableRC1, then do a string freeze, to allow translators to wrap up any changes to translations, and then a final 3.0-stable on July 1.
I'm excited to hear a date for the release. I'm as impatient as anyone, and I've got still got bugs in /my/ queue! There are still a lot of bugs in Bugzilla to be fixed, and I don't take the announcement of a release date as indication that these bugs can be left unfixed. I think everyone has done a lot of hard work and it really shows: I think the delay we've seen for this release is going to be worth it to all our libraries for the better product they'll get. We still need a final push to get the bug list pared down. We don't want to release a buggy 3.0. We've come too far for that. Let's see some Bugzilla action! -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
1. BUG SEVERITY SIGNIFICANTLY UNDER-REPORTED. The severity of many currently reported bugs has been significantly under-reported. If the practical effect of many bugs marked as normal would be considered, they would be found to be blocking or critical for the part of Koha to which they relate. Koha might be modestly usable without those parts, if that was the standard for not considering a bug blocking. but we should not be conceiving of Koha as merely a modestly usable ILS. By the evidence, most people never bothered to carefully consider the severity of a bug by a functionally useful standard if they bothered to consider changing the default severity at all. The important thing was and is filing the bug at all. Most people might have also presumed that every bug would be evaluated after being reported and that those with the worst effects would be fixed. irrespective of the severity listed. before 3.0 was released as stable. I examined the bug list a few days ago. I did not think I should take it upon myself to change the severity of bugs which I did not report myself without discussing the issue on the mailing list. If I would make appropriate changes to currently reported bugs with my knowledge of the practical effect of many bugs, I would double the number of critical and blocking bugs when adhering to a rather cautious use of those severity levels. 2. STANDARDS OF BUG SEVERITY. For the benefit of those who were not present or do not remember, Joshua Ferraro offered a standard for bug severity on the #koha IRC channel in which almost any bug which was noticed by the librarian would be perceived as critical. Koha has mostly been adopted by libraries which have been somewhat tolerant of bugs or do not recognise bugs which ought to be fairly obvious. The standard which I applied when considering that re-evaluating the severity of reported bugs would double the number of critical and blocking bugs is a much more relaxed standard. By the standard given by Joshua, even the most trivial OPAC bug would be a critical bug. "01/09/06 03:06:53+-5 [kados:#koha] I notice that US companies place more importance on a web presense than French, so perhaps this is part of the difference 01/09/06 03:07:10+-5 [kados:#koha] to a US organization, a website is a core part of the organization 01/09/06 03:07:25+-5 [kados:#koha] and if something on the website seems silly, people perceive the organization to be silly 01/09/06 03:08:12+-5 [kados:#koha] I agree it's not a blocker 01/09/06 03:08:34+-5 [kados:#koha] but it is still critical (the fact that I received two separate bug reports in minutes about this proves it)" 3. APPLICATION TO VERSION RELEASES. The problem here is that libraries are concerned about either how they are perceived through the software they use or suspicious of deeper problems in software when even superficial bugs are noticeable. In either case, libraries may run in the opposite direction if they do not already have a commitment to Koha. While Koha 3.0 has a much better underlying foundation than 2.2, that foundation is not what the user sees and the foundation will not be appreciated when so many bugs are noticeable. Looking carefully in the way librarians ought to when evaluating an ILS choice, perhaps three times as many bugs could be reported as have been now. I have avoided reporting bugs which I thought would either necessarily be fixed as the particular part of the software became more developed or would have too low a priority for being fixed unless I fixed them myself. (Sadly, I did not have the time to fix for a second time the few OPAC bugs which I had originally fixed around the time of Koha 2.2.3-5 but which reappeared a version or two later. At least now LibLime has someone, Nicole Engard, who has recognised and reported some of them.) I presume that it may be acceptable for Koha 3.0 to have a much lower standard for what counts as a stable release than 3.1-. If the standard for 3.0 is much lower than for 3.1-, then 3.0 may be suitable for libraries which have essentially already decided to commit to Koha. 3.1- could still be attractive to libraries at large when a much larger number of bugs would be fixed, including many bugs which are trivially easy to spot but have not yet been reported. It would be most unfortunate if too many libraries looked at 3.0 and formed an adverse judgement which left them disinclined to give due consideration to 3.1. Unless there are some contractual needs for developers offering support services to have a stable 3.0 release at a much lower standard than 3.1-, I suggest a series of 3.0 release candidates with a more rigorous effort at reporting additional bugs and reporting their severity. Many of the readily noticeable unreported bugs with which I am familiar are easy to fix but merely giving enough attention to fix them necessarily takes time. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Wed, May 21, 2008 1:22 pm, Joshua Ferraro wrote:
Hi folks,
I've done an audit of the outstanding bugs in Bugzilla and have found 39 are marked as blocker, major, or critical:
There are an additional 157 marked 'normal':
Galen and I discussed the blocker, major, critical issues and concluded we could address them with a concerted effort before Monday, June 16th. I'd like to set that as the date for releasing 3.0-stableRC1, then do a string freeze, to allow translators to wrap up any changes to translations, and then a final 3.0-stable on July 1.
I do request that those of you using and programming Koha take a look at the outstanding bugs in both categories, and flesh out any issues in more detail where you can -- and if you feel a bug in the 'normal' category should be prioritized, please speak out.
Thanks to everyone who's contributed, even in small ways, to the major improvements to this new version of Koha.
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
"Thomas Dukleth" <kohadevel@agogme.com> wrote:
2. STANDARDS OF BUG SEVERITY.
For the benefit of those who were not present or do not remember, Joshua Ferraro offered a standard for bug severity on the #koha IRC channel in which almost any bug which was noticed by the librarian would be perceived as critical. [...]
I support our current descriptions, which you can find at http://bugs.koha.org/cgi-bin/bugzilla/page.cgi?id=fields.html#bug_severity Blocker Blocks development and/or testing work Critical crashes, loss of data, severe memory leak Major major loss of function Minor minor loss of function, or other problem where easy workaround is present Trivial cosmetic problem like misspelled words or misaligned text Enhancement Request for enhancement I'd suggest that the "librarian noticability" aspect would be better represented by the bug's Component and possibly the Priority.
3. APPLICATION TO VERSION RELEASES.
The problem here is that libraries are concerned about either how they are perceived through the software they use or suspicious of deeper problems in software when even superficial bugs are noticeable. [...]
To allay that suspicion, we should be clear in our release notes that what should be our full list of known bugs is public and available. Hope that helps, -- 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Reply inline: On Wed, June 4, 2008 1:33 pm, MJ Ray wrote:
"Thomas Dukleth" <kohadevel@agogme.com> wrote:
2. STANDARDS OF BUG SEVERITY.
[..]
I support our current descriptions, which you can find at http://bugs.koha.org/cgi-bin/bugzilla/page.cgi?id=fields.html#bug_severity
Blocker Blocks development and/or testing work Critical crashes, loss of data, severe memory leak Major major loss of function Minor minor loss of function, or other problem where easy workaround is present Trivial cosmetic problem like misspelled words or misaligned text Enhancement Request for enhancement
This definition seems very reasonable and I was not aware that it was there. By this definition, I would have to include major in my statement about how appropriately reassigning the severity of reported bugs would double the bugs which are at least major. Yet, after exploring a few issues for bugs which I had not tested myself, it seems that some reported bugs which would be at least major seem to have been fixed but not marked as fixed. If more bugs have been fixed but not reported as fixed the overall problem may be much less serious than I had supposed.
I'd suggest that the "librarian noticability" aspect would be better represented by the bug's Component and possibly the Priority.
I have never known what to do with selecting priority in bug tracking systems so I have usually left it at the default value. A specification for what priority values mean as has already been provided for severity would be helpful. Some higher level of priority should be designated as applicable to even trivial bugs which may lead librarians to not give sufficient consideration to adopting Koha. Some trivial bugs could then appropriately have priority over normal bugs which might not be especially noticeable.
3. APPLICATION TO VERSION RELEASES.
The problem here is that libraries are concerned about either how they are perceived through the software they use or suspicious of deeper problems in software when even superficial bugs are noticeable. [...]
To allay that suspicion, we should be clear in our release notes that what should be our full list of known bugs is public and available.
I agree that reference to a public bug tracking system should be used to reduce concerns. Public bug tracking is a benefit of free software as opposed to the common proprietary practise. where bugs are a secret and sometimes denied even when obvious and especially when severe. We should be honest about bugs without going out of our way to advertise them so as not to seem adverse to comparable proprietary software where bugs are not disclosed. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Oops, I meant Koha 3.0.1 where I wrote 3.1 in my previous message. The corrected message follows. 1. BUG SEVERITY SIGNIFICANTLY UNDER-REPORTED. The severity of many currently reported bugs has been significantly under-reported. If the practical effect of many bugs marked as normal would be considered, they would be found to be blocking or critical for the part of Koha to which they relate. Koha might be modestly usable without those parts, if that was the standard for not considering a bug blocking. but we should not be conceiving of Koha as merely a modestly usable ILS. By the evidence, most people never bothered to carefully consider the severity of a bug by a functionally useful standard if they bothered to consider changing the default severity at all. The important thing was and is filing the bug at all. Most people might have also presumed that every bug would be evaluated after being reported and that those with the worst effects would be fixed. irrespective of the severity listed. before 3.0 was released as stable. I examined the bug list a few days ago. I did not think I should take it upon myself to change the severity of bugs which I did not report myself without discussing the issue on the mailing list. If I would make appropriate changes to currently reported bugs with my knowledge of the practical effect of many bugs, I would double the number of critical and blocking bugs when adhering to a rather cautious use of those severity levels. 2. STANDARDS OF BUG SEVERITY. For the benefit of those who were not present or do not remember, Joshua Ferraro offered a standard for bug severity on the #koha IRC channel in which almost any bug which was noticed by the librarian would be perceived as critical. Koha has mostly been adopted by libraries which have been somewhat tolerant of bugs or do not recognise bugs which ought to be fairly obvious. The standard which I applied when considering that re-evaluating the severity of reported bugs would double the number of critical and blocking bugs is a much more relaxed standard. By the standard given by Joshua, even the most trivial OPAC bug would be a critical bug. "01/09/06 03:06:53+-5 [kados:#koha] I notice that US companies place more importance on a web presense than French, so perhaps this is part of the difference 01/09/06 03:07:10+-5 [kados:#koha] to a US organization, a website is a core part of the organization 01/09/06 03:07:25+-5 [kados:#koha] and if something on the website seems silly, people perceive the organization to be silly 01/09/06 03:08:12+-5 [kados:#koha] I agree it's not a blocker 01/09/06 03:08:34+-5 [kados:#koha] but it is still critical (the fact that I received two separate bug reports in minutes about this proves it)" 3. APPLICATION TO VERSION RELEASES. The problem here is that libraries are concerned about either how they are perceived through the software they use or suspicious of deeper problems in software when even superficial bugs are noticeable. In either case, libraries may run in the opposite direction if they do not already have a commitment to Koha. While Koha 3.0 has a much better underlying foundation than 2.2, that foundation is not what the user sees and the foundation will not be appreciated when so many bugs are noticeable. Looking carefully in the way librarians ought to when evaluating an ILS choice, perhaps three times as many bugs could be reported as have been now. I have avoided reporting bugs which I thought would either necessarily be fixed as the particular part of the software became more developed or would have too low a priority for being fixed unless I fixed them myself. (Sadly, I did not have the time to fix for a second time the few OPAC bugs which I had originally fixed around the time of Koha 2.2.3-5 but which reappeared a version or two later. At least now LibLime has someone, Nicole Engard, who has recognised and reported some of them.) I presume that it may be acceptable for Koha 3.0 to have a much lower standard for what counts as a stable release than 3.0.1-. If the standard for 3.0 is much lower than for 3.0.1-, then 3.0 may be suitable for libraries which have essentially already decided to commit to Koha. 3.0.1- could still be attractive to libraries at large when a much larger number of bugs would be fixed, including many bugs which are trivially easy to spot but have not yet been reported. It would be most unfortunate if too many libraries looked at 3.0 and formed an adverse judgement which left them disinclined to give due consideration to 3.0.1. Unless there are some contractual needs for developers offering support services to have a stable 3.0 release at a much lower standard than 3.0.1-, I suggest a series of 3.0 release candidates with a more rigorous effort at reporting additional bugs and reporting their severity. Many of the readily noticeable unreported bugs with which I am familiar are easy to fix but merely giving enough attention to fix them necessarily takes time. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Wed, May 21, 2008 1:22 pm, Joshua Ferraro wrote:
Hi folks,
I've done an audit of the outstanding bugs in Bugzilla and have found 39 are marked as blocker, major, or critical:
There are an additional 157 marked 'normal':
Galen and I discussed the blocker, major, critical issues and concluded we could address them with a concerted effort before Monday, June 16th. I'd like to set that as the date for releasing 3.0-stableRC1, then do a string freeze, to allow translators to wrap up any changes to translations, and then a final 3.0-stable on July 1.
I do request that those of you using and programming Koha take a look at the outstanding bugs in both categories, and flesh out any issues in more detail where you can -- and if you feel a bug in the 'normal' category should be prioritized, please speak out.
Thanks to everyone who's contributed, even in small ways, to the major improvements to this new version of Koha.
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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
I have avoided reporting bugs which I thought would either necessarily be fixed as the particular part of the software became more developed or would have too low a priority for being fixed unless I fixed them myself.
I agree that bugs are underreported, so I encourage everyone to report early and often. It's impossible to know what bugs the developers already know about and are planning to fix. Even if a bug is known to a developer, it's important to have a bug report so that others can be aware of it--or even so others can step in and fix it! I might see a problem and think, "Oh I'll fix that later," and not file a bug report. If I do file the report, not only will someone see that the bug has been acknowledged, someone else might even fix it! :)
I presume that it may be acceptable for Koha 3.0 to have a much lower standard for what counts as a stable release than 3.0.1
I certainly hope that's not the prevailing attitude. Although I have to say, I haven't seen much bug fixing since the release date announcement... -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Owen Leonard a écrit :
I certainly hope that's not the prevailing attitude. Although I have to say, I haven't seen much bug fixing since the release date announcement...
mmm... what I see is a lot of bugfixing for bugs, but that are not on bugs.koha.org I have submitted something like 15 bugfixes last months, none of them being from bugs.koha.org (we use suivi.biblibre.com, our own BibLibre internal bug tracking systèm) What is annoying me is that the 12 bugzilla blockers don't have been solved. I have looked at them, and find they are very very hard to deal with. The only one affected to me is being dealed by hdl atm. galen & others, could you tell us where you are with those blockers ? (I think some of them are solved now) -- 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
Hi to all, I'm using Unimarc as Marc system. The leader field (field 000) is shipped without a plugin. I think it is impossible to insert data without a plugin for the Leader field. So in the zip attach there is the plugin written by me (starting ftom marc21 authority leader plugin). The file 'unimarc_leader_authorities.tmpl' into ../koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder dir the file marc21_leader_authorities.pl into ../caloguing/value_builder dir There is also a modification into ../installer/data/mysql/en/marcflavour/unimarc/mandatory/authorities_normal_unimarc.sql From INSERT INTO `auth_subfield_structure` (`authtypecode`, `tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `tab`, `authorised_value`, `value_builder`, `seealso`, `isurl`, `hidden`, `linkid`, `kohafield`, `frameworkcode`) VALUES ('', '000', '@', 'fixed length control field', 'fixed length control field', 0, 1, 0, NULL, NULL, NULL, 0, 0, '', '', ''), To INSERT INTO `auth_subfield_structure` (`authtypecode`, `tagfield`, `tagsubfield`, `liblibrarian`, `libopac`, `repeatable`, `mandatory`, `tab`, `authorised_value`, `value_builder`, `seealso`, `isurl`, `hidden`, `linkid`, `kohafield`, `frameworkcode`) VALUES ('', '000', '@', 'fixed length control field', 'fixed length control field', 0, 1, 0, NULL, 'unimarc_leader_authorities.pl', NULL, 0, 0, '', '', ''), In the table 'auth_subfield_structure' with the tag field '00' and the tagsubfield '@' you need to insert the value 'unimarc_leader_authorities.pl' in the coloum 'value_builder' 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
Reply inline: On Wed, June 4, 2008 3:12 pm, Paul POULAIN wrote: [..]
mmm... what I see is a lot of bugfixing for bugs, but that are not on bugs.koha.org
I have submitted something like 15 bugfixes last months, none of them being from bugs.koha.org (we use suivi.biblibre.com, our own BibLibre internal bug tracking systèm)
I think that most bugs are fixed without being reported to any bug tracking system for Koha. Fixing bugs without reporting them should be fine. However, not having time to fix a bug, even a trivial one, and then also not taking the time to even minimally report it anywhere is a bad practise of which I have been especially guilty.
What is annoying me is that the 12 bugzilla blockers don't have been solved. I have looked at them, and find they are very very hard to deal with. The only one affected to me is being dealed by hdl atm.
galen & others, could you tell us where you are with those blockers ? (I think some of them are solved now)
I do not know about those blockers but some bugs which have been reported as normal but would be major seem to no longer be reporducable. I hope there are more which could already be changed to fixed but have not been reported as fixed yet. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi folks, Well, here we are: Monday June 16th. Based on the feedback to my last post announcing a proposed release date I've decided to hold off for a week and aim for Friday the 20th as the RC1 / string freeze date. I'm still hopeful that we'll have the final release ready for July 1st. In terms of statistics, we're down to 35 bugs marked blocker, major or critical (down from 39 on May 21): http://tinyurl.com/5hysmf There are now 159 marked 'normal' (up from 157 on May 21): http://tinyurl.com/3lmp67 So in summary, we had a lot of new bugs added, and fixed, so though there has been activity, it doesn't look like it on paper :-). The entire LibLime development team will be working exclusively on bugfixing this week and I'm hopeful we'll be in a position to release on Friday. Feel free to join the effort, we'll be on IRC all week! Thanks again to all the contributors to this release. 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Hi folks, Just a quick update on progress of the 3.0-stableRC1 release. The programming team patched over 50 bugs today, so kudos to everyone! I began the process of updating translations and have updated all but the following: el-GR-i-staff-t-prog-v-3000000.po es-ES-i-staff-t-prog-v-3000000.po hy-Armn-i-staff-prog-v-3000000.po ru-RU-i-staff-t-prog-v-3000000.po tr-TR-i-staff-t-prog-v-3000000.po uk-UA-i-staff-t-prog-v-3000000.po zh-Hans-CN-i-staff-t-prog-v-3000000.po These have a lot of invalid characters and incorrect syntax, and I'm afraid it will take me a bit of time to weed through those ... but I hope to have them ready by this weekend, and as soon as they update with no errors I'll push everything up to http://translate.koha.org, declare the 'string freeze', and release RC1 ... Until that time, please don't submit any changes to translate.koha.org as those changes will be lost. I'll keep you all posted as to the progress. 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (9)
-
Andrew Moore -
Frederic Demians -
Joshua Ferraro -
MJ Ray -
Nicole Engard -
Owen Leonard -
Paul POULAIN -
Thomas Dukleth -
Zeno Tajoli