headers
Paul Poulain | 10 Feb 17:50
Gravatar

Automatic detection of "does not apply" patch

Hello,

I wrote a small script that automatically retrieve all patches that
"Needs signoff" and try to apply them on master. If it's not possible,
the script can also update the status on the bug.

I'll push the script on misc/devel/ directory (that will be created)

I was wondering what to do with this script. The script can be run
regularly, and automatically change the status of the bug, adding a
comment saying "The script misc/devel/testbugzillapatches.pl has
detected that this patch does not apply anymore:" with the git error
message.

I ran the script, with the update of bugzilla commented, and can already
say the following patches don't apply:
3571, 4032, 5166, 5786, 5787, 5788, 5877, 5911, 6296, 6334,
 6504, 7411, 7430
(13 patches on 77 waiting for being signed-off)

My proposition is:
* to push this patch into Koha, to let everybody know how it works
* run it myself regularly, something like every friday. In some
weeks/months, once i'm sure there are no hidden problems with the
script, run it cronly, from jenkins

PS: I also could easily check for signed off patches, just in case some
of them don't apply anymore before being QAed

PS2: the only problem i've found is when a patch depends on another one.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Poulain | 10 Feb 12:24
Gravatar

[Discussion tech] Generalise the use Template Toolkit plugins

I've started another discussion page:
http://wiki.koha-community.org/wiki/Generalise_the_use_Template_Toolkit_plugins

Chris_c recently has added a plugin to manage the display of dates into
Koha (see
http://wiki.koha-community.org/wiki/Coding_Guidelines#Displaying_dates),
that is very interesting.

Do we want to generalise this mechanism ? When do we want to use it ?

For example, the patch for bug
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4078 could
nicely use this mechanism

let's start the discussion !
(reading the page and the possible solutions, you'll see I made 2, but
am not happy with them. Probably need others ideas...)
--

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Poulain | 10 Feb 11:44
Gravatar

[Discussion tech] database table naming

Continuing with open discussion for the future of Koha:

On the page http://wiki.koha-community.org/wiki/DB_schema_bugs, we have
referenced some inconsistencies on the database.
One of them is about table naming : acquisition related tables all start
by aq, other tables don't have any prefix.

OTOH, Julian has submitted a bug
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5339 that adds
an "invoice" table, related to acquisitions, but don't has a aq prefix.

The possible options are on
http://wiki.koha-community.org/wiki/Table_naming, let's start the
discussion !
--

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Permalink | Reply | 1 comment |
headers
Paul Poulain | 10 Feb 10:41
Gravatar

IRC meeting decision about "discussion"

Hi all,
(Koha general mailing list reader: this mail is also for you, please
read it's an opportunity to participate to Koha, even if you don't have
technical skills !)

Tomas was faster than me to start a discussion, I planned to send a mail
about the results of our discussion during the last IRC session.

The question was : "how to deal with patches that are 'in discussion'".
I made a proposal, that has been a little bit amended during the
discussion, here is the final result:

* when a patch is rejected or is conflicting with another one (not a
technical conflict, but a "strategic" conflict), the bug status can be
set to "In Discussion"
* Someone (I volunteered to do it, but feel free to do it yourself if
you're concerned=
  - start a wiki page with describing the problem
  - send a mail to koha-devel and koha pointing to the wiki page, and
calling for comments.
* the delay for discussion is "until next IRC meeting, not less than 1 week"
* at the next IRC meeting,
 - if the discussion (on the wiki or koha-devel) result in a general
agreement, nothing specific need to be made (no vote needed)
  - if the discussion result in a balanced situation, organize a vote.

About the vote (this has not been discussed on last IRC meeting,
thinking of it and proposing it now): as some of us are always sleeping
during IRC meetings, it's unfair to vote only on the IRC channel during
the meeting. I propose that ppl could also express their preference/vote
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul | 8 Feb 20:37
Favicon

"Damaged" values

In our "Authorized values" > "Damaged", we have added a term "Normal wear" 
to the Koha defaults 0, 1 and 2:

0       Not damaged     Not damaged
1       Damaged         Some damage noted
2       Unknown         Condition not stated
3       Normal wear     Normal wear

However, in both staff interface and OPAC, "normal wear" items are 
appearing as damaged

I assume (maybe incorrectly) that the value of "damaged" is read by 
detail.pl starting line 196:

     if ($item->{damaged}) {
         $item->{itemdamagedloop} = 
GetAuthorisedValues($authvalcode_items_damaged, $item->{damaged}) if 
$authvalcode_items_damaged;
     }

and then passed to detail.tt start line 310:

         [% IF ( itemloo.damaged ) %]
                 [% IF ( itemloo.itemdamagedloop ) %]
                         [% FOREACH itemdamagedloo IN 
itemloo.itemdamagedloop %]
                         [% IF ( itemdamagedloo.selected ) %]
                                                         <span 
class="dmg">[% itemdamagedloo.lib %]</span>
                         [% END %]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tomas Cohen Arazi | 8 Feb 16:42
Picon

[Discussion Tech] Cache handling in koha

Hi, I'm just starting a thread to discuss this topic so we make some
decisions and we can continue improving Koha in this aspect. As far as
I can remember there are a few issues with this:

1) The use of ENV vs. koha-conf.xml vs. DB/systempreferences to store
memcached configuration.

I introduced the use of ENV (from Apache vhost definition) for storing
memcached servers configuration data on Bug 6193. This was done for
being able to cache the koha-conf.xml configuration variables (prior
to that, memcached info was saved in koha-conf.xml itself and thus
not-cacheable). When coding that I realized that memcached was being
initialized everywhere we needed it. And namespaces where not always
consistent (KOHA and koha alternatively, this might not be a problem
if this happens to be case insensitive, anyway, it looked bad to me).

I then exported the object memcached and the ismemcached variable in
C4::Context. This first patch (koha-conf.xml in memcache, and
memcached object available for every other lib that includes
C4::Context) has been pushed.

Then there's a second patch, that removes several memcached
configuration validation and  initialization code from the rest of the
libs, and reuses that variables from C4::Context. I tested it to work
flawlessly, but things around it halted when other proposals raised.

I like mi approach. I like how the resulting code looked, I wont hide
it. But I don't need it to be accepted at all, maybe the other
proposals are far better. The only thing I missed on this cache thing
was more feedback.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Paul Poulain | 7 Feb 18:27
Gravatar

"in discussion" bugs, proposed workflow

Hello all,

i've added to the IRC agenda some details about the "in discussion"
bugs. We must setup a workflow to be sure there is a discussion and we
exit from this discussion in a given time, with a clear decision.
You can find a proposition for a workflow on the IRC agenda wiki page
and i'd like to discuss of this workflow during the IRC.
Look at :
http://wiki.koha-community.org/wiki/General_IRC_Meeting,_8_February_2012#Agenda
for more details.

I plan to be at the meeting, but it's 3AM for me, so apologize if I
shoot my radio when she awake me ;-)

