Hello world, I see a change in the wiki : " Contributors to Koha are encouraged to reference a bug number with every commit. This helps us determine the purpose of the commit and establishes a more searchable and understandable history. If there is no bug open at [[http://bugs.koha.org|bugs.koha.org]] that addresses your contribution, please feel free to open one and describe the bug or enhancement. Then, include the bug number in your commit message and set the "priority" field to "patch-sent". This helps us keep track of patches that have been contributed but not yet applied. " I fully agree with the idea of pointing the bug if there is one. But I strongly disagree about adding a bug if there is none. For at least 2 reasons : - it is an obviously "long" process to add a bug. If we have found a small & quickly fixed bug, then there is no need to add a bug imo. Having a complete patch comment is necessary for the ppl reviewing/validating the patch. But the need of a bug.koha.org is unclear to me (the PATCH-sent thing is not enough imo) - we (BibLibre) have a specific internal (& french) tool for our customer requests. When we fix a bug discovered by a client, frankly, it's a loss of time to translate it to english & rewrite it to bugs.koha.org Comments welcomed. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
Comments welcomed
It's a good rule because it helps RM to validate, test and apply patches. But not only. There is another advantage: it helps identifying already submitted bugs and comments/solution. It avoid investigating bugs already solved. I have an example... Yesterday, someone on koha-fr list pointed out that it wasn't possible to record overdue actions rules in Notices Triggers. I had the same bug. So I submitted it: http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2416 Finally it appears that Ryan Higgins (thanks) already had solved this bugs but he didn't file a bug. If he had, I would have find it with a search like that: http://tinyurl.com/69vcr5 and wouldn't have spend time trying to figure out what was wrong. So a waste of time for Ryan, indeed, a gain for me and potentially for others. For me, Koha Bugzilla is the right place, unique and central place, to submit bugs and enhancement demands. This way, you don't have to search elsewhere: git, lists, local bugs tracker, etc. -- Frédéric
Hi On Wed, Jul 30, 2008 at 7:03 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
For at least 2 reasons : - it is an obviously "long" process to add a bug. If we have found a small & quickly fixed bug, then there is no need to add a bug imo.
Small bug = quick description, therefore less time to enter a bug. :) For things like typo corrections, we don't necessarily need to file a new bug for each one, but even just having a standing typo bug would be useful: translators could watch for that bug number.
Having a complete patch comment is necessary for the ppl reviewing/validating the patch. But the need of a bug.koha.org is unclear to me (the PATCH-sent thing is not enough imo)
Sometimes a patch description isn't enough - for a complex bug that has taken a lot of time and conversation to isolate, having the full history of the bug be available would be immensely useful.
- we (BibLibre) have a specific internal (& french) tool for our customer requests. When we fix a bug discovered by a client, frankly, it's a loss of time to translate it to english & rewrite it to bugs.koha.org
But we don't get the benefit of your wisdom if the bug description and history is locked away in your internal bugs database. :) LibLime also has an internal bugs database, but that's mostly for truly internal stuff; for anything that we submit patches for, we have a goal of making sure that a good bug description is entered in the public Bugzilla. I recognize that you have pressures on your time. I don't think you necessarily need to spend time translating your bug descriptions by hand; quick machine translations would be sufficient. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
Galen Charlton a écrit :
But we don't get the benefit of your wisdom if the bug description and history is locked away in your internal bugs database. :) LibLime also has an internal bugs database, but that's mostly for truly internal stuff;
We too. But you must know that sometimes a customer request is caused by a bug. In this case, it's easier for us to fix it directly than create a bug in bugzilla to immediatly close it.
for anything that we submit patches for, we have a goal of making sure that a good bug description is entered in the public Bugzilla.
Everybody is against me it seems, so I think i'll accept & change my mind... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
Andrew Moore a écrit :
On Wed, Jul 30, 2008 at 8:32 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
Everybody is against me it seems, so I think i'll accept & change my mind...
I apologize, Paul. I was specifically trying to avoid having you feel that way. You will see that our mails have reached the mailbox at the same time. looking at it & answering now ;-)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
On Wed, Jul 30, 2008 at 7:03 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
I fully agree with the idea of pointing the bug if there is one. But I strongly disagree about adding a bug if there is none.
Hi Paul - Thanks for the feedback. I'm glad you're on board with putting bug numbers in the git commit message when relevant. I think that really helps me out, too. I wrote that there after a brief discussion with some other contributors. I intentionally attempted to word it so that it was clearly not a requirement, but just something that may make it easier for other contributors and the Release Manager. If it's not something you're interested in doing, I don't think that will be a problem at all. I understand that sometimes it seems like unnecessary work to report a bug for a one line patch. I don't think our views are too far apart. Please allow me to see if I can bring them a little closer, though:
For at least 2 reasons : - it is an obviously "long" process to add a bug. If we have found a small & quickly fixed bug, then there is no need to add a bug imo. Having a complete patch comment is necessary for the ppl reviewing/validating the patch. But the need of a bug.koha.org is unclear to me (the PATCH-sent thing is not enough imo)
It does sometimes seem like a long process, especially compared to a small patch. Could we make it easier by making bugzilla accept entries via email? <http://wiki.mozilla.org/Bugzilla:FAQ:Bugzilla_Email#How_do_I_set_up_the_email_interface_to_submit.2Fchange_bugs_via_email.3F> About small and quickly fixed bugs, sometimes what seems simple at first turns into two or three patches to get it right. I'm notoriously bad at this. Having a bug to tie them together may help others. Maybe this isn't enough to justify the cost of opening a bug for each one, though.
- we (BibLibre) have a specific internal (& french) tool for our customer requests. When we fix a bug discovered by a client, frankly, it's a loss of time to translate it to english & rewrite it to bugs.koha.org
I'd like to encourage you to submit any of those bugs that are appropriate to bugs.koha.org. I understand that feature requests or contracted development from your clients may be completely inappropriate for bugs.koha.org. That's no problem. But, in the event of a bug that will not reveal usage or client information, having that information in bugs.koha.org may help users realize that they're seeing the same behavior that others are and that a fix may be on the way. It helps the other contributors know how many outstanding bugs we have reported against our product at any time. It may also help me stop writing so many bugs. I may even be fixing one of yours right now! Paul, I know that I'm not going to completely convince you to do this all the time. In fact, I personally probably won't do it all the time. But, I'll encourage you and others to do it when it makes sense. If you'd like for me to make another page on the wiki for "coding suggestions" or something like that, I understand. By the way, my suggestion to write a git hook to enforce this policy was shot down, and understandably so! Thanks, -Andy
Andrew Moore a écrit :
For at least 2 reasons : - it is an obviously "long" process to add a bug. If we have found a small & quickly fixed bug, then there is no need to add a bug imo. Having a complete patch comment is necessary for the ppl reviewing/validating the patch. But the need of a bug.koha.org is unclear to me (the PATCH-sent thing is not enough imo)
It does sometimes seem like a long process, especially compared to a small patch. Could we make it easier by making bugzilla accept entries via email? <http://wiki.mozilla.org/Bugzilla:FAQ:Bugzilla_Email#How_do_I_set_up_the_email_interface_to_submit.2Fchange_bugs_via_email.3F>
mmm... maybe a good way to do so.
About small and quickly fixed bugs, sometimes what seems simple at first turns into two or three patches to get it right. I'm notoriously bad at this. Having a bug to tie them together may help others. Maybe this isn't enough to justify the cost of opening a bug for each one, though.
That's just what I wanted to point in fact : in the case of a small & evident bug, I don't think it's usefull to write a bug.koha.org for non immediate solution bugs, though, it's interesting. Also note that more often our customer questions are a mix of "bug", "feature request", "poor use of Koha", and "bad use of the result they get" So, it's hard (impossible) to translate & throw the request "as is".
I'd like to encourage you to submit any of those bugs that are appropriate to bugs.koha.org.
Of course, when it is relevant, i'll take time to do it (although I didn't previously) Our positions are not that far then. I was just afraid to have this rule too hardly added to our patch policy. For anyone else involvement, it can also be a problem : i've found a small bug in Koha, I know the solution. I must : - get git & know how to use it - create an account on bugzilla - file a bug for that - create & send my patch for a single patch, too much imo. I wouldn't do that for a project I don't plan to be involved to. So let say "it's better to", and not "you must do" -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc NOUVEAU TELEPHONE : 04 91 81 35 08
Hi Paul - On Wed, Jul 30, 2008 at 8:54 AM, Paul POULAIN <paul.poulain@free.fr> wrote:
It does sometimes seem like a long process, especially compared to a small patch. Could we make it easier by making bugzilla accept entries via email?
mmm... maybe a good way to do so.
I'll follow up on this a bit.
So let say "it's better to", and not "you must do"
I agree. If it is too strongly worded on the wiki, please feel free to edit it. Thanks, Paul! -Andy
Paul POULAIN <paul.poulain@free.fr> wrote:
I see a change in the wiki : [...]
Yeah, please can people discuss such policy changes on -devel first? Or at least tell us. I read http://owu.towers.org.uk/planets/koha/ most days, but not everyone does. What's the point of changing policy silently? It's not going to change how we work and you'll get deservedly flamed if you try to slap us for breaking a secret policy.
I fully agree with the idea of pointing the bug if there is one. But I strongly disagree about adding a bug if there is none. For at least 2 reasons : - it is an obviously "long" process to add a bug. If we have found a small & quickly fixed bug, then there is no need to add a bug imo. Having a complete patch comment is necessary for the ppl reviewing/validating the patch. But the need of a bug.koha.org is unclear to me (the PATCH-sent thing is not enough imo) - we (BibLibre) have a specific internal (& french) tool for our customer requests. When we fix a bug discovered by a client, frankly, it's a loss of time to translate it to english & rewrite it to bugs.koha.org
I think there SHOULD be a bug for every patch. However, there should be some tool trying to update bugs automatically on patch-mail and head commit (maybe from /bug\s+(\d+)/ on the commit message). TTLLP also has an internal work tracker (RT), but we can link from the "Refers to" field to bugs.koha.org - I'm trying to be better at doing that for all our koha bugs as soon as we're reasonably confident it's not a local configuration error. The flames from LibLimeys if I patch a bug they've not experienced yet are *not* encouraging this (TMPL_ELSIF MacOS X 10.5 unpredictability/unportability most recently) so I can understand why BibLibre feel it's too expensive. "Galen Charlton" <galen.charlton@liblime.com> wrote:
I recognize that you have pressures on your time. I don't think you necessarily need to spend time translating your bug descriptions by hand; quick machine translations would be sufficient.
Please let BibLibre forward bug reports in French and let's add babelfish links to the bug display page header or footer. "Andrew Moore" <andrew.moore@liblime.com> wrote:
I wrote that there after a brief discussion with some other contributors.
Who, JOOI? It's not showing up in IRC logs. [...]
It does sometimes seem like a long process, especially compared to a small patch. Could we make it easier by making bugzilla accept entries via email? <http://wiki.mozilla.org/Bugzilla:FAQ:Bugzilla_Email#How_do_I_set_up_the_email_interface_to_submit.2Fchange_bugs_via_email.3F>
Yes, please! I learned about this a few days ago and was going to ask if we can do it here. It would make life much easier. Can we also allow koha users to submit new bugs by email without getting spammed to hell? It would help to make the bugs data more accurate and representative. Thanks, -- 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
On Thu, Jul 31, 2008 at 9:06 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Yeah, please can people discuss such policy changes on -devel first?
You bet. I should probably have discussed this more before editing. I'm still getting used to this concept where all edits of the wiki need to be vetted by the community first Please note: I didn't think I was changing any policies. It has long (always?) been my policy to encourage opening bugs for all patches. I continue to do so. Patches still seem to be accepted without open bugs, and I think that's fine.
I think there SHOULD be a bug for every patch. However, there should be some tool trying to update bugs automatically on patch-mail and head commit (maybe from /bug\s+(\d+)/ on the commit message).
I agree. I think that would be really useful, too. I've had it on my list for a while to write a git hook that will help do that. If you come up with one, please share it with the rest of us! If there existed a good one, I think that Josh or the RM at the time could make their git use it for all commits to the head. I'd personally like to use it as a hook after "git send-email" so that it would note that I have submitted a patch.
Please let BibLibre forward bug reports in French and let's add babelfish links to the bug display page header or footer.
Bablefish translations aren't that great, but I guess they're better than nothing. Can you take care of adding that link to Bugzilla somehow, please?
Who, JOOI? It's not showing up in IRC logs.
Who or what is JOOI?
Yes, please! I learned about this a few days ago and was going to ask if we can do it here. It would make life much easier.
Can we also allow koha users to submit new bugs by email without getting spammed to hell? It would help to make the bugs data more accurate and representative.
I'm hoping that email interface gets put together, too. I don't think I understand, though. It sounds like you're asking for two things here. I'd like to be able to submit and update bugs via email. Does that cover both of those requests? I may be able to work on that soon, unless someone else beats me to it. Just so that I don't step into some kind of historical problem (again!), have we been spamming users to hell for reporting bugs via email? What kind of spam do you mean? Is it something from us? Or do you mean that their email address gets put on bugzilla and then they get spam from elsewhere? Thanks, -Andy
"Andrew Moore" <andrew.moore@liblime.com> wrote:
On Thu, Jul 31, 2008 at 9:06 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Yeah, please can people discuss such policy changes on -devel first?
You bet. I should probably have discussed this more before editing. I'm still getting used to this concept where all edits of the wiki need to be vetted by the community first
Please don't exaggerate to "all edits". The guidelines are a bit more formal/important than many wiki pages. [...]
Bablefish translations aren't that great, but I guess they're better than nothing. Can you take care of adding that link to Bugzilla somehow, please?
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=2442 but bugs.koha.org seems to be run by liblime so I don't have access to fix stuff (this is a recurring problem in koha.org...).
Who, JOOI? It's not showing up in IRC logs.
Who or what is JOOI?
Just Out Of Interest. STFW. ;-) So how about it? Who endorsed "a bug for every patch"?
Yes, please! I learned about this a few days ago and was going to ask if we can do it here. It would make life much easier.
Can we also allow koha users to submit new bugs by email without getting spammed to hell? It would help to make the bugs data more accurate and representative.
I'm hoping that email interface gets put together, too. I don't think I understand, though. It sounds like you're asking for two things here. I'd like to be able to submit and update bugs via email. Does that cover both of those requests? I may be able to work on that soon, unless someone else beats me to it.
It would also need unregistered users to be allowed to report bugs.
Just so that I don't step into some kind of historical problem (again!), have we been spamming users to hell for reporting bugs via email? What kind of spam do you mean? Is it something from us? Or do you mean that their email address gets put on bugzilla and then they get spam from elsewhere?
Both getting spam because their email address gets put on bugzilla and bugzilla getting spammed because it allows incoming emails. Email-accessible bug trackers have to have some protection. I'm not sure what is possible with bugzilla. Hope that explains, -- 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
Who or what is JOOI?
Just Out Of Interest. STFW. ;-)
I did search the fucking web, and I didn't come up with anything useful in the small amount of time I was interested in spending. http://www.google.com/search?hl=en&q=define%3AJOOI&btnG=Search I'm interested in adding something to the wiki about being civil to each other. Do you think you could support such a proposal? -A
"Andrew Moore" <andrew.moore@liblime.com> wrote:
Who or what is JOOI? Just Out Of Interest. STFW. ;-)
I did search the [fine] web, and I didn't come up with anything useful in the small amount of time I was interested in spending. http://www.google.com/search?hl=en&q=define%3AJOOI&btnG=Search
Oh dear, Google doesn't know it if it's prefixed with define:, so it must not exist in the English language.
I'm interested in adding something to the wiki about being civil to each other. Do you think you could support such a proposal?
Sure, as long as it doesn't mandate US sense of humour, but I feel this is starting irrelevant arguments instead of saying which developers were included in that coding guideline discussion. 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
Hi, On Thu, Jul 31, 2008 at 9:06 AM, MJ Ray <mjr@phonecoop.coop> wrote:
I think there SHOULD be a bug for every patch. However, there should
Obviously, we cannot mandate that every patch have a bug number, and I'm not going to use that as a criteria for rejecting patches for 3.2. However, this needs to be encouraged.
be some tool trying to update bugs automatically on patch-mail and head commit (maybe from /bug\s+(\d+)/ on the commit message).
Making some tool to automatically tie patch submissions to bug updates is a good idea.
TTLLP also has an internal work tracker (RT), but we can link from the "Refers to" field to bugs.koha.org - I'm trying to be better at doing that for all our koha bugs as soon as we're reasonably confident it's
Thanks.
not a local configuration error. The flames from LibLimeys if I patch a bug they've not experienced yet are *not* encouraging this (TMPL_ELSIF MacOS X 10.5 unpredictability/unportability most recently) so I can understand why BibLibre feel it's too expensive.
Flames? This is a strong accusation. TMPL_ELSIF is a useful construct, and if there is a portability problem on one platform, it is better to at least try fix the root cause. As I recall, Joe, one of the "LibLimeys", spent a great deal of time working with you on #koha to debug the issue. Do you seriously consider this to be evidence of a LibLime effort to flame you, or are you objecting to any criticism whatsoever of your patches? No patch should be above constructive criticism, including any that LibLime submits. Regarding your implication that BibLibre is being put off by LibLime's "flames", are you claiming to speak for them? I'm sure Paul can speak for himself.
"Galen Charlton" <galen.charlton@liblime.com> wrote:
I recognize that you have pressures on your time. I don't think you necessarily need to spend time translating your bug descriptions by hand; quick machine translations would be sufficient.
Please let BibLibre forward bug reports in French and let's add babelfish links to the bug display page header or footer.
Again, I assume Paul can speak for himself. If some bugs get entered in French or any other non-English language, so be it: we all have access to online translators. However, I would still encourage most bugs to be submitted in English; not only does this improve the ability for everybody to search to bug database, for better or worse, English is the only language that contributors to core Koha have in common. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On Thu, Jul 31, 2008 at 9:06 AM, MJ Ray <mjr@phonecoop.coop> wrote:
not a local configuration error. The flames from LibLimeys if I patch a bug they've not experienced yet are *not* encouraging this (TMPL_ELSIF MacOS X 10.5 unpredictability/unportability most recently) so I can understand why BibLibre feel it's too expensive.
Flames? This is a strong accusation. TMPL_ELSIF is a useful construct, and if there is a portability problem on one platform, it is better to at least try fix the root cause.
It's not a strong accusation. It's a feeling. Don't make a drama out of a crisis only just noticed, like the adverts used to say. The portability problem is that it only works with HTML::Template::Pro so far, which is fine if Koha is the only thing someone is templating with that syntax. Otherwise it's just confusing and limits what tools can be used and what can be shared. ELSIF doesn't seem much more useful as a construct than an IF inside an ELSE. It's not like adding hygenic macros or something.
As I recall, Joe, one of the "LibLimeys", spent a great deal of time working with you on #koha to debug the issue.
Sure, the IRC discussion has been much better than the email one, which is different to what happens in other projects. I thank Joe for his time, but he did keep blaming HTML::Template::Expr which, it turns out, was a wild goose chase. See http://koha.org/cgi-bin/logs.pl?startdate=2008072908%3A59%3A23&enddate=2008072911%3A04%3A27&search=Search (I get the impression from the "scare quotes" above that "LibLimeys" isn't liked - what is? I've used BibLibrians and Turuloj without complaint in the past, but LibLimers sounded to me like people who'd smear stuff with limes...)
Do you seriously consider this to be evidence of a LibLime effort to flame you, or are you objecting to any criticism whatsoever of your patches?
I don't mind being challenged, but calling everything from module version to the OS installation (which was done by another company, for what it's worth) into question in response to a bugfix patch seems inappropriate criticism, bordering on blind defence of a feature which doesn't work for everyone at times. http://lists.koha.org/pipermail/koha-patches/2008-July/001325.html
Regarding your implication that BibLibre is being put off by LibLime's "flames", are you claiming to speak for them?
No, I'm just noting I can understand why they might consider interacting with koha.org too expensive, because of things like that, or this subthread where I'm being interrogated in detail over a simple comment. It really doesn't help to get more bugs linked across or more TTLLP members active on koha-devel. It's more duty than fun most of the time. As part of any code of conduct, I'd suggest not sending the above sort of personal messages ("you... you... you...") to this list. Hope that explains, -- 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
participants (5)
-
Andrew Moore -
Frederic Demians -
Galen Charlton -
MJ Ray -
Paul POULAIN