Simpler Bugzilla

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Simpler Bugzilla

Gervase Markham
I had someone complaining to me recently that Bugzilla's UI was too
complicated. I said that some people needed all those fields; he replied
that still, there was no need to show them by default.

Is it worth us considering whether we want to make default Bugzilla use
fewer fields? Are there some switchable ones turned on by default that
we could turn off? Or can we put a few more hard-coded ones inside [% IF
%] blocks to make them switchable?

Also, chatting with Myk over lunch, a couple of things that would make
installation simpler:

- We could support and ship with SQLite. I suspect it would be all that
90% of installations needed, and removes the need to set up and
configure MySQL or PgSQL.

- We could ship with a simple Perl webserver or lighttpd, which removes
the need to set up and configure Apache. We don't use many advanced
webserver features; as long as it obeys .htaccess files, we should be fine.

With these two features, installing Bugzilla would be a case of:

- Download and unpack
- Run the module install script
- Do first-run config in the GUI like your SMTP server name
- Done.

Not even any localconfig, as far as I can see.

What do people think?

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Guy Pyrzak
I agree 100% with both points, fewer fields and easier install. That's a big problem with bugzilla and why many people don't want to use it. Some folks could care less about the default fields that we give. In the end i think the only fields that should appear by default are the ones bugzilla needs to function.

However, part of this conversion also has to be making it easier to use custom fields as well since people will invariably use those to create fields that they need.

As far as easier shipping, I'd like to think the LAMP framework is kind standard, however, talking to people in the chat rooms the P in lamp tends to stand for PHP not perl and that's where people get tripped up.

I do think that overall the UI for Bugzilla could be simplified so that the advanced features are there but they don't get in the way so much. I've had this discussion with max a few times.

I'm not convinced that having bugzilla ship with mysql-lite and a perl will fix the problem, but it is an interesting idea.

-Guy


On Fri, Jul 25, 2008 at 3:51 PM, Gervase Markham <[hidden email]> wrote:
I had someone complaining to me recently that Bugzilla's UI was too
complicated. I said that some people needed all those fields; he replied
that still, there was no need to show them by default.

Is it worth us considering whether we want to make default Bugzilla use
fewer fields? Are there some switchable ones turned on by default that
we could turn off? Or can we put a few more hard-coded ones inside [% IF
%] blocks to make them switchable?

Also, chatting with Myk over lunch, a couple of things that would make
installation simpler:

- We could support and ship with SQLite. I suspect it would be all that
90% of installations needed, and removes the need to set up and
configure MySQL or PgSQL.

- We could ship with a simple Perl webserver or lighttpd, which removes
the need to set up and configure Apache. We don't use many advanced
webserver features; as long as it obeys .htaccess files, we should be fine.

With these two features, installing Bugzilla would be a case of:

- Download and unpack
- Run the module install script
- Do first-run config in the GUI like your SMTP server name
- Done.

Not even any localconfig, as far as I can see.

What do people think?

Gerv


_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak@...>

Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Frédéric Buclin
In reply to this post by Gervase Markham
Gervase Markham a écrit :
> - We could support and ship with SQLite. I suspect it would be all that
> 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.
>
> - We could ship with a simple Perl webserver or lighttpd, which removes
> the need to set up and configure Apache.


I'm not sure installing MySQL and Apache is such a big deal, even on
Windows. The first time I had to install both on Windows, I could do it
without any problem. Their respective executables (.exe) are easy enough
to use to do it in a few minutes. Also, the most difficult part to
install is Perl, not the other two above, IMO.

Related bugs and discussions:

- SQLite: https://bugzilla.mozilla.org/show_bug.cgi?id=337776
- lighttpd: https://bugzilla.mozilla.org/show_bug.cgi?id=415529

Now a few questions:
- does SQLite support UTF8 and transactions?
- does lighttpd support mod_perl?


About the UI, there is nothing new here. We already had this discussion
several times on IRC, especially with mkanat and pyrzak (and again no
later than yesterday, with pyrzak). We have several ideas in mind; just
waiting to have the time to implement them.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Atsushi Shimono
  hi, LpSolit

