[Incubator] proposal to graduate MapBender

[Cameron Shorter]

I popped into the IRC and had a quick chat with Seven.

Using a bug tracker slows developers down.  The bug tracker only becomes 
valuable when the project becomes too hard to manage in people's heads.

Complexity is created as a consequence of:
* code size
* rate of development
* number of developers
* geographically distributed developers

After chatting with Seven, it seems that the Mapbender team have not 
been forced into setting up a bug tracking system because 5 members of 
their team can all talk with each other.

While this has some great advantages, in the long term, I think this 
will make it harder for Mapbender to attract new developers.  External 
developers may find they feel excluded from conversations that happen 
verbally.

So I see the lack of a standard bug tracker as an indication of a 
developer community which may have difficulty attracting outside members.

That said, I think that Mapbender is ready to complete incubation.
+1 for me.


Arnulf Christl wrote:
> On Mon, July 3, 2006 03:30, Frank Warmerdam wrote:
> 
>>Cameron Shorter wrote:
>>
>>>Could someone please expand on how Mapbender proposes to handle bugs.  I
>>>had similar concerns to Frank regarding bug tracking and would like to
>>>see how this is to be addressed.
>>>
>>>My vote: +0
>>>Will be +1 after seeing a solid plan to set up a bug tracker.
>>
>>Cameron,
>>
>>I don't believe there is any plan in place.  But Uli has called a
>>Mapbender
>>PSC/dev meeting for Monday to address the issue.  Perhaps after this he
>>can report on the plan(s) if any.
>>
>>Uli writes:
>> > dear list,
>> >
>> > we invite all members of the dev-list to the following discussion:
>> > Topic: How to manage bugs for Mapbender
>> > Monday, July 3, 11:00 (Berlin)
>> >
>>http://www.timeanddate.com/worldclock/fixedtime.html?day=3&month=7&year=2006&hour=11&min=0&sec=0&p1=37
>> > irc.freenode.net#mapbender
>>
>>I'll try and attend the meeting if I can rouse myself at the appointed
>>hour.  But from my point of view, I'm happy they are considering the
>>issue.
>>
>>Best regards,
> 
> 
> Hi,
> to make a long story short - we tried to get bug tracking operative
> several times, but it never worked. Some traces can still be found on
> SourceForge and a more recent faint try is in the CN Project Tracker. But
> it was never put to any good use - neither by the users nor by the
> developers, they all simply ignore it. We have it on our long term agenda
> and will address it once it becomes useful - currently it simply is not.
> 
> It gives me the impression that we would impose a technical and
> operational barrier to an otherwise perfectly well working informal way of
> doing things.
> 
> I don't know why, but there has always been a lack of fundamental errors
> in the software. Practically all issues brought up in the mailing lists
> can be idnetified and resolved as a problem outside the Mapbender
> codebase. Its not that the software is so great and perfect but rather
> that it only glues together other highly standardized pieces of code. I
> can see that I can't really explain. Maybe our chat will shed some more
> light on the issue. And yes, I am the first to support a formalized way to
> handle bugs. Maybe the neeed will arise as we see more project
> interaction.
> 
> Regards, Arnulf.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
> 
> 


-- 
Cameron Shorter
http://cameron.shorter.net