--

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Permalink | Reply | 0 comments |
headers
Magnus Enger | 7 Feb 10:44
Picon
Gravatar

2012-02-08 Global bug squashing day #9 - you can help!

Dear Community,

In just 15 minutes, it's that time again (at least in Kiribati):
http://wiki.koha-community.org/wiki/2012-02-08_Global_bug_squashing_day

Just as an example of work that needs to be done, there are currently
89 bugs that need signing off - that's too many!

And to put things in perspective, on 2012-02-08 it's just 2 months and
2 weeks until 2012-04-22 is upon us! (If you're wondering why that is
significant, it's the date dictated by tradition for the next version
of Koha - 3.8. (The actual date is of course dictated by Paul P. ;-))

Happy hunting, folks!
Magnus
_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Permalink | Reply | 0 comments |
headers
Paul Poulain | 6 Feb 22:23
Gravatar

Call for help, testing sandboxes system

Hello koha-devel,

In my Release Manager Application, there was something about setting
sandbox testing servers.
I wrote some scripts to deal with this system.
With them, you can easily test patches. I think the system is ready to
be deployed and announced widely.
But before doing that, i'd like to have some feedback from a small group
like users of this list.
So my request is:
* got to the wiki page http://wiki.koha-community.org/wiki/Sandboxes, it
should be self-explanatory, otherwise I must improve the page and please
report it here
* test some patches to see if everything is working well

2 more informations:
* the MARC21 sample database is really a tiny one. If someone has a
bigger one, he's welcomed to send it to me, i'll update the sandbox
* only test1 (unimarc) and test5 (marc21) are deployed for instance.
Don't try to user other testX server, it won't work.

Thanks for the time you'll dedicate on this task, it really hope this
system will be usefull to lower the number of patches needing signoff by
lowering the technical level needed to test it.
--

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul | 4 Feb 19:17
Favicon

Bug 5677

Not sure if it's possible to re-open a "resolved" bug (or even if mine is 
germane) having just looked at 
<http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5677>.

We have some items that are showing up as "lost" despite having a correct 
"library" and "shelf location". e.g.: from OPAC: "Books NMA box_rr169 
Reference REFE-UNKN-57

(<http://koha/cgi-bin/koha/opac-detail.pl?biblionumber=12812&shelfbrowse_itemnumber=12807#shelfbrowser>Browse 
Shelf) Item lost" -- it's a book at the NMA, in box_rr169, [call# correct], 
LOST.

In the staff interface (same "lost" labeling), editing "item", the "lost 
status" is given as 5 but our "authorized values" are default and 5 does 
not exist.

I have edited the framework to attempt to be able to edit/modify this 
(952$1), but the drop down box "1 - Lost status" only appears for *new* 
items, and while the line is there, there is no dropdown to edit existing 
records.

Bug 5677 suggests that it was an OPAC problem, not showing in the staff 
interface -- whereas mine is showing in both.

Can anyone assist me, please?

As background, we are not a lending library, have no "patrons" in the Koha 
sense, and have never even tried to declare an item as "lost" which if I 
understand correctly is a management tool for unreturned books.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Scott Kushner | 3 Feb 22:37

Translating a template file.

I want to translate one .tmpl to template toolkit .tt file.

 

Does anyone know the command for this? I have a git install.

 

Do not have /koha/tt dir….

 

Just want to translate the one template file.

 

Thanks,

 

Scott Kushner

Systems Librarian

Middletown Public Library

55 New Monmouth Rd

Middletown, NJ 07748

 

_______________________________________________
Koha-devel mailing list
Koha-devel@...
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
Permalink | Reply | 1 comment |

Gmane