On Sat, Jul 26, 2008 at 7:40 PM, Frédéric Buclin <[hidden email]> wrote:
> Now a few questions:
> - does SQLite support UTF8 and transactions?

  utf8 might be yes. (Unicode supported)
  transactions, yes. with thread-safe but re-build is needed at some binary
distributions.

> - does lighttpd support mod_perl?

  i don't know about mod_perl, but i think it supports FastCGI.

  regards,
--
Atsushi Shimono - [hidden email]
 http://www.mozilla.gr.jp/~shimono/blog/
 Mozilla-Gumi : Japanese Mozilla Users Group / System Administrator
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Frédéric Buclin
Atsushi Shimono a écrit :
>> - does SQLite support UTF8 and transactions?
>
>   utf8 might be yes. (Unicode supported)
>   transactions, yes. with thread-safe but re-build is needed at some binary
> distributions.

I just visited http://www.sqlite.org/omitted.html which says foreign
keys are not supported. This is a problem as our code now assumes these
constraints to be enforced, especially on deletion.


LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

bill barry
Frédéric Buclin wrote:
>
> I just visited http://www.sqlite.org/omitted.html which says foreign
> keys are not supported. This is a problem as our code now assumes
> these constraints to be enforced, especially on deletion.
Foreign keys can be mocked using triggers.

The biggest problem with supporting sqlite is its concurrency model.
Multiple connections can read at the same time, but only one connection
can connect to the entire database (the whole db is write locked) when
writing. That severely limits the number of concurrent users of Bugzilla.

A better path for Bugzilla might be to work towards a completely
abstracted migration/installation database library (DBMI? *note). Once
that is done, it would be able to support any database where a migration
implementation (DBMD?) exists and a DBD implementation exists

