Results of the discussion about parameters removal

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

Results of the discussion about parameters removal

Frédéric Buclin
Hi all,

The Bugzilla meeting ended right now with 18 people attending today
(probably a record), and we are going towards the removal of 23
parameters(!). You can see our decisions on this page:

http://wiki.mozilla.org/Bugzilla:Params

We also decided to wait one month, i.e. till our next meeting on October
2, before definitely validating the list. We think this will give all of
you enough time to object if you have a very good reason why we
shouldn't remove some parameters. Note that a few parameters will be
replaced by a constant so that you still have a way to edit them if you
really want to/have to. But most of the ones we want to remove will be
simply killed.

Please do not edit the page itself as it contains the results of our
discussion at the meeting. Probably better is to reply to this email and
keep the discussion in this thread. We will update the list ourselves if
there is a good reason to, based on the discussion we might have per email.

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: Results of the discussion about parameters removal

Joel Peshkin



We should be able to get rid of shadowdbhost, shadowdbsock, shadowdbport.

   shadowdb can be redefined to be the DSN of the database.  So, that can be
    myshadowdb
    database=myshadowdb
    database=myshadowdb;host=myshadowhost
    database=myshadowdb;host=myshadowhost;port=8900
    database=myshadowdb;mysql_socket=/var/mysql.sock
Oracle and Pg seem to support similar syntaxes.

Also, as we move various *group items to groups, we risk cluttering up
the groups UI just as badly.  We should consider reserving the group
names, but not pre-creating them so, if the group isn't defined, the
feature is disabled.



   
-
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: Results of the discussion about parameters removal

Max Kanat-Alexander
On Tue, 04 Sep 2007 15:41:49 -0700 Joel Peshkin <[hidden email]>
wrote:
>    shadowdb can be redefined to be the DSN of the database.  So, that
> can be myshadowdb

        Unfortunately, that just won't work very well with Bugzilla::DB.
The separate parameters are as necessary for shadowdb as they are in
localconfig.

> Also, as we move various *group items to groups, we risk cluttering
> up the groups UI just as badly.  We should consider reserving the
> group names, but not pre-creating them so, if the group isn't
> defined, the feature is disabled.

        I'm more OK with having lots of groups. We can perhaps switch
things around for System Groups at some point so that they display
differently in the UI, but I think reserving but not pre-creating
groups would add a lot of complexity to the code.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And 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: Results of the discussion about parameters removal

Frédéric Buclin
> I'm more OK with having lots of groups. We can perhaps switch
> things around for System Groups at some point so that they display
> differently in the UI

We could have a toggle button to show/hide system groups in the group
list. Doesn't look like a problem to me either.
-
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: Results of the discussion about parameters removal

John Beranek
In reply to this post by Frédéric Buclin
Frédéric Buclin wrote:
> Hi all,
>
> The Bugzilla meeting ended right now with 18 people attending today
> (probably a record), and we are going towards the removal of 23
> parameters(!). You can see our decisions on this page:
>
> http://wiki.mozilla.org/Bugzilla:Params

I wonder how you can make decisions like this without actually polling
your users? Perhaps at least on the support list?

There are far more users of Bugzilla than there are developers that read
this list, and the diversity of those users could certainly mean that
they would have reasons that particular parameters are an absolute
necessity, something which you've not thought of yourself.

I've already brought up possible issues with removing sslbase, and
looking at your list I see others that may cause issues. A particular
one is cookie path - on another project I work on the cookie path was
worked out from the PHP_SELF variable (admittedly different than getting
 it from urlbase in Bugzilla but stick with me), and this caused issues
with a particular setup where the web app was fetched through a proxying
setup, which masked the real path from the actual path. What I had to do
is add a cookie path override config parameter. If Bugzilla were to
remove its cookie path config parameter similar configurations may then
start to fail...not really the friendliest thing to do to the user...

Just my tuppence.

John.

--
John Beranek                         To generalise is to be an idiot.
http://redux.org.uk/                                 -- William Blake

-
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: Results of the discussion about parameters removal

Frédéric Buclin
John Beranek a écrit :
> I wonder how you can make decisions like this without actually polling
> your users? Perhaps at least on the support list?


We already started talking about params per email last week, and as I
said, we give one month to discuss if something should be kept. Without
an initial discussion/decision, it's hard for people to comment.

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: Results of the discussion about parameters removal

Colin Ogilvie
In reply to this post by Frédéric Buclin
Frédéric Buclin wrote:
> Note that a few parameters will be
> replaced by a constant so that you still have a way to edit them if you
> really want to/have to. But most of the ones we want to remove will be
> simply killed.

Shouldn't we find some 'better' way of doing it that doesn't mean having
to edit the file each time you update?
-
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: Results of the discussion about parameters removal

