[mapguide-internals] Request for submission

Wed Mar 28 13:11:52 EDT 2007

#3 already exists and has for some time.

   mapguide-trac at lists.osgeo.org.

I guess maybe I should have told someone/everyone that exists :)

I am looking into enabling #4.

Bob

Paul Spencer wrote:
> 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/ |
> +-----------------------------------------------------------------+
> 
> 
> 
> 
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> 