note:
As a disclaimer, I have no idea how migrations are working in bugzilla
at the moment, nor have I searched in Bugzilla for anything like this. I
have only done rudimentary searching on cpan and come up with
DBIx::Migrations::Directory, but I don't think that is a good solution
as it requires sql scripts for each migration for each supported
database. I was thinking something more along the lines of migrator.net
(http://code.google.com/p/migratordotnet/) which abstracts away the sql
that runs in order to support multiple databases with a single migration
script.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Jochen Wiedmann
In reply to this post by Gervase Markham
On Sat, Jul 26, 2008 at 12:51 AM, Gervase Markham <[hidden email]> wrote:

> Is it worth us considering whether we want to make default Bugzilla use
> fewer fields? Are there some switchable ones turned on by default that
> we could turn off? Or can we put a few more hard-coded ones inside [% IF
> %] blocks to make them switchable?

I know that in particular the search UI is/was deterrent for a lot of
users. The "simple search" was a great help, but the "advanced search"
could do with renaming to "expert search" and the addition of someting
in between. Apart from the search, I only heard complaints about the
bug editing UI, but the primary candidates for removal there are
already configurable via parameters.


> - We could support and ship with SQLite. I suspect it would be all that
> 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.

That would sure be nice. OTOH, it might make upgrades more difficult.
And, apart from that, I do personally believe that the most important
problem is not the setup but the myriad of Perl modules. The changes
in the email system for 3.0 haven't been exactly helpful there. I do
not know so much about Perl than I used to do, in particular, I do not
know whether there is an equivalent to the Java jar files today, but
an included delivery of the required/optional modules would help.
Perhaps in a separate directory, where you can very easily switch them
off, and perhaps including the Pure-Perl modules only.


> - We could ship with a simple Perl webserver or lighttpd, which removes
> the need to set up and configure Apache. We don't use many advanced
> webserver features; as long as it obeys .htaccess files, we should be fine.

I do not know how the reality on the user lists look alike, but
personally I never considered that as painful.


> With these two features, installing Bugzilla would be a case of:
>
> - Download and unpack
> - Run the module install script
> - Do first-run config in the GUI like your SMTP server name
> - Done.
>
> Not even any localconfig, as far as I can see.
>
> What do people think?

About the localconfig: I am always impressed by the setup of systems
like typo3, drupal, egroupware, mediawiki: The system detects whether
it is a first time installation (usually because some config file is
missing) and provides a UI for the first time installation. I would
recommend to think in that direction instead.

Of course, a complete distribution would be nice, but I think it is
realistic for Windows only. Apart from that, that's something you can
leave to interesting individuals and not necessarily a task for the
whole community.


Jochen


--
Look, that's why there's rules, understand? So that you think before
you break 'em.

 -- (Terry Pratchett, Thief of Time)
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Max Kanat-Alexander
In reply to this post by bill barry
On Sat, 26 Jul 2008 10:25:13 -0600 Bill Barry <[hidden email]>
wrote:
> The biggest problem with supporting sqlite is its concurrency model.
> Multiple connections can read at the same time, but only one
> connection can connect to the entire database (the whole db is write
> locked) when writing. That severely limits the number of concurrent
> users of Bugzilla.

        That's fine. We wouldn't expect large installs to use SQLite,
we would tell them to use a real DB server.

> A better path for Bugzilla might be to work towards a completely
> abstracted migration/installation database library (DBMI? *note).

        SQL::Translator, I have a bug filed about it somewhere.

        -Max
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Max Kanat-Alexander
In reply to this post by Jochen Wiedmann
On Sat, 26 Jul 2008 20:00:07 +0200 "Jochen Wiedmann"
<[hidden email]> wrote:
> I know that in particular the search UI is/was deterrent for a lot of
> users. The "simple search" was a great help, but the "advanced search"
> could do with renaming to "expert search" and the addition of someting
> in between. Apart from the search, I only heard complaints about the
> bug editing UI, but the primary candidates for removal there are
> already configurable via parameters.

        I think search would be greatly improved by making it work a
bit like iTunes (or Rhythmbox, which I'm used to) filters, where you
have a limited list of fields in one drop-down, and then a second box
for the "operator" (which could also be a more limited list than we
have in the Boolean Charts) and then a text box for the criteria.

        In a sense, like a Boolean Charts but simplified. Also, for
<select> fields (like product, component, etc), the "text box" could
become a drop-down that only contains valid choices.

> That would sure be nice. OTOH, it might make upgrades more difficult.

        No, I know how to make upgrades fully possible with
SQLLite--they'll just be slow. But that's fine, we expect SQLite to be
easy, not fast.

> And, apart from that, I do personally believe that the most important
> problem is not the setup but the myriad of Perl modules.

        See install-module.pl in the 3.2 branch.

> About the localconfig: I am always impressed by the setup of systems
> like typo3, drupal, egroupware, mediawiki:

        All not written in Perl...

> The system detects whether
> it is a first time installation (usually because some config file is
> missing) and provides a UI for the first time installation. I would
> recommend to think in that direction instead.

        I worked on this for a while, and I decided that it didn't
actually have any benefit for our users over checksetup.pl, at least
not enough benefit to justify the added complexity.

        However, we could quiz people for the essential localconfig
data, instead of making them edit the file, on a new install.

> Of course, a complete distribution would be nice, but I think it is
> realistic for Windows only. Apart from that, that's something you can
> leave to interesting individuals and not necessarily a task for the
> whole community.

        I think the best solution for non-Windows is the VM images that
people distribute that already have Bugzilla working on them.

        -Max
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Max Kanat-Alexander
In reply to this post by Gervase Markham
On Fri, 25 Jul 2008 15:51:03 -0700 Gervase Markham <[hidden email]>
wrote:
> I had someone complaining to me recently that Bugzilla's UI was too
> complicated. I said that some people needed all those fields; he
> replied that still, there was no need to show them by default.

        Sometimes more fields actually makes life simpler, because it
allows better data organization.

        We've improved the UI for 3.2, also.

> Is it worth us considering whether we want to make default Bugzilla
> use fewer fields? Are there some switchable ones turned on by default
> that we could turn off? Or can we put a few more hard-coded ones
> inside [% IF %] blocks to make them switchable?

        We have bugs for this, I'm pretty sure.

        op_sys and platform should be made into custom fields and
should be moved into a plugin (so that they can maintain their magic
"auto-select what the browser tells us" functionality).

> - We could support and ship with SQLite. I suspect it would be all
> that 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.

        Yes, there's a bug for that and I was working on it.

> - We could ship with a simple Perl webserver or lighttpd, which
> removes the need to set up and configure Apache. We don't use many
> advanced webserver features; as long as it obeys .htaccess files, we
> should be fine.

        "Obeys .htaccess files" is the tricky (or perhaps impossible)
part there.

        -Max
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Emmanuel Seyman
In reply to this post by Gervase Markham
* Gervase Markham [26/07/2008 04:15] :
>
> Is it worth us considering whether we want to make default Bugzilla use
> fewer fields? Are there some switchable ones turned on by default that
> we could turn off? Or can we put a few more hard-coded ones inside [% IF
> %] blocks to make them switchable?

Just so that we're on the same wavelength, the switchable fields are:

bugaliases
classification
qacontact
statuswhiteboard
targetmilestone
votes (enabled by default in 3.0)

Gerv, did the person you were talking to tell you which fields
he had in mind?

Emmanuel
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Frédéric Buclin wrote:
> I'm not sure installing MySQL and Apache is such a big deal, even on
> Windows.

They may not be, but sometimes a long list of requirements is enough to
put people off. It would be interesting to see if we could get hard data
on what people found most difficult.

> Related bugs and discussions:
>
> - SQLite: https://bugzilla.mozilla.org/show_bug.cgi?id=337776
> - lighttpd: https://bugzilla.mozilla.org/show_bug.cgi?id=415529
>
> Now a few questions:
> - does SQLite support UTF8 and transactions?

UTF8, I'm sure. Mozilla uses it, and it's fully internationalizable.
Transactions, yes: http://www.sqlite.org/lang_transaction.html

> - does lighttpd support mod_perl?

Probably not, but most people don't need it. If you want mod_perl,
install Apache.

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Max Kanat-Alexander wrote:
> Sometimes more fields actually makes life simpler, because it
> allows better data organization.

I think Joel's piece about custom fields addresses that view. I assume
you've read it; what do you think of it?

> Yes, there's a bug for that and I was working on it.

Cool! :-)

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Emmanuel Seyman wrote:
> Gerv, did the person you were talking to tell you which fields
> he had in mind?

Nope. But perhaps we could look at what we provide that Trac doesn't,
and use that as a starting point for discussion :-)