Joel Peshkin
> Frédéric Buclin wrote:
>> Note that a few parameters will be
>> replaced by a constant so that you still have a way to edit them if you
>> really want to/have to. But most of the ones we want to remove will be
>> simply killed.
>
> Shouldn't we find some 'better' way of doing it that doesn't mean having
> to edit the file each time you update?
> -

This sounds like a case where we should provide a file that sets the
defaults so the user can copy to their own location.  So, if we provide
"settings.pl", the user can provide "settings.pl.local" and override those
settings.

This file could look like...


# DO NOT EDIT THIS ORIGINAL FILE (settings.pl)
# Copy this file to settings.pl.local and make changes there

package Settings;   # is there a better way to set a namespace?

# usermatchmode can be search, none, or wildcard
$usermatchmode = 'search';

# cookiepath, if not specified will be inferred from urlbase
# $cookiepath = '/';

# ...etc...
1;



-
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: Results of the discussion about parameters removal

Frédéric Buclin
Note that only 2 params will be replaced by a constant. The other 21
params will be removed. Not sure we want to implement settings.pl.local
for 2 exceptions only.

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: Results of the discussion about parameters removal

Colin Ogilvie
Frédéric Buclin wrote:
> Note that only 2 params will be replaced by a constant. The other 21
> params will be removed. Not sure we want to implement settings.pl.local
> for 2 exceptions only.
>  

Not sure we should remove them then... if they are the ones we are
expecting people to want to change (by providing a constant) we should
give them the scope without breaking upgrades for them.

Colin
-
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: Results of the discussion about parameters removal

Max Kanat-Alexander
On Wed, 05 Sep 2007 17:06:55 +0100 Colin Ogilvie
<[hidden email]> wrote:
> Not sure we should remove them then... if they are the ones we are
> expecting people to want to change (by providing a constant) we
> should give them the scope without breaking upgrades for them.

        We are expecting an extremely minor fraction of installations
to change them. Thus constants are acceptable.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And 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: Results of the discussion about parameters removal

Colin Ogilvie
Max Kanat-Alexander wrote:
> We are expecting an extremely minor fraction of installations
> to change them. Thus constants are acceptable.
>  

Based on what evidence? Do we know how many installations have
customised them?

Surely the goal is to make it easier for people to upgrade -- forcing
them to change something that we ship, and could (potentially) break
their upgrade path seems to me to be a VERY bad idea.

Colin

-
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: Results of the discussion about parameters removal

Max Kanat-Alexander
On Wed, 05 Sep 2007 21:00:00 +0100 Colin Ogilvie
<[hidden email]> wrote:
> Based on what evidence? Do we know how many installations have
> customised them?

        I personally have installed and configured Bugzilla at many
different organizations. LpSolit, myself, and the other developers
involved in the discussion have also been providing Bugzilla support to
many, many people for many, many years.

> Surely the goal is to make it easier for people to upgrade -- forcing
> them to change something that we ship, and could (potentially) break
> their upgrade path seems to me to be a VERY bad idea.

        The goal is to make our code simpler and the UI easier to use.
If only a tiny fraction of people are using the parameters, making life
ever-so-slightly difficult for that tiny fraction is OK as long as we
note it in the Release Notes.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla Services. And 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: Results of the discussion about parameters removal

Colin Ogilvie
Max Kanat-Alexander wrote:
> The goal is to make our code simpler and the UI easier to use.
> If only a tiny fraction of people are using the parameters, making life
> ever-so-slightly difficult for that tiny fraction is OK as long as we
> note it in the Release Notes.
>  

Moving two parameters to a constant doesn't seem worth it - it won't
make the code any simpler (since the parameters will still exist) and I
doubt it will make the UI any easier to use... and if the UI being
easier to use is an argument for removing two parameters then I would
suggest that we have more important things to be worrying about.

Colin


-
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: Results of the discussion about parameters removal

Joel Peshkin
In reply to this post by Max Kanat-Alexander

Actually, I think that
a) we should have checksetup warn users if they had non-default settings
for any parameters that are going away.
b) I have used wildcard usermatchmode (rather than search) at several
sites and it has been required.



> On Wed, 05 Sep 2007 21:00:00 +0100 Colin Ogilvie
> <[hidden email]> wrote:
>> Based on what evidence? Do we know how many installations have
>> customised them?
>
> I personally have installed and configured Bugzilla at many
> different organizations. LpSolit, myself, and the other developers
> involved in the discussion have also been providing Bugzilla support to
> many, many people for many, many years.
>



-
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: Results of the discussion about parameters removal

Gervase Markham
In reply to this post by Frédéric Buclin
Frédéric Buclin wrote:
> http://wiki.mozilla.org/Bugzilla:Params

Is discussion continuing here on the list, or on the wiki?

We should rename "Required Settings" to something else, because none are
Required any more.

Gerv
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>