[Trac] bugs existing in multiple versions and fixed in multiple versions

[trac at nogga.de]

Hi Brad, Hi Martin,

thanks for commenting on this issue. One reasons for me to change from 
bugzilla to trac is the minimalistic but still powerfull approach of 
trac to handle this issue. I have seen a major increase of issue 
reporting and code documentation effort, since we changed to trac in our 
team. Bugzilla was a beast that kept my team members away. Perhaps good 
for a large distributed user base, but not for a small development team.

The rationale behind my question is very simple. We develop a high 
specialized application for the industry and have to support at least 
ervery version we deliverd once. No bigger industry is willing to change 
the software after the solution was established in their production 
environment. Every new software installation will lead to user 
training,  will lead to new problems, will disturb the current 
production practices and so on. In most cases, they want to have their 
bugs fixed and want to participate only in major development steps.

This behavoir is totally different to the bleeding edge internet adicted 
open source development comunity, where every peace of printed paper is 
antiquated at the time the paper was printed.

For my szenario a service person has the responsibility to track first 
all installations of every software, all bugs reported against every 
version and he must decide, wether it is necessary to make more than one 
maintance version for different customers due to the same bug.

Now you may question, wether we don't by a high specialized bug tracking 
software, that can do this. First, they are very expensive, second I 
don't know of any software that works this way. I once worked with 
Starteam. They solved this problem by keeping software and bug reports 
in the same tool and then branched the bug reports like the software 
into the maintance branches. Working with this tool was not very 
intuitive (esp. when you com from CVS or other RCS based version 
control). And I don't know exactly, wether it was possible to later 
branch/share bugs into already existant maintanance branches. If 
everything worked well, it was very easy for the support personal to 
open a specific software version (or better software line)  and to tell 
which bugs are still existant in this version.

The above mentioned behavoir is also an option for subversion. There is 
the subissue project at  http://subissue.tigris.org/ that tries to treat 
issues like everthing else in subversion.

For trac I would hope for
- a multiselect version field
- a sperate multiselect "fixed in" handling (seperate from milestone)
- a Versionmap (like Roadmap, but only for the version information) to 
show the full issue information of each version
- and some built in logic about the propagation of bugs between the 
different versions.


Thanks for listening. And also if this mail was a little longer than 
expected I would be very interested in further discussions.

Best regards
Dirk




Brad Anderson schrieb:

>We have had a lot of success delivering applications that have the complexity 
>when required, but hide a lot of it if the requirement is not there.  It is a 
>delicate balance, for sure, but if done well, is powerful.
>
>I think it is inevitable that successful projects will grow in 
>feature/function, and Trac appears to be on that road.  One of the keys for 
>the developers (Daniel, Jonas, Chris, et al) is to choose the right 
>ideas/proposals that are coming in, and be smart about maybe adding the 
>functionality but doing the UI in a way that doesn't necessarily expose the 
>complexity if it's not needed.  
>
>I agree with you that Bugzilla is a monster, but only because the UI grew out 
>of control when the features rolled in.  An example of what I'm talking about 
>is Google.  They have evolved tremendous complexity in their back-of-house, 
>with a colossal Linux cluster, their own file system, memory caching and a 
>host of other problems that they solved in some manner or another.  And yet 
>their home page still has one text box and 53 words or less.  They've kept 
>that complexity away from their users when the user doesn't require it.
>
>BA
>
>
>On Thursday 16 December 2004 1:38 pm, Martin Bialasinski wrote:
>  
>
>>trac at nogga.de wrote:
>>    
>>
>>>Does anybody else have this type of requirement?
>>>      
>>>
>>Not me. But I like to vote for "Keep it simple" nevertheless, so that
>>Trac does not become a monster like Bugzilla.
>>
>>I would do it this way:
>>
>>"Bug for (1.8 - 2.0)" in the title and comments like "Fixed for 1.8"
>>and changing the title. Then, when the last version it applies for is
>>fixed, the bug is closed.
>>
>>Or I would set "1.8, 1.9, 2.0" in the keywords field and used this for
>>selection, if I needed to select by version.
>>
>>Bye,
>>        Martin
>>_______________________________________________
>>Trac mailing list
>>Trac at lists.edgewall.com
>>http://lists.edgewall.com/mailman/listinfo/trac
>>    
>>
>_______________________________________________
>Trac mailing list
>Trac at lists.edgewall.com
>http://lists.edgewall.com/mailman/listinfo/trac
>
>
>  
>