FreeLists / haiku-web / [haiku-web] Re: Trac (reevaluated)

[Waldemar Kornewald <wkornew@xxxxxxx>]

Charlie Clark wrote:
> No problem with that. We wanted to work on this at BeGeistert but for
> various reasons couldn't. What we do need is an export of the existing
> Bugzilla database. As Michael has indicated the core developers are happy
> with the current setup.

Sorry, I don't have any server access. Michael, could you please give 
Charlie
and/or me the login or create an account? Well, or a sample DB...

About Bugzilla's component organization: it must be improved. I don't like the
current scheme because it's not *absolutely* obvious which top-level category
to choose (Servers vs Kits? Kits vs Shared Libraries? Applications vs
Preferences vs Tools)? I prefer a categorization scheme that is clearly
separated by *function*. Instead of Servers and Kits we should rather have
Media, User Interface, Networking, etc.. Now, if we get multi-level categories
we can add the actual server *below* the top-level category.

I'm just not 100% sure if multi-level categories won't lead to
over-categorization. I mean, did we even try a one-level scheme? At least, I
can say for use that the current Bugzilla system is *less* effective than a
good one-level system. I like the current summary scheme where people enter,
for example:
Summary: "[BListView] distortions on scrolling"
It's very annoying to manually add every little new app (or growing task) that
we include in our repos to the category list and we can't list all possible
drivers and command-line apps, etc. This summary scheme is a lot more 
flexible,
but still allows a team-wise separation, so tickets don't interfere with each
other (e.g.: Media with Networking). I mean, even Bugzilla's two-level
categorization doesn't seem to handle tickets more effectively than a simple
one-level scheme. If you look at mozilla.org you will see that they have more
items in their lists than a normal human wants to handle. It's overkill and
ineffective.
Let's first try to go the simple route. We can extend it later, but 
let's first
import the repos and convert it into a one-level categorization scheme. At
first, we only need a few bugs&tasks, so our developers can play with it and
say "yeah, it's nice!" or "no way! too ineffective!". I volunteer to do this
stupid conversion work.
It means a lot to me to get *everything* right. I want our users to get the
impression that everything we do is easy to use and effective. Perfect! Guys,
please give me a chance. Maybe it sounds stupid and unimportant to you. IMHO,
this is extremely important for marketing and our reputation. People must feel
very comfortable with the website as a whole before they consider installing
and *keeping* Haiku. My goal for R2 is to reach more people than only
developers and OS-lovers. By the time the website is ready we will probably
release R1 beta, so I don't think that I'm planning too far into the future.
Yes, I have strong feelings about this website project. :)

> Mikael, I think the best thing is if I give you access to my server and let
> you have the root password. This will let you set up Trac and svn.

Would it be possible for me to help with a few simple tasks? Or will you 
find
enough time to do it, so I can concentrate on the new website's content.

> Regarding the core issue of users - Trac I suspect was initally setup to
> work with existing svn users which is why the default doesn't have them.
> However, the even though replacement using sessions is simply sick I am not
> sure whether my model will ever be accepted into trunk. My version do not
> allow anonymous users to create anything.

Too bad. Personally, I prefer if anonymous users *can't* create/modify 
anything,
but if that stops adoption by the Trac team I'd rather take something that is
maintained by a whole community (as oppsed to only you, Charlie).

Bye,
Waldemar Kornewald


-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List