self-intro: Craig Sebenik

[Craig]

Frédéric Buclin wrote:
> Craig a écrit :
>>>>    - move all of data/params into the DB (???)
> 
> I'm currently against this idea. I have two use cases in mind right now:
> 
> 1) When moving your Bugzilla installation to a new web server, you have 
> to edit urlbase and sslbase first, to point to the new server. If you 
> forget to do this on time, Bugzilla redirects you to the old web server 
> and you can never update these parameters from the UI. In this case, 
> it's much easier to edit data/params with a text editor than to type SQL 
> commands.

Ok. What if there was a CLI to update the necessary values? This isn't 
an ideal situation...

> 2) When Bugzilla is down (e.g. for maintenance), you still want the 
> content of the shutdownhtml parameter to be displayed, even if the DB 
> server is down, see https://bugzilla.mozilla.org/show_bug.cgi?id=398075. 
> This parameter must then be kept outside the DB.

Good point. (I forgot about this parameter.) One could argue that this 
is, essentially, a "database connection parameter". If it's true, then 
ignore the rest of the DB settings.


> And having parameters in two different places is a bad idea, offers no 
> benefit and increases complexity.

Totally agree! If the data/params cannot be moved into the DB, can we 
move "setting" and "setting_value" out of the DB and into data/params?

=========================

Ok, let me back up a little. My basic problem is that there is some data 
in the DB and some other in the filesystem. This is a bit of a pain to 
backup. (How we backup the DB is significantly different than any kind 
of filesystem backups.) Also, with some data in the files, doing 
upgrades are more difficult than they have to be (IMHO). If the "config" 
was outside of the "app home", then this wouldn't be so bad. But, we 
can't just download a new version, drop it in, run "checksetup.pl" and 
everything is up. *Ideally*, all of the data and config would be in one 
place. When I was new to bz, I had to upgrade an existing install and 
forgot data/params. Admittedly, we can't prevent any/all stupids 
mistakes. Just trying to make the upgrade process easier. I thought that 
moving the params into the DB was going to be a simple thing, since 
several are already in there. It sounds like it's going to create more 
problems than solve...



> No, we don't want to interact with the DB when doing l10n. The DB is not 
> the right place to add human readable text.

Fair enough. I had an issue when trying to add a "custom field". I read 
the page about customizing bz and it mentioned that you should "co-opt" 
a field before creating a "custom field". We used "rep_platform". We 
changed the row in fielddefs, but then had to change 2 files to update 
various help pages:
	template/en/default/search/search-help.html.tmpl
	template/en/default/pages/fields.html.tmpl

It was a little tedious. At the very least, the admin pages should allow 
one to update those values. I was merely thinking that by putting it in 
the DB it would be easier to manage. But, the truth is that I jsut am 
looking for an easier way to update all necessary pieces of data when 
changing a field.

Craig