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

Jean-Francois Leveque jean-francois.leveque at upmc.fr
Tue Sep 10 03:04:30 PDT 2013

Patch added to https://jira.sakaiproject.org/browse/SAK-22022 and 
awaiting review and integration for the release that will spring from trunk.


On 18/07/2013 15:26, Jean-Francois Leveque wrote:
> 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
> afterwards.
> 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.
> J-F
> 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