[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread Martin Albrecht

On Monday 22 October 2007, mabshoff wrote:
 Hello,

 since this has come up repeatedly I would like to clarify: Do not
 close any tickets in trac unless you have been explicitly told to do
 so by either malb, was, cwitty or mabshoff. This is to avoid having
 issues slip through the cracks. Once a ticket is closed and off the
 top of the time line chances are nobody will ever look at it again
 unless you stumble across it by accident.

 Just like the [with patch] byline we should come up with something
 to indicate that a ticket should be looked at like [should be
 closed], [is invalid] or [is won'tfix]. In addition you should
 give a reason why you think the action you requested should be taken
 (the more precise the better) and retag the ticket against the current
 target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is
 unlikely to be found and looked at because there are another 140
 tickets open against that one.

 William can configure trac so that closing tickets is limited to a
 few, but so far he has not done so. But as we have to deal with an
 ever increasing number of tickets we need to follow the process in
 order to avoid losing issues and also keep the confusion and the work
 to deal with tickets to a minimum.

I got a clarification for the clarification:

Michael mentioned me (malb) and Carl (cwitty) because William (was) asked us 
to prepare the next release. So for 2.8.9 the three of us are the release 
managers and consequently we are supposed to close tickets.

and a question:

Take ticket 729 as an example ( 
http://trac.sagemath.org/sage_trac/ticket/729 ): It was closed by Robert 
(rml) because the bugfix/feature request was invalid. Michael (mabshoff) 
reopened it due to the rule state above. But there is nothing for the release 
manager to do and I feel perfectly comfortable with rml closing invalid 
tickets for the Graph subsystem. So I think in those cases it makes perfectly 
sense to just close tickets.

IMHO this rule could be relaxed if we had the e-mail subsystem working (I know 
it is being worked on). Because in that case, the submitter and the owner of 
a ticket get an e-mail and can complain if it isn't actually fixed.

Martin

-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---



[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread mabshoff



On Oct 22, 10:40 am, Martin Albrecht [EMAIL PROTECTED]
wrote:
 On Monday 22 October 2007, mabshoff wrote:

Hello,

  Hello,

  since this has come up repeatedly I would like to clarify: Do not
  close any tickets in trac unless you have been explicitly told to do
  so by either malb, was, cwitty or mabshoff. This is to avoid having
  issues slip through the cracks. Once a ticket is closed and off the
  top of the time line chances are nobody will ever look at it again
  unless you stumble across it by accident.

  Just like the [with patch] byline we should come up with something
  to indicate that a ticket should be looked at like [should be
  closed], [is invalid] or [is won'tfix]. In addition you should
  give a reason why you think the action you requested should be taken
  (the more precise the better) and retag the ticket against the current
  target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is
  unlikely to be found and looked at because there are another 140
  tickets open against that one.

  William can configure trac so that closing tickets is limited to a
  few, but so far he has not done so. But as we have to deal with an
  ever increasing number of tickets we need to follow the process in
  order to avoid losing issues and also keep the confusion and the work
  to deal with tickets to a minimum.

 I got a clarification for the clarification:

 Michael mentioned me (malb) and Carl (cwitty) because William (was) asked us
 to prepare the next release. So for 2.8.9 the three of us are the release
 managers and consequently we are supposed to close tickets.

 and a question:

 Take ticket 729 as an example 
 (http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert
 (rml) because the bugfix/feature request was invalid. Michael (mabshoff)
 reopened it due to the rule state above. But there is nothing for the release
 manager to do and I feel perfectly comfortable with rml closing invalid
 tickets for the Graph subsystem. So I think in those cases it makes perfectly
 sense to just close tickets.

Well, I see it the same way: rml is responsible for the graph
subsystem, so he is the person with the expertise to determine that
the ticket is invalid. But he closed that ticket against 2.9, while it
is customary to close invalid tickets against the sage-duplicate/
invalid milestone. The same applies for #731. It is not so much the
marking the ticket invalid, it just ended up against the wrong
milestone.

What caused me to actually raise the issue is #656: That one is
clearly not a duplicate. #968 is an enhancement relative to #656.
During Bug Day 4 William also told rlm not to close tickets until the
issue had been officially resolved.


 IMHO this rule could be relaxed if we had the e-mail subsystem working (I know
 it is being worked on). Because in that case, the submitter and the owner of
 a ticket get an e-mail and can complain if it isn't actually fixed.


Yep, that has been requested for quite some time. William has enabled
smtp support for trac IIRC, but it doesn't work (yet).

 Martin


Cheers,

Michael

 --
 name: Martin Albrecht
 _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
 _www:http://www.informatik.uni-bremen.de/~malb
 _jab: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---



[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread Martin Albrecht

  Take ticket 729 as an example
  (http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert
  (rml) because the bugfix/feature request was invalid. Michael (mabshoff)
  reopened it due to the rule state above. But there is nothing for the
  release manager to do and I feel perfectly comfortable with rml closing
  invalid tickets for the Graph subsystem. So I think in those cases it
  makes perfectly sense to just close tickets.

 Well, I see it the same way: rml is responsible for the graph
 subsystem, so he is the person with the expertise to determine that
 the ticket is invalid. But he closed that ticket against 2.9, while it
 is customary to close invalid tickets against the sage-duplicate/
 invalid milestone. The same applies for #731. It is not so much the
 marking the ticket invalid, it just ended up against the wrong
 milestone.

Why do we need to change the milestone for invalid tickets?

Martin

-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---



[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread mabshoff



On Oct 22, 11:13 am, Martin Albrecht [EMAIL PROTECTED]
wrote:
   Take ticket 729 as an example
   (http://trac.sagemath.org/sage_trac/ticket/729):It was closed by Robert
   (rml) because the bugfix/feature request was invalid. Michael (mabshoff)
   reopened it due to the rule state above. But there is nothing for the
   release manager to do and I feel perfectly comfortable with rml closing
   invalid tickets for the Graph subsystem. So I think in those cases it
   makes perfectly sense to just close tickets.

  Well, I see it the same way: rml is responsible for the graph
  subsystem, so he is the person with the expertise to determine that
  the ticket is invalid. But he closed that ticket against 2.9, while it
  is customary to close invalid tickets against the sage-duplicate/
  invalid milestone. The same applies for #731. It is not so much the
  marking the ticket invalid, it just ended up against the wrong
  milestone.

 Why do we need to change the milestone for invalid tickets?


The idea is to collect all invalid tickets in one milestone so that
they can be found by accessing one milestone. You can pull all of them
via custom query, but that is not as transparent. I only recently
started doing that, so there are invalid tickets attached to older
milestones, but I had a discussion with William about that in IRC
before creating that special milestone. The discussion happened about
3 weeks ago.

 Martin

Cheers,

Michael


 --
 name: Martin Albrecht
 _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
 _www:http://www.informatik.uni-bremen.de/~malb
 _jab: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---



[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread Robert Miller

 What caused me to actually raise the issue is #656: That one is
 clearly not a duplicate. #968 is an enhancement relative to #656.
 During Bug Day 4 William also told rlm not to close tickets until the
 issue had been officially resolved.

I'm assuming you're talking about 956. The reason I closed 956 and
deferred to 968 was because the patches are both to the same area of
code, and if you apply the patch in #956, then the ones in 968, funny
stuff might happen. The recommended patches in #968 will cover both,
so...


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---



[sage-devel] Re: Rules for closing tickets in trac

2007-10-22 Thread mabshoff



On Oct 22, 5:17 pm, Robert Miller [EMAIL PROTECTED] wrote:
  What caused me to actually raise the issue is #656: That one is
  clearly not a duplicate. #968 is an enhancement relative to #656.
  During Bug Day 4 William also told rlm not to close tickets until the
  issue had been officially resolved.


Hello Robert,

 I'm assuming you're talking about 956.

You are right, sorry for the type.

 The reason I closed 956 and
 deferred to 968 was because the patches are both to the same area of
 code, and if you apply the patch in #956, then the ones in 968, funny
 stuff might happen. The recommended patches in #968 will cover both,
 so...

Well, #968 has two patches, one of which is idential to the one
attached to #656 except that it is rebased against the tree after your
fixes went in. I would have suggested to attach the updated version
for #656 to that ticket and add a comment not to apply the first, but
the second version due to the rewrite attached to #968.

Cheers,

Michael


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---