Re: Anthony Baxter's comments: I am aware that NewRoundup is a brand new beast, and that's a very good thing. =) As Ping himself noted in his release, roundup wasn't really architected. We pushed it too hard, and paid the price. I'm quite confident that the new roundup is much better. I'm also confident that both the new roundup and bugzilla would be better than the SF tracker =). The fact that the new roundup is in Python is a huge win IMO compared to bugzilla -- I can't tweak bugzilla, since my Perl sucks. >>4) non-web, non-email access to the database (e.g. take all the bugs >>assigned to so and so, and take those submitted by people in england, >>and set the keyword "never" to them). >> >There's the roundupdb interface, where you can directly script the database. >This requires local access (unless there's some sort of remote RPC for it). > That's fine by me. >>5) scalability (in # of developers, # of users, # of bugs, # of >>'versions', # of 'products', etc.) >> > >Unknown. > The biggest issue I see with roundup there is that the original model at least tended to generate wayyy too much mail, and the nosy list concept didn't really work well for long-lived bugs (I didn't really analyze the deeper 'why', sorry -- maybe Mark's memory is better than mine =). For one thing, it was basically impossible for people with only a peripheral view of the database (managers, QA folks) to get accurate pictures of the database. Nothing that can't be fixed if one has a real DB backend. >>6) Being able to migrate a bug from one product to another (not all that >>relevant for a Python-only bug tracker, except if the versions are >>handled as different products). >> >Assuming we're not just talking about tweaking the metadata, this is an >export/import task. Done. > Well, it's an export task done on a bug -- and all the metadata goes along with it, if you see what I mean. It just shows up in a different set of queries. >>2) an 'efficient' UI. The bugzilla default search results pages are >>very inefficient from a UI point of view. Andy McKay's version is much >>better, I think. >> >I don't see the difference in the two, aside from a smaller font? The UI >for roundup's pretty much completely flexible. > My only point is that flexibility is fine, but getting the details right is what matters in the end. Bugzilla's UI is flexible (it's all Perl, after all), but the defaults suck. >Ok. The way we have roundup configured is that a message is sent to >a set of users when an issue is opened, and then to users that are >"interested" subsequently - they've either commented on the bug, or >added themselves to the nosy list. What did you find meant too much >email? The "initial email out" was something we added. > Yeah, we added the same thing. As I said, I forget the details of the failure. >Would need more details for this. > No you don't. =) Roundup used the filesystem as a database, and lots of things didnt' work right in high load situations. I'm confident that the new one has a much better design. --david PS: bugzilla _does_ have a learning curve, not too bad a one for users w/ some UI cleanup (as in the 'simple search'), but pretty steep if people want to become power-users. Bugzilla also has a _ton_ of features, and someone else is worrying about it. I hear that bugzilla is also not very 'open' as a project -- getting changes back into the core is hard, and some of the changes that are needed (refactoring to make the UI more easily configurable, for example, and the email interface) are hard to get 'in'. This is mostly hearsay though.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4