Gerv
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Max Kanat-Alexander
In reply to this post by Gervase Markham
On Wed, 30 Jul 2008 21:53:03 -0700 Gervase Markham <[hidden email]>
wrote:
> Max Kanat-Alexander wrote:
> > Sometimes more fields actually makes life simpler, because
> > it allows better data organization.
>
> I think Joel's piece about custom fields addresses that view. I assume
> you've read it; what do you think of it?

        It's sort of a sliding scale. Allowing people to add any field
they want can make a bug-tracker too complex. Having too few built-in
fields can also make a bug-tracker too difficult to use.

        The ideal is to figure out the exact data model that's needed
and present it in the most user-friendly fashion.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Emmanuel Seyman
In reply to this post by Gervase Markham
* Gervase Markham [31/07/2008 07:03] :
>
> Nope. But perhaps we could look at what we provide that Trac doesn't,
> and use that as a starting point for discussion :-)

Let's start with bug entry, then.

Fields that Trac doesn't ask on bug entry that Bugzilla does :

- OS
- Hardware
- URL
- Initial State
- Depends on
- Blocks

OS and Hardware, we've talked about.
URL could easily be activated by a 'useurl' params.
Removing Initial state would be a regression more than anything else.
Depends on and Blocks, I'm torn about.

Emmanuel
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Guy Pyrzak
So while I'm happy that there is an interest in the simplification. And i have yet to find anyone who thinks it is a bad idea, and I think most of us are in agreement that the solution is to make the "default" fields into custom fields. However, the problem is the lack of people with the time to implement the changes. We could supply a bunch of mocks that simplify the UI etc, but we'll need some folks (more than me) to implement them, which it seems like we're lacking.

If there isn't a meta bug for this already lets start one and start filing some bugs. I'll be happy to supply multiple mocks of various ideas that people on this list have as well as my own, but I want to know who is willing to help implement these changes?

-Guy

