Roundup Issue Tracker

+1 for bazaar support.  :)



David Hostetler
negativesum@...

On Tue, 02.06.2009 at 11:30:31 -0400, David Hostetler <negativesum@...> wrote:
> +1 for bazaar support.  :)

Seconded.

-- 
Kind regards,
--Toni++

My initial proposal was actually focused on Bazaar, but focus will
mostly be given to Mercurial during the GSoC.
However, yes, expect Bazaar integration as well probably sometime after GSoC.

Cheers,
M.

On Tue, Jun 2, 2009 at 17:40, Toni Mueller <support-roundup-dev@...> wrote:
>
> Seconded.
>

El mar, 02-06-2009 a las 20:31 +0200, Mario escribió:
> My initial proposal was actually focused on Bazaar, but focus will
> mostly be given to Mercurial during the GSoC.
> However, yes, expect Bazaar integration as well probably sometime after GSoC.
> 

If the core code is clean enough I might contribute, time permitting, a
git integration. I don't expect big problems if mercurial and bazaar are
supported.

Regards
Santiago

> Cheers,
> M.
> 
> On Tue, Jun 2, 2009 at 17:40, Toni Mueller <support-roundup-dev@...> wrote:
> >
> > Seconded.
> >
> 
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
> looking to deploy the next generation of Solaris that includes the latest 
> innovations from Sun and the OpenSource community. Download a copy and 
> enjoy capabilities such as Networking, Storage and Virtualization. 
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Roundup-devel mailing list
> Roundup-devel@...
> https://lists.sourceforge.net/lists/listinfo/roundup-devel

Santiago Gala wrote:
> El mar, 02-06-2009 a las 20:31 +0200, Mario escribió:
>   
>> My initial proposal was actually focused on Bazaar, but focus will
>> mostly be given to Mercurial during the GSoC.
>> However, yes, expect Bazaar integration as well probably sometime after GSoC.
>>
>>     
>
> If the core code is clean enough I might contribute, time permitting, a
> git integration. I don't expect big problems if mercurial and bazaar are
> supported.
>   

That sounds great ! Yes, as Roundup already has an extension for SVN, 
the main idea here is to create an abstraction that is able to support 
different VCS backends (we just happen to focus on Mercurial as the 
Python-dev folks are interested into that) so people can continue  the 
work on other VCS bindings.

Regards,
       Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan@...
(650) 331-3385 x718

Stefan Seefeld schrieb:
> Santiago Gala wrote:
>> El mar, 02-06-2009 a las 20:31 +0200, Mario escribió:
>>   
>>> My initial proposal was actually focused on Bazaar, but focus will
>>> mostly be given to Mercurial during the GSoC.
>>> However, yes, expect Bazaar integration as well probably sometime after GSoC.
>>>
>>>     
>> If the core code is clean enough I might contribute, time permitting, a
>> git integration. I don't expect big problems if mercurial and bazaar are
>> supported.
>>   
> 
> That sounds great ! Yes, as Roundup already has an extension for SVN, 
> the main idea here is to create an abstraction that is able to support 
> different VCS backends

We should pay attention to the fact that the subversion support
currently doesn't include pysvn support; this means, that it is
sometimes necessary to compile Subversion, which can be a non-trivial
task (see
<http://sourceforge.net/mailarchive/forum.php?thread_name=47B30456.9080701%40gmx.de&forum_name=roundup-users>).
The abstraction layer is the opportunity to fix this, too (perhaps
trying the "better" version first, and on ImportError fall back to the
other).

-- 
Tobias

Am Dienstag, 2. Juni 2009 02:57:53 schrieb Stefan Seefeld:
> with a lot of delay I'm (still) happy to announce that Roundup was
> selected to benefit from a Google Summer of Code project this year.
> Mario Danic is going to work on VCS integration into Roundup. In
> particular, the idea is to start with Richards work on SVN integration,
> and generalize and expand on it. Generalize in that other revision tools
> will be supported (mercurial, in particular, which python-dev folks are
> particularly interested in), and expand, as we plan to support more use
> cases than the simple "make Roundup close bug X when I check this in".

Wonderful.

> The first new piece of code is a new tracker template, which is quite
> close to what we currently use on http://issues.roundup-tracker.org, and
> http://bugs.python.org.
>
> I split 'issues' into 'bugs' and 'tasks', and added a 'milestone' type.
> I expect other new features to follow (such as a 'patch' type, using
> some of the VCS support that will come soon).

For software development I suggest to not use the term "bug" anymore,
issue is much better. And then some things are defects which means the 
software does not behave as the programmer wanted it. Not all problems are 
defects. For a detailed reasoning see Zeller 2005,
http://www.whyprogramsfail.com/.



-- 
Managing Director - Owner: http://www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: http://www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Bernhard Reiter schrieb:
> Am Dienstag, 2. Juni 2009 02:57:53 schrieb Stefan Seefeld:
>> I split 'issues' into 'bugs' and 'tasks', ...
> 
> For software development I suggest to not use the term "bug" anymore,
> issue is much better. And then some things are defects which means the 
> software does not behave as the programmer wanted it. Not all problems are 
> defects. For a detailed reasoning see Zeller 2005,
> http://www.whyprogramsfail.com/.

This implies it is not a good idea to have different classes for bugs
and tasks, and I agree.  IMO, it would be better to keep them in their
common "issue" class, and of course split the urgency (or "severity",
like it is done in the "devel" template; I like "urgency" better,
because it suits better for tasks) from the "priority" attribute.

-- 
Tobias

On 07/09/2009 02:50 AM, Tobias Herp wrote:
> Bernhard Reiter schrieb:
>    
>> Am Dienstag, 2. Juni 2009 02:57:53 schrieb Stefan Seefeld:
>>      
>>> I split 'issues' into 'bugs' and 'tasks', ...
>>>        
>> For software development I suggest to not use the term "bug" anymore,
>> issue is much better. And then some things are defects which means the
>> software does not behave as the programmer wanted it. Not all problems are
>> defects. For a detailed reasoning see Zeller 2005,
>> http://www.whyprogramsfail.com/.
>>      
>
> This implies it is not a good idea to have different classes for bugs
> and tasks, and I agree.

I don't think the suggestion to use 'issue' instead of 'bug' implies 
that 'tasks' would be 'issues', too. While I can see that 'bug' is too 
narrow a concept (it seems indeed strange to represent enhancement 
requests as 'bugs' with a 'RFE' tag added), I still believe there is 
enough difference between an end-user-visible entity such as 'issue' on 
the one hand, and a project-management-specific term such as 'task'. 
They are quite distinct terms, and Roundup users may or may not want to 
use one of them or even both.

>    IMO, it would be better to keep them in their
> common "issue" class, and of course split the urgency (or "severity",
> like it is done in the "devel" template; I like "urgency" better,
> because it suits better for tasks) from the "priority" attribute.
>    

Again, the difference between severity and priority is about domain: 
Severity provides a ranking for users, while priority is entirely about 
development (project management), and the ordering in which issues 
should be addressed. 'Urgency' is ambiguous, IMO, while severity makes 
it clear that this is about impact on the end-user.

My 2 cents,

         Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...