[Deploying Sakai] [Building Sakai] Shouldn't bug reports be easier to read for humans?

Jean-Francois Leveque jean-francois.leveque at upmc.fr
Thu Jul 18 06:26:51 PDT 2013

Given the input, that's what I'm gonna code.

Don't know when I will but I still intend to and hope the parts of the 
code that are more critical will be explicit and the review process 
defined so I can confidently contribute and be reviewed not too late 

I can patch locally but don't want to fork too far from the community 
code. Having contributions merged when they're good is part of the best 
things we can do together.


On 17/07/2013 20:00, David Adams wrote:
> Perhaps the safer way to address the problem would be to add new
> fields to provide the human readable dates you are looking for and
> leave the existing fields intact.
> -dave
> On Wed, Jul 17, 2013 at 9:08 AM, Matthew Jones<matthew at longsight.com>  wrote:
>> Well, at Michigan we had a process to cc these bug reports to a special
>> mailbox, a script to parse them and put them into a database, then do
>> monthly reporting on them. Something like that would be based around this
>> date field being as it is. Ideally something like this would be built into
>> Sakai, but it was much faster doing it externally.
>> I'm not sure if they're still running that actively, but you have to figure
>> someone out there might be.
>> I agree with Aaron, it is a high profile area, but someone would review and
>> commit any code that you provide. The ideal is that every jira is
>> verified/reviewed either by a developer or QA depending, usually depending
>> on the test plan or how extensive the changes are.
>> On Wed, Jul 17, 2013 at 4:19 AM, Jean-Francois Leveque
>> <jean-francois.leveque at upmc.fr>  wrote:
>>> I'm personally not aware or reasons to preserve the old values, that's why
>>> I was asking. Unless I get answers from people who need the old values to be
>>> kept, I won't.
>>> I'm adding the production list now to reach a larger audience who might
>>> need the old values.
>>> Unless this part of the code is subject to review like kernel because
>>> changes are known to be risky, I think I can handle it myself.
>>> On 17/07/2013 04:12, Matthew Jones wrote:
>>>> Agreed. If it's important to you, submit a patch or contract with a
>>>> developer/commercial affiliate to have it resolved. Would be a few lines
>>>> of code and a few new message strings.
>>>> The code is somewhere in
>>>> portal/portal-util/util/src/java/org/sakaiproject/portal/util/ErrorReporter.java
>>>> I think you'd want to preserve the old values in-case anyone is using
>>>> them and append new values like Created (formatted)
>>>> Unless it's a high priority bug (breaks tool functionality) or a desired
>>>> local feature, generally it could take a while until it gets resolved.
>>>> On Tue, Jul 16, 2013 at 9:17 PM, Poindexter, David Ray
>>>> <davpoind at iupui.edu<mailto:davpoind at iupui.edu>>  wrote:
>>>>      Dev resources, I'm guessing.
>>>>      --
>>>>      David Poindexter
>>>>      Sent from my mobile
>>>>      On Jul 16, 2013, at 10:49 AM, "Jean-Francois Leveque"
>>>>      <jean-francois.leveque at upmc.fr
>>>>      <mailto:jean-francois.leveque at upmc.fr>>  wrote:
>>>>       >  Hi,
>>>>       >
>>>>       >  I've created https://jira.sakaiproject.org/browse/SAK-22022 as a
>>>>      feature
>>>>       >  request some time ago.
>>>>       >
>>>>       >  Do we have reasons not to do this?
>>>>       >
>>>>       >  Cheers,
>>>>       >  J-F

More information about the production mailing list