[mapguide-internals] Request for submission

Wed Mar 28 08:25:38 EDT 2007

Tom,

The example you gave below would be useful to see both in the defect  
and on the mailing list.  One way is to put the traffic on the  
mailing list and then copy the appropriate info to the defect.  I  
think this is quite possibly error prone because it relies on human  
intervention (actually going to trac, finding the ticket, copying the  
comment) and interpretation (is this really useful to put on the  
ticket? nah, I'll remember that).

Looking in Trac, I see 10 open issues (3 submitted by me!).  I highly  
doubt that the amount of traffic coming from these tickets is going  
to overwhelm anyone, especially if the traffic is mostly discussion  
that would have happened on the list anyway.  I doubt this would  
result in more than 1 email per day on average, probably 1 a week.

So the suggestions on the table are:

1) status quo, we don't change anything and no-one on the internals  
list will know about new tickets unless they go look

2) modify trac to cc mapguide-internals, the list will get emails for  
everything that happens on all tickets

3) modify trac to cc a new mailing list (mapguide-tickets?) to which  
only those who are interested can subscribe

4) modify trac to set mapguide-internals as the default owner of new  
tickets.  The list will get traffic on the ticket until it gets  
assigned to someone specific to deal with it, at which point people  
can cc themselves on the issue if they are interested in following it

5) some combination of 4 and 2) or 3)

I would like to see option 4) and option 3) implemented  
simultaneously but I could live with either or option 2).  As long as  
my email inbox fills up ...

For patches submitted from the wild, we can encourage them to file a  
ticket in trac.  Any discussion related to the patch should (IMO) go  
in the ticket and to the list (automagically) until the patch has  
been accepted or rejected.  If we go with 4), mapguide-internals  
would stay the owner until the patch had been discussed and then  
would be assigned to whoever wants to take responsibility for it.   
Further discussion can safely happen on the ticket after the change  
because anyone who is interested can cc themselves.

What I would like to avoid is the situation where you are looking at  
a ticket with a patch two months after it was submitted and think to  
yourself "someone said something about these 5 lines of code and I  
can't find it anywhere," or you forget the conversation ever took  
place.  I am personally lazy and forgetful.  Any system that requires  
me to do more than the minimum will ultimately fail for me ... and I  
have a theory on human nature that indicates I'm not the only one ;)

Cheers

Paul

On 28-Mar-07, at 12:43 AM, Tom Fukushima wrote:

> Hi,
>
> Some more thoughts...
>
> The way I see things working: if someone without commit rights has a
> patch to submit, they attach the patch to the ticket and send a  
> note to
> mapguide-internals that a patch has been submitted.  A committer picks
> up the patch, reviews it and sends any feedback to mapguide-internals.
> If the patch needs rework this process is repeated.
>
> To say what I was trying to say in my previous email differently: I
> don't think that it makes sense to put feedback such as "did you
> consider using method abc to replace the five lines in method y" in  
> the
> trac defect; this is globally useful information and everyone  
> should see
> it.

This is where I disagree ... when you go to apply the patch, you then  
have to go looking for the related email (if you remember it  
happened).  By cc'ing the list, the info goes into the ticket where  
it can be easily be found when the ticket is actioned and goes to the  
list for general information.

>
> Paul, I think that this satisfies the "all discussion related to the
> patch should take place in the ticket" requirement that you had
> originally stated right? The patch review comments don't relate to the
> defect, and instead relate to the code or techniques used in the patch
> itself. If there are patch review comments that do provide information
> for the defect, they need to be added to the defect.
>
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom
> Fukushima
> Sent: Tuesday, March 27, 2007 11:57 AM
> To: MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] Request for submission
>
> Hi,
>
> 1) I think that the discussion should be on the mailing list; and then
> any relevant parts should be copied to the trac defect after  
> discussion
> is completed. The reason for having the discussion on the mailing list
> is so that we can all see what a submitters submissions are like; then
> when it comes time to vote on whether to accept the patch submitter as
> someone with actual commit rights, we will all have know the
> capabilities of the person.
>
> 2) I like the idea of attaching the patch to the trac defect.
>
> Thanks
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of  
> Robert
> Bray
> Sent: Tuesday, March 27, 2007 8:31 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Request for submission
>
> According to the book Producing FOSS by Karl Fogel discussion  
> should not
> take place in the tracker. To date I've been using that book to guide
> many of our open source efforts. In the end I am not sure it is a big
> deal but I'll let the rest of the PSC voice their thoughts.
>
> I do like the idea of new tickets showing up in a number of peoples
> inbox to give them visibility, so in the meantime I'll look into  
> how to
> go about that.
>
> Bob
>
> Jason Birch wrote:
>> Hmm.
>>
>> That approach would work well also.  I agree that new tickets don't
>> really get enough visibility.  If we do this, we should also make  
>> sure
>
>> that we either set up something like Akismet to block spam, or  
>> require
>
>> a login for a ticket submission.
>>
>> Jason
>>
>> -----Original Message-----
>> From: Paul Spencer
>> Subject: Re: [mapguide-internals] Request for submission
>>
>> I personally think all patches should be filed as enhancements and  
>> all
>
>> discussion related to the patch should take place in the ticket so
>> that everything related to that issue is in one place and can easily
>> be found.
>>
>> This is what we have done in the past and it is very effective, no
>> information is lost.  The reason it works is because the default  
>> owner
>
>> of new issues is a mailing list of people that are interested in new
>> issues.  In this case, it would be very useful if new tickets  
>> could be
>
>> assigned to a default owner that is, in effect, the mapguide-
>> internals list.  While the issue is not reassigned, all discussion
>> would be tracked in both the bug and on the list.  Once assigned  
>> (i.e.
>
>> someone is going to do something about it), the mailing list user can
>> be removed and anyone that is interested in following further can cc
>> themselves to the bug.
>>
>> One thing that I have found with the current setup is that bugs just
>> seem to disappear when filed.  No-one else seems to get notified that
>> a new bug was created etc.  Perhaps that's not the case?
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+