Subject: [TOOLS-DEVELOPMENT] Urgent tickets in [ietfdb]: What's the current situation with these and how do we keep them from getting this old?

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jun 2012 16:35:45 -0500

There are two tickets in the ietfdb system that shouldn't be as old as 
they are:

http://trac.tools.ietf.org/tools/ietfdb/ticket/842
http://trac.tools.ietf.org/tools/ietfdb/ticket/843

Is there activity on getting them resolved being tracked somewhere else?
I'm trying to follow up on them.

843 is probably OBE. Cindy says Matt was trying to post before 4.21 was 
deployed, and the
draft he was trying to post is posted now.

842 is still a problem - I get a crash from the server trying to look at 
the sunset4 charter.

What can we do to make sure reports like these land in a place where 
they get prompt attention?

RjS

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 29 Jun 2012 00:20:21 +0200

Hi Robert,

> 842 is still a problem - I get a crash from the server trying to look at 

For both of these, (and whenever there's a 500 error) notification of
the failure, together with stack traces, go directly to the people listed
in settings.ADMINS.  For #843 I saw the notifications, fixed the problem
and wrote back to Matthew within an hour of his first posting attempt.

I didn't remember to go and close the Trac ticket (but not closed it) though
(I do get email notifications of any new trac tickets, too).

The crash for /wg/sunset4/charter is a regression between 4.20 and 4.21.
I patched in the patches from production to trunk, but apparently this
one didn't take quite as it should have.  Fixing that now; then I'll go
back and have a look at the situation behind #842.

Best regards,

	Henrik

---

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jun 2012 17:53:39 -0500

Thanks Henrik -

Summarizing:

843 was fixed in a timely fashion, we just didn't capture that in the 
tracker.

842 was fixed in a timely fashion, but another problem came up later 
that coincidentally looked to be similar.

Can you think of anything that would make it easier/more likely to 
capture the closure on these?

One more to think about: earlier this week I found
<http://trac.tools.ietf.org/tools/ietfdb/ticket/832> which was 4 weeks 
old. The error there wasn't
a crash, it was just a data entry problem. What can we do to make it 
more likely those get caught
quickly?

RjS

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 29 Jun 2012 01:42:48 +0200

Hi Robert,

> more likely those get caught

Put more people on the notification list of the issue tracker?

I actually don't think we have a problem with catching important things;
but we do have a problem with following up on some of the issues which
aren't urgent.  

I do get email copies of all the issues (as well as stack traces for
each and every 500 error that occurs on the production server), and I
always do try to catch the serious issue tracker tickets as soon as I
can; I remember seeing #832 and concluding it was not serious and probably
a data entry error; but with the amount of load I've had lately I've been
triaging rather ruthlessly, and that one I just dropped.

I guess my priority list for handling things go something like this

 * Server 500 email traces -- analyse and handle ASAP
 * Requests from ADs -- handle ASAP if errors, handle as time permits
   for features
 * Requests from the secretariat -- handle ASAP if the issue is blocking
   secretariat work, otherwise urgently as time permits.
 * Direct email questions -- handle as time permits, may backlog
 * Tracker issues and email list messages -- handle as time permits,
   will backlog if not triaged to urgent.

The amount of time I have for each of my 3 areas of responsibility
(Netnod software development, IETF Program Manager [i.e., most of the
datatracker stuff], and IETF Tools Maintenance) varies a lot depending
on how many urgent things pop up in each of the areas.  During the first
half of this year there's been serveral urgent projects internally at
Netnod, and there's been the datatracker database schema conversion and
merging and deployment of the projects which were ready and waiting for
the new schema to be deployed.  Tools has been fairly calm, except for
the Trac server crash where an urgent change-over to another server had
to be arranged.

On both the Netnod side and the Datatracker side things are looking
better now, with several urgent projects completed and/or deployed,
but I don't see that I'll reach the point where I don't need to triage
quite yet.

Best regards,

	Henrik

> _______________________________________________
> TOOLS-DEVELOPMENT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-development
>