[Deploying Sakai] [Building Sakai] Shouldn't bug reports be easier to read for humans?
da1 at vt.edu
Wed Jul 17 11:00:49 PDT 2013
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.
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
>>> 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
>>> > request some time ago.
>>> > Do we have reasons not to do this?
>>> > Cheers,
>>> > J-F
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
More information about the production