On Mon, Aug 4, 2008 at 12:32 AM, Emmanuel Seyman <[hidden email]> wrote:
* Gervase Markham [31/07/2008 07:03] :
>
> Nope. But perhaps we could look at what we provide that Trac doesn't,
> and use that as a starting point for discussion :-)

Let's start with bug entry, then.

Fields that Trac doesn't ask on bug entry that Bugzilla does :

- OS
- Hardware
- URL
- Initial State
- Depends on
- Blocks

OS and Hardware, we've talked about.
URL could easily be activated by a 'useurl' params.
Removing Initial state would be a regression more than anything else.
Depends on and Blocks, I'm torn about.

Emmanuel
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=guy.pyrzak@...>

Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Frédéric Buclin
Guy Pyrzak a écrit :
> If there isn't a meta bug for this already lets start one and start filing
> some bugs.

We already have bugs for that. Just query b.m.o a bit. ;)

LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

"Andrés G. Aragoneses"
In reply to this post by Gervase Markham
I hope this thread isn't dead yet. See inline:

Gervase Markham wrote:

> I had someone complaining to me recently that Bugzilla's UI was too
> complicated. I said that some people needed all those fields; he replied
> that still, there was no need to show them by default.
>
> Is it worth us considering whether we want to make default Bugzilla use
> fewer fields? Are there some switchable ones turned on by default that
> we could turn off? Or can we put a few more hard-coded ones inside [% IF
> %] blocks to make them switchable?
>
> Also, chatting with Myk over lunch, a couple of things that would make
> installation simpler:
>
> - We could support and ship with SQLite. I suspect it would be all that
> 90% of installations needed, and removes the need to set up and
> configure MySQL or PgSQL.
>
> - We could ship with a simple Perl webserver or lighttpd, which removes
> the need to set up and configure Apache. We don't use many advanced
> webserver features; as long as it obeys .htaccess files, we should be fine.
>
> With these two features, installing Bugzilla would be a case of:
>
> - Download and unpack
> - Run the module install script
> - Do first-run config in the GUI like your SMTP server name
> - Done.

I don't agree that changing the product architecture is the solution of
a packaging problem. What I would encourage is to fix this RFE:

https://bugzilla.mozilla.org/show_bug.cgi?id=369200

(In case you don't know, OBS is cross-distro.)


By generating cross-distro RPMs, installing Bugzilla would be a case of:

- Select Bugzilla on your package manager and install it.
- Run Bugzilla locally in a browser and configure it.
- Ready.

> Not even any localconfig, as far as I can see.


Of course, hand-editing files are not the friendliest way of
configuration methodology for this type of solution, so I guess we
should firstly rework the side mentioned by Jochen Wiedmann: web-based
UI for initial configuration, like other products already have (drupal,
mediawiki...).

It's possible that some people at Novell Inc are going to target on this
packaging work for the upcoming hackweek, so any help on the web UI will
be appreciated (and of course, we're willing to know if this is
desirable in the bugzilla devs community).

Regards,

        Andrés

--
_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=$MSGRCPT>
Reply | Threaded
Open this post in threaded view
|

Re: Simpler Bugzilla

Max Kanat-Alexander
On Mon, 11 Aug 2008 19:16:11 +0200 "Andrés G. Aragoneses"
<[hidden email]> wrote:
> By generating cross-distro RPMs, installing Bugzilla would be a case
> of:

        Fedora already has an RPM for Bugzilla, meaning that EPEL (for
RHEL) also has one. They're very good about keeping it up-to-date. I
think that other distros also have an RPM.

        An RPM wouldn't cover Debian or Ubuntu (though they have a
package...but it's out-of-date, as I recall).

        An RPM also wouldn't cover Mac or Windows.

        So the only big distros who would benefit would be SuSE and
Mandriva.

> web-based UI for initial configuration, like other products already
> have (drupal, mediawiki...).

        No, I tried developing it and it wasn't worth the effort and
complexity it would add to installation. See these two bugs for
details:

        https://bugzilla.mozilla.org/show_bug.cgi?id=270066
        https://bugzilla.mozilla.org/show_bug.cgi?id=389845

Probably a better solution is just to ask people for info during
checksetup (like their MySQL root password) and just set up everything
else automatically.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
12