From gerv at mozilla.org  Mon Jan  3 13:27:04 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 03 Jan 2005 13:27:04 +0000
Subject: Security release needed
Message-ID: <41D94828.3090500@mozilla.org>

Developers,

Vladd has pointed out that security bug 272620 is now public knowledge, 
having been posted to Bugtraq before Christmas.
https://bugzilla.mozilla.org/show_bug.cgi?id=272620
So we need to do a security release. It's an XSS problem, so it's not as 
if attackers can drop the database, but we need to get moving.

2.16.8 is ready to go - there are two security patches to check in.
2.18.0 has the blocker list we all know about. See Jake's weblog.
2.19.2 could go at any time, really - it's just a development release.

I just posted the following idea in bug
https://bugzilla.mozilla.org/show_bug.cgi?id=108870
which is our last remaining major 2.18 blocker. Please let me know what 
you think.

<snip>

I understand the following things to be true:

- We need to do a security release ASAP (because of bug 272620)
- It would be good if that release was 2.18 final as well.
- This is the major remaining bug for 2.18 final.
- If you check this patch in on the tip, it'll break my patch for 73665,
   which would be annoying.

So here's what I suggest:

- You write and review a patch here for the 2.18 branch *only*, and
   check it in ASAP.
- We release 2.16.8, which has nothing to do with this patch
- We release 2.18 final, with this patch
- We release 2.19.2, without this patch
- We all breathe a sigh of relief
- Max and I try and get bug 73665 done before we branch for 2.20
- If we succeed, fine. If we fail, we revive this patch for the 2.20
   branch also, at that point.

This plan seems to me to be the quickest way to get 2.18 and the 
security releases out of the door. What do you think?

Gerv


From justdave at bugzilla.org  Mon Jan  3 18:28:31 2005
From: justdave at bugzilla.org (David Miller)
Date: Mon, 03 Jan 2005 13:28:31 -0500
Subject: Security release needed
In-Reply-To: <41D94828.3090500@mozilla.org>
References: <41D94828.3090500@mozilla.org>
Message-ID: <41D98ECF.3090506@bugzilla.org>

Gervase Markham wrote:

> 2.16.8 is ready to go - there are two security patches to check in.
> 2.18.0 has the blocker list we all know about. See Jake's weblog.
> 2.19.2 could go at any time, really - it's just a development release.

There will be no 2.19.2.  We're releasing 2.20rc1 concurrently with 2.18 
final, at which point we branch.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Mon Jan  3 19:08:36 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 03 Jan 2005 19:08:36 +0000
Subject: Security release needed
In-Reply-To: <41D98ECF.3090506@bugzilla.org>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org>
Message-ID: <41D99834.5070903@mozilla.org>

David Miller wrote:
> Gervase Markham wrote:
> 
>> 2.16.8 is ready to go - there are two security patches to check in.
>> 2.18.0 has the blocker list we all know about. See Jake's weblog.
>> 2.19.2 could go at any time, really - it's just a development release.
> 
> There will be no 2.19.2.  We're releasing 2.20rc1 concurrently with 2.18 
> final, at which point we branch.

In an ideal world, we would definitely do that. However, given that the 
bug in question is public knowledge, we need to get a security release 
out ASAP, as in "today or tomorrow". That means releasing from all three 
trees. So, there are several reasons why it might not be the best idea 
to branch and release 2.20rc1 at the same time:

- It's more complicated, and so will take longer and divide effort
- There are significantly more bugs marked as blocking2.20+ than there
   are blocking2.18+, and we shouldn't do a Release Candidate unless the
   build is a release candidate, which means fixing them all
- It requires doing the bug 108870 patch for both 2.18 and 2.20, which
   will also delay things
- There is a higher level of expectation for an "rc" release than a
   development release, which I'm not sure we're in a position to meet
   yet.
- Max hasn't reviewed bug 73665 yet ;-)

What's the objection to doing a 2.19.2, apart from the fact that we 
didn't plan to?

Gerv


From preed at sigkill.com  Mon Jan  3 19:21:36 2005
From: preed at sigkill.com (J. Paul Reed)
Date: Mon, 3 Jan 2005 11:21:36 -0800
Subject: Security release needed
In-Reply-To: <41D99834.5070903@mozilla.org>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org> <41D99834.5070903@mozilla.org>
Message-ID: <20050103192136.GA22436@sigkill.com>

On 03 Jan 2005 at 19:08:36, Gervase Markham arranged the bits on my disk to say:

> David Miller wrote:
> >Gervase Markham wrote:
> >
> >>2.16.8 is ready to go - there are two security patches to check in.
> >>2.18.0 has the blocker list we all know about. See Jake's weblog.
> >>2.19.2 could go at any time, really - it's just a development release.
> >
> >There will be no 2.19.2.  We're releasing 2.20rc1 concurrently with 2.18 
> >final, at which point we branch.
> 
> In an ideal world, we would definitely do that. However, given that the 
> bug in question is public knowledge, we need to get a security release 
> out ASAP, as in "today or tomorrow". 

You *JUST* said "2.19.2 could go at any time, really - it's just a
development release."

And now, it has to go out "today or tomorrow?"

Which is it?

And if it is "just a development release," why does it have to go out
"today or tomorrow?"

Later,
Paul
------------------------------------------------------------------------
J. Paul Reed -- 0xDF8708F8 || preed at sigkill.com || web.sigkill.com/preed
Math, my dear boy, is nothing more than the lesbian sister of biology.
                                            -- Peter Griffin, Family Guy

I use PGP; you should use PGP too... if only to piss off John Ashcroft


From justdave at bugzilla.org  Mon Jan  3 19:21:52 2005
From: justdave at bugzilla.org (David Miller)
Date: Mon, 03 Jan 2005 14:21:52 -0500
Subject: Security release needed
In-Reply-To: <41D99834.5070903@mozilla.org>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org> <41D99834.5070903@mozilla.org>
Message-ID: <41D99B50.40408@bugzilla.org>

Gervase Markham wrote:

> - It's more complicated, and so will take longer and divide effort
> - There are significantly more bugs marked as blocking2.20+ than there
>   are blocking2.18+, and we shouldn't do a Release Candidate unless the
>   build is a release candidate, which means fixing them all

> What's the objection to doing a 2.19.2, apart from the fact that we 
> didn't plan to?

The fact that we were ready to call it 2.20rc1 when we released 2.19.1, 
and the only reason we didn't is because 2.18 hadn't been released yet. 
  The fact that we've discovered so many new blockers since then worries 
me.  Perhaps some of them shouldn't be.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Mon Jan  3 19:51:20 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 03 Jan 2005 19:51:20 +0000
Subject: Security release needed
In-Reply-To: <20050103192136.GA22436@sigkill.com>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org> <41D99834.5070903@mozilla.org> <20050103192136.GA22436@sigkill.com>
Message-ID: <41D9A238.90004@mozilla.org>

J. Paul Reed wrote:
> You *JUST* said "2.19.2 could go at any time, really - it's just a
> development release."
> 
> And now, it has to go out "today or tomorrow?"
> 
> Which is it?
> 
> And if it is "just a development release," why does it have to go out
> "today or tomorrow?"

Because we are doing a security release, we have to release all three at 
the same time. (That's been the practice in the past, at any rate.) I 
would like this to happen "today or tomorrow", and am looking for the 
best ways to make that happen. 2.16.8 is ready to go. 2.19.2 is ready to 
go. If we all work hard, we can make 2.18 final ready to go today or 
tomorrow.

A release called 2.19.2 could go out at any time, as I stated, because 
it's "just a development release". But I don't think we are ready for a 
release called 2.20rc1, for the reasons I gave in my last mail.

Apologies if this wasn't clear first time round.

Gerv


From jake at bugzilla.org  Tue Jan  4 12:23:59 2005
From: jake at bugzilla.org (Jake)
Date: Tue, 04 Jan 2005 07:23:59 -0500
Subject: Security release needed
In-Reply-To: <41D99834.5070903@mozilla.org>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org> <41D99834.5070903@mozilla.org>
Message-ID: <41DA8ADF.8040206@bugzilla.org>

Gervase Markham wrote:

> - There are significantly more bugs marked as blocking2.20+ than there
>   are blocking2.18+, and we shouldn't do a Release Candidate unless the
>   build is a release candidate, which means fixing them all

I think this is the most compelling reason. A "Release Candidate" 
implies that if there are no major issues found, this will be the 
release. In a perfect world, the only change from, for example, 1.0rc1 
and 1.0 would be a version number. To have known bugs that we want fixed 
before a release takes place seems backwards. Our criteria should be 
only slightly lower for an rc as it is for a full blown release. I 
understand that there's some "cool stuff" that wants to appear on the 
trunk but can't because of the 2.20 freeze, but we also need to focus on 
the task at hand (eg, getting the current release out the door).


From justdave at bugzilla.org  Tue Jan  4 12:42:21 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 04 Jan 2005 07:42:21 -0500
Subject: Security release needed
In-Reply-To: <41DA8ADF.8040206@bugzilla.org>
References: <41D94828.3090500@mozilla.org> <41D98ECF.3090506@bugzilla.org> <41D99834.5070903@mozilla.org> <41DA8ADF.8040206@bugzilla.org>
Message-ID: <41DA8F2D.3090702@bugzilla.org>

Jake wrote:
> Gervase Markham wrote:
> 
>> - There are significantly more bugs marked as blocking2.20+ than there
>>   are blocking2.18+, and we shouldn't do a Release Candidate unless the
>>   build is a release candidate, which means fixing them all
> 
> I think this is the most compelling reason. A "Release Candidate" 
> implies that if there are no major issues found, this will be the 
> release. In a perfect world, the only change from, for example, 1.0rc1 
> and 1.0 would be a version number. To have known bugs that we want fixed 
> before a release takes place seems backwards. Our criteria should be 
> only slightly lower for an rc as it is for a full blown release. I 
> understand that there's some "cool stuff" that wants to appear on the 
> trunk but can't because of the 2.20 freeze, but we also need to focus on 
> the task at hand (eg, getting the current release out the door).

OK, here's the deal.  After I went and looked, and did a little triage, 
there are exactly 4 bugs that are blocking 2.20 that are not also 
blocking 2.18.  That hardly constitutes "significantly more" when you 
consider we still have 7 bugs left that are blocking 2.18.  We still 
have to have all the 2.18 blockers done before we can release 2.18.  If 
the 2.20 blockers happen to also be taken care of by that time, we'll 
release 2.20rc1.  If they aren't, we'll release 2.19.2.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From bugzilla-AT-obmutescentthiophen-DOT-mine-DOT-nu at nospam.invalid  Fri Jan  7 07:03:23 2005
From: bugzilla-AT-obmutescentthiophen-DOT-mine-DOT-nu at nospam.invalid (Keoni Jacobsen)
Date: 6 Jan 2005 23:03:23 -0800
Subject: Modifying Bugzilla to track a bug across multiple versions with different statuses
Message-ID: <20050107070323.23283.qmail@sunni.gummiwisdom.com>

I am the Bugzilla guru for the company I work for.  We want to modify
Bugzilla, and I was looking for advice on how to do this.  I'm not
asking for any technical help.  We have good people working on this.
(Well, it's just me, but I can handle it.)  I was trying to figure out
how to make this look for the users and managers.

Here is the situation: we have bugs and we have different versions of
our product.  We can find bugs in one version of our product, and we
know it may exist in other versions of our product.  A bug can get
fixed in one version, but, life being what it is, it may not get fixed
in other versions.

We want to be able to track what versions a bug appears in, and where
it gets fixed.  So, the single bug status isn't adequate for this.  We
can't just say a bug is resolved if it's fixed in the most recent
version if it isn't fixed in the previous version.

What we've been doing is opening up new bugs for each version.  But
it's a pain trying to keep all the bugs straight, and seeing what bugs
are really the same as other bugs, just in different versions.  It
messes up bug dependencies, and it makes it hard to link to our
customer issues.

So, I want to find a way to make things easier on everybody.  What
scheme would you suggest?

-KJ

P.S. Please forgive the obfuscated E-mail address.  I'm just trying to
avoid the plague of the Internet (aka spam).


From bugzilla-AT-obmutescentthiophen-DOT-mine-DOT-nu at nospam.invalid  Fri Jan  7 07:21:49 2005
From: bugzilla-AT-obmutescentthiophen-DOT-mine-DOT-nu at nospam.invalid (Keoni Jacobsen)
Date: 6 Jan 2005 23:21:49 -0800
Subject: Interview questions for a Bugzilla developer
Message-ID: <20050107072149.23459.qmail@sunni.gummiwisdom.com>

While I'm at it, I was wondering: what type of interview questions
would you pose for a Bugzilla developer?

I'm not really looking for a Bugzilla developer, but I am looking for
someone who would work on another tool.  It's a Perl and PHP based web
application tool with a MySQL backend, so I figured there would be
some overlap.

--KJ

P.S. Please forgive the obfuscated E-mail address.  I'm just trying to
avoid the plague of the Internet (aka spam).


From timeless at myrealbox.com  Fri Jan  7 07:47:36 2005
From: timeless at myrealbox.com (timeless)
Date: Thu, 06 Jan 2005 23:47:36 -0800
Subject: Modifying Bugzilla to track a bug across multiple versions with
In-Reply-To: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
References: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
Message-ID: <41DE3E98.5040803@myrealbox.com>

Keoni Jacobsen wrote:
> I am the Bugzilla guru for the company I work for.  We want to modify
> Bugzilla, and I was looking for advice on how to do this.  I'm not
> asking for any technical help.  We have good people working on this.
> (Well, it's just me, but I can handle it.)  I was trying to figure out
> how to make this look for the users and managers.
> 
> Here is the situation: we have bugs and we have different versions of
> our product.  We can find bugs in one version of our product, and we
> know it may exist in other versions of our product.  A bug can get
> fixed in one version, but, life being what it is, it may not get fixed
> in other versions.
> 
> We want to be able to track what versions a bug appears in, and where
> it gets fixed.  So, the single bug status isn't adequate for this.  We
> can't just say a bug is resolved if it's fixed in the most recent
> version if it isn't fixed in the previous version.
> 
> What we've been doing is opening up new bugs for each version.  But
> it's a pain trying to keep all the bugs straight, and seeing what bugs
> are really the same as other bugs, just in different versions.  It
> messes up bug dependencies, and it makes it hard to link to our
> customer issues.
> 
> So, I want to find a way to make things easier on everybody.  What
> scheme would you suggest?
> 
> -KJ
> 
> P.S. Please forgive the obfuscated E-mail address.  I'm just trying to
> avoid the plague of the Internet (aka spam).
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=timeless at myrealbox.com>

the approach mozilla.org took was to use keywords.
	this requires no coding effort.

the approach i'm hoping to use for my company is dependencies on aliases.
	this can be done without any coding effort. a bug is dependent on 
open_1.7 and when it's fixed there, it's changed to being dependent on 
fixed_1.7 (you have to pick which way you want the dependency to go, or 
do a bit more work and add the related bug list). To make it pretty 
would require dependencies to be displayed by their aliases instead of 
their bug ids, and to deal with what happens when someone moves an alias 
and someone else commits a change to a which was dependent on the alias.

you're already sort of using one of the other options, namely forked 
bugs (most likely you'd want to use a related bug field - i need to find 
a bug number about this).

one could of course "simply" change the version and target milestone 
fields from single selects to multi selects (this is of course a schema 
change, and requires dealing w/ users who accidentally clear the 
selection). there's something to be said for this 'simple' solution, 
until you consider combinations. suppose you took it a step further and 
allowed multiselect for os/hardware (and really, we should), what 
happens when a bug is fixed for all hardware in one version and some 
hardware for another version :). at some point you really do need to 
fork bugs and rearrange the /flags/ (however you implement them).

lastly, i suppose, you can go for a system where you have at least two 
types of bugs, the first type tracks analysis and resolution, the second 
type is filed for each case where a fix is committed, included in such a 
bug is always a list of commits (or however your changes are tracked, 
personally i use 
http://bonsai.mozilla.org/cvslog.cgi?file=whatever&mark=EACH,COMMITTED,VERSION 
.) the former blocks the latter, and people never include commit 
messages into analysis bugs.


From sukria at sukria.net  Fri Jan  7 13:32:53 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Fri, 7 Jan 2005 14:32:53 +0100
Subject: Need some more information about the #272620 bug
Message-ID: <20050107133252.GA18014@sukria.net>

Hello Bugzilla developers.

I'm working on the maintenance of the Bugzilla package for the Debian
project.

We have recently noticed that there is an important bug report on
Bugzilla which is about XSS issues[1].

This bug is closed to the public in your bug database and then, the
Debian team is not able to access details about what can be
vulnerable in the sofwtare.

We would really apreciate your help to fix this bug.

I've already try to exploit our Bugzilla version with submiting values
such as '<script>alert(1)</script>' in many forms and, hopefully,
everytime, Bugzilla said that the variable is not valid.

Anyway, as this bug is serious, I really cannot close it without being
sure that our version is not affected.

We actually provide the 2.16.7 release.

Any help is strongly welcome.

Best Regards.

Alexis.

1 :
http://lists.netsys.com/pipermail/full-disclosure/2004-December/030222.html

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From bugzilla at colinogilvie.co.uk  Fri Jan  7 13:38:07 2005
From: bugzilla at colinogilvie.co.uk (Colin Ogilvie)
Date: Fri, 07 Jan 2005 13:38:07 +0000
Subject: Need some more information about the #272620 bug
In-Reply-To: <20050107133252.GA18014@sukria.net>
References: <20050107133252.GA18014@sukria.net>
Message-ID: <41DE90BF.2030406@colinogilvie.co.uk>

Alexis Sukrieh wrote:

>This bug is closed to the public in your bug database and then, the
>Debian team is not able to access details about what can be
>vulnerable in the sofwtare.
>
https://bugzilla.mozilla.org/show_bug.cgi?id=272620 is open, and 
viewable to all as far as I can tell. The fix has also been checked in 
on the Trunk, 2.18 and 2.16 branches.

-- 
Colin Ogilvie
bugzilla at colinogilvie.co.uk



From sukria at sukria.net  Fri Jan  7 14:24:47 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Fri, 7 Jan 2005 15:24:47 +0100
Subject: Need some more information about the #272620 bug
In-Reply-To: <41DE90BF.2030406@colinogilvie.co.uk>
References: <20050107133252.GA18014@sukria.net> <41DE90BF.2030406@colinogilvie.co.uk>
Message-ID: <20050107142441.GB18800@sukria.net>

* Colin Ogilvie (bugzilla at colinogilvie.co.uk) disait :
> https://bugzilla.mozilla.org/show_bug.cgi?id=272620 is open, and 
> viewable to all as far as I can tell. The fix has also been checked in 
> on the Trunk, 2.18 and 2.16 branches.

Thanks a lot, last time I looked at it, the bug report was closed.
This fix[1] will be included soon in our 2.16 release until 2.18 is out.

Thanks again.

1 : https://bugzilla.mozilla.org/attachment.cgi?id=168868

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From dwilliss at microimages.com  Fri Jan  7 15:10:11 2005
From: dwilliss at microimages.com (Dave Williss)
Date: Fri, 7 Jan 2005 09:10:11 -0600
Subject: Modifying Bugzilla to track a bug across multiple versions with different statuses
References: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
Message-ID: <15f701c4f4ca$fc076250$4b00000a@opus2>

We have a similar situation.  The solution we came up with is that when a 
bug is
reported, the version is set to the earliest version the bug is known to 
exist in.
When an engineer fixes it, they're supposed to fix all versions from current 
back.
If, for some reason, they can't, they set the target milestone to the 
earliest version
that they fixed.

Another good idea would be to define flags for each version specifying if 
the bug
exists in that version and another one for if it's fixed in that version.

----- Original Message ----- 
From: "Keoni Jacobsen" 
<bugzilla-AT-obmutescentthiophen-DOT-mine-DOT-nu at nospam.invalid>
To: <developers at bugzilla.org>
Sent: Friday, January 07, 2005 1:03 AM
Subject: Modifying Bugzilla to track a bug across multiple versions with 
different statuses


>I am the Bugzilla guru for the company I work for.  We want to modify
> Bugzilla, and I was looking for advice on how to do this.  I'm not
> asking for any technical help.  We have good people working on this.
> (Well, it's just me, but I can handle it.)  I was trying to figure out
> how to make this look for the users and managers.
>
> Here is the situation: we have bugs and we have different versions of
> our product.  We can find bugs in one version of our product, and we
> know it may exist in other versions of our product.  A bug can get
> fixed in one version, but, life being what it is, it may not get fixed
> in other versions.
>
> We want to be able to track what versions a bug appears in, and where
> it gets fixed.  So, the single bug status isn't adequate for this.  We
> can't just say a bug is resolved if it's fixed in the most recent
> version if it isn't fixed in the previous version.
>
> What we've been doing is opening up new bugs for each version.  But
> it's a pain trying to keep all the bugs straight, and seeing what bugs
> are really the same as other bugs, just in different versions.  It
> messes up bug dependencies, and it makes it hard to link to our
> customer issues.
>
> So, I want to find a way to make things easier on everybody.  What
> scheme would you suggest?
>
> -KJ
>
> P.S. Please forgive the obfuscated E-mail address.  I'm just trying to
> avoid the plague of the Internet (aka spam).
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dwilliss at microimages.com> 



From justdave at bugzilla.org  Fri Jan  7 17:22:47 2005
From: justdave at bugzilla.org (David Miller)
Date: Fri, 07 Jan 2005 12:22:47 -0500
Subject: Need some more information about the #272620 bug
In-Reply-To: <20050107133252.GA18014@sukria.net>
References: <20050107133252.GA18014@sukria.net>
Message-ID: <41DEC567.2020005@bugzilla.org>

Alexis Sukrieh wrote:

> I've already try to exploit our Bugzilla version with submiting values
> such as '<script>alert(1)</script>' in many forms and, hopefully,
> everytime, Bugzilla said that the variable is not valid.

The bug is not exploitable unless you're using Internet Explorer or 
Konqueror as the browser (maybe others, but those are the only two we 
tested that we could duplicate it in).  If you're using most other 
browsers, the browser will prevent the unescaped URL from being used.

> We actually provide the 2.16.7 release.

I notice Debian Stable still lists version 2.14.2.  A quick examination 
shows the content of the package is actually version 2.14.5, and the 
version number wasn't bumped (all of the patches from the 2.14 branch 
since 2.14.2 were applied by the diff.gz file as "backported patches" 
except those were the only changes between those versions anyway).

Version 2.14.x is NOT vulnerable to this particular issue.  The 
javascript in question was added somewhere during the 2.15 development 
cycle.  However, there have been several security issues since then that 
have not been fixed in the 2.14 branch (because upstream support for it 
was dropped two years ago), nor do I see patches for them included in 
the existing Debian package, so the package in Woody shouldn't be 
considered safe.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From sukria at sukria.net  Fri Jan  7 18:26:33 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Fri, 7 Jan 2005 19:26:33 +0100
Subject: Need some more information about the #272620 bug
In-Reply-To: <41DEC567.2020005@bugzilla.org>
References: <20050107133252.GA18014@sukria.net> <41DEC567.2020005@bugzilla.org>
Message-ID: <20050107182632.GD20930@sukria.net>

* David Miller (justdave at bugzilla.org) disait :
> The bug is not exploitable unless you're using Internet Explorer or 
> Konqueror as the browser (maybe others, but those are the only two we 
> tested that we could duplicate it in).  If you're using most other 
> browsers, the browser will prevent the unescaped URL from being used.

Indeed, I do know that and I've performed my tests with Windows IE 6.

> >We actually provide the 2.16.7 release.
> 
> I notice Debian Stable still lists version 2.14.2.  A quick examination 
> shows the content of the package is actually version 2.14.5, and the 
> version number wasn't bumped (all of the patches from the 2.14 branch 
> since 2.14.2 were applied by the diff.gz file as "backported patches" 
> except those were the only changes between those versions anyway).
> 
> Version 2.14.x is NOT vulnerable to this particular issue.  The 
> javascript in question was added somewhere during the 2.15 development 
> cycle.  However, there have been several security issues since then that 
> have not been fixed in the 2.14 branch (because upstream support for it 
> was dropped two years ago), nor do I see patches for them included in 
> the existing Debian package, so the package in Woody shouldn't be 
> considered safe.

Ok, thanks for that note. 

The problem is that patches for woody must be
only security fixes, so is there a way to apply only the security
patches to make our 2.14 release safe ? 

I'm pretty sure the woody issue is quite sofisticated to solve, moreover
when we know that sarge will fix all that with providing a safe version... 

Any advices are really welcome as I'm just starting to maintain the
Bugzilla Debian package, feel free to give me comments and advices then
;)


-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From john.fisher at znyx.com  Fri Jan  7 19:06:41 2005
From: john.fisher at znyx.com (john fisher)
Date: Fri, 07 Jan 2005 11:06:41 -0800
Subject: Modifying Bugzilla to track a bug across multiple versions
In-Reply-To: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
References: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
Message-ID: <1105124801.3729.411.camel@johnf.znyx.com>

Keoni, we have a similar problem. We make a switch board with different
chipsets etc. Our software has some code that spans all types, and some
code is specific to a chipset or backplane. We use CVS.

First, I added a second Version, version-fixed-in, and changed version
to be version-found-in, so a single bug has a code version where Test
knows it should be fixed (and all versions later).
Then we had to branch the code tree to accommodate new chipsets.
Second, I added a new field, Branch, which is a text label that applies
to a series of code versions, in a unique relationship.
Third I added the concept of clones- a cloned bug is a separate bug,
which originated from some earlier bug. There is no dependency.
After adding some UI and search capability, the software manager can do
the following:
When a bug is found in a code branch, which also exists in a different
code branch ( different files or versions of files ), he clones the
first bug, passing along all its information, and changes the branch on
the new bug. Now he can track two bugs, and Test knows when and where
they should be testing the bug fix. The process is the same if the
hardware platform is different.
When a new branch of the code is created, the manager branches multiple
bugs so we can track fixes in two places.

I'd be happy to provide details or explanation off-line, if any of this
is helpful.

John

On Thu, 2005-01-06 at 23:03 -0800, Keoni Jacobsen wrote:
...

> 
> Here is the situation: we have bugs and we have different versions of
> our product. ...

-- 
John Fisher at Znyx Networks
Santa Barbara office
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050107/2e5944b8/attachment.html>

From travis at SEDSystems.ca  Fri Jan  7 19:10:28 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Fri, 7 Jan 2005 13:10:28 -0600 (CST)
Subject: Modifying Bugzilla to track a bug across multiple versions
In-Reply-To: <1105124801.3729.411.camel@johnf.znyx.com>
References: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
 <1105124801.3729.411.camel@johnf.znyx.com>
Message-ID: <Pine.GHP.4.58.0501071256190.20922@milhouse.SEDSystems.ca>



On Fri, 7 Jan 2005, john fisher wrote:

> First, I added a second Version, version-fixed-in, and changed version
> to be version-found-in, so a single bug has a code version where Test
> knows it should be fixed (and all versions later).

We have something almost identical: 'Version' became 'Version w/defect' and
we added a new field 'Version w/fix'.

That doesn't say where the fix has been installed, though. (Our company
doesn't do 'general products' -- most of our software is custom built for
one customer who may have many installations.) We have been keeping track of
this information in the bug itself, but we plan to use flags to make it
easier. Something like this:

installed-Singapore   ?
installed-DC
installed-Hawaii      +
installed-Pune        ?

This nomenclature would mean that the fix has already been applied to the
site at Hawaii, but still needs to be applied to Pune and Singapore. DC does
not need the fix (for whatever reason).

I hope this helps!

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From mkanat at kerio.com  Sat Jan  8 02:22:50 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Fri, 07 Jan 2005 18:22:50 -0800
Subject: Feedback Needed: Release Notes for 2.18
Message-ID: <1105150970.31727.5.camel@localhost.localdomain>

	I've just spent quite some time working on the Release Notes for 2.18,
which we are (believe it or not) almost ready to release. We have almost
no remaining critical bugs blocking the release, now it just remains to
do a lot of administrative work, like these release notes. I'm sure that
sometime soon justdave will send out a request for help on updating the
web site for the release, and in generally making a big deal of it once
it comes out.

	Until then, I'd like your input on the release notes. Release Notes for
2 1/2 years of code is really a major effort, and it's obviously easier
if the people who wrote the code (all of you) pitch in.

	So, check it out:

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

	Please let me know if I left out anything from the attached patches.

	-Max




From mkanat at kerio.com  Sat Jan  8 09:44:27 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Sat,  8 Jan 2005 01:44:27 -0800
Subject: Your Help Needed With Bugzilla 2.18 Release Process!
Message-ID: <20050108014427.e2615b64@mail.kerio.com>

Hey there! We have several administrative tasks that need to be done in order to be able to release 2.18. These are now the major blockers to the release.

  They each have a bug in bugzilla.mozilla.org. These bugs are all assigned to Dave Miller (justdave) at the moment, but *anybody* may take them and assign them to themselves, and then work on that part of the release!

  To get the website templates on your local machine, you can use CVS:

  export CVSROOT=:pserver:anonymous at cvs-mirror.mozilla.org:/www
  cvs -q co -d bugzilla.org mozilla-org/html/projects/bugzilla

  Here are the tasks that need to be done:

  bug 277509: Status Update Release for 2.18 
  https://bugzilla.mozilla.org/show_bug.cgi?id=277509

  bug 277510: Update the "Changes" page for 2.18 Release
  https://bugzilla.mozilla.org/show_bug.cgi?id=277510

  bug 277511: Update the Download page for 2.18
  https://bugzilla.mozilla.org/show_bug.cgi?id=277511

  bug 277512: News Announcement for 2.18 Release
  https://bugzilla.mozilla.org/show_bug.cgi?id=277512

  bug 277515: Release Announcement for Bugzilla 2.18
  https://bugzilla.mozilla.org/show_bug.cgi?id=277515

  If you need information for these things, you can use the Release Notes (with the patch attached to bug 150149: https://bugzilla.mozilla.org/show_bug.cgi?id=150149).

  The faster we get all of these small website changes done, the faster we can release 2.18. :-) Feel free to submit patches to any of those bugs.

  -Max




From gerv at mozilla.org  Sat Jan  8 13:41:03 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 08 Jan 2005 13:41:03 +0000
Subject: Need some more information about the #272620 bug
In-Reply-To: <20050107182632.GD20930@sukria.net>
References: <20050107133252.GA18014@sukria.net> <41DEC567.2020005@bugzilla.org> <20050107182632.GD20930@sukria.net>
Message-ID: <41DFE2EF.6030004@mozilla.org>

Alexis Sukrieh wrote:
> The problem is that patches for woody must be
> only security fixes, so is there a way to apply only the security
> patches to make our 2.14 release safe ? 

I'm afraid not. You are going to have to review all the security bugs 
between when we stopped supporting 2.14 and now, see if they apply, and 
if so port the patches. :-( Sorry about that.

I'm sure Dave would be happy to add you to the webtools-security group 
in bugzilla.mozilla.org once he's happy you are definitely a Debian 
developer ;-)

> Any advices are really welcome as I'm just starting to maintain the
> Bugzilla Debian package, feel free to give me comments and advices then
> ;)

It's great that these packages are getting some love :-) Not wanting to 
point the finger, but in the past incompatibilities and problems with 
the Debian version of Bugzilla have led to us refusing to support it. 
We'd love to work with you to look at making changes to Bugzilla to make 
it easier for you to integrate it into Debian, and reduce the number of 
differences between the versions.

Gerv


From gerv at mozilla.org  Sat Jan  8 13:59:32 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 08 Jan 2005 13:59:32 +0000
Subject: Interview questions for a Bugzilla developer
In-Reply-To: <20050107072149.23459.qmail@sunni.gummiwisdom.com>
References: <20050107072149.23459.qmail@sunni.gummiwisdom.com>
Message-ID: <41DFE744.5060402@mozilla.org>

Keoni Jacobsen wrote:
> While I'm at it, I was wondering: what type of interview questions
> would you pose for a Bugzilla developer?

Not specifically for a Bugzilla developer (although his company does 
make a bug tracker) but Joel's Guerilla Guide to Interviewing is 
excellent general advice. It's in his book, and also online:
http://www.joelonsoftware.com/articles/fog0000000073.html

Gerv


From sukria at sukria.net  Sat Jan  8 14:09:07 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Sat, 8 Jan 2005 15:09:07 +0100
Subject: Need some more information about the #272620 bug
In-Reply-To: <41DFE2EF.6030004@mozilla.org>
References: <20050107133252.GA18014@sukria.net> <41DEC567.2020005@bugzilla.org> <20050107182632.GD20930@sukria.net> <41DFE2EF.6030004@mozilla.org>
Message-ID: <20050108140906.GB28347@sukria.net>

* Gervase Markham (gerv at mozilla.org) disait :
> Alexis Sukrieh wrote:
> >The problem is that patches for woody must be
> >only security fixes, so is there a way to apply only the security
> >patches to make our 2.14 release safe ? 
> 
> I'm afraid not. You are going to have to review all the security bugs 
> between when we stopped supporting 2.14 and now, see if they apply, and 
> if so port the patches. :-( Sorry about that.

Looking at how hard such a work could be and at the fact that sarge is
going to replace woody, I think we might focus on solving sid/sarge
bugs.

Moreover, when Bugzilla 2.18 (or 2.20) is up, I plan to package it from
scratch, in order to enhance the Bugzilla/Debian work.

So, let's focus on closing sarge/sid bugs :)

> I'm sure Dave would be happy to add you to the webtools-security group 
> in bugzilla.mozilla.org once he's happy you are definitely a Debian 
> developer ;-)

That would be a honour :) But, to be precise, I'm not really a Debian
Developer, I'm just a Debian Maintainer, see that blog entry for details
: http://www.sukria.net/en/index.php?p=129

That means that I am responsible of the Bugzilla maintenance but I
cannot upload by myself new releases, I must ask my sponsor for it.
That's the difference between Debian Developers and Debian Maintainers.

> It's great that these packages are getting some love :-) Not wanting to 
> point the finger, but in the past incompatibilities and problems with 
> the Debian version of Bugzilla have led to us refusing to support it. 
> We'd love to work with you to look at making changes to Bugzilla to make 
> it easier for you to integrate it into Debian, and reduce the number of 
> differences between the versions.

That's definitely my point of view, the nearest Debian release is to
upstream, the best it is for everyone.

As soon as Bugzilla 2.18 (or 2.20, I'm not sure about the best timetable
to adopt) is out, I'll start a new packaging, and every collaborative
work with you guys will be strongly appreciated :)

Let's give Bugzilla a new face in the Debian world :)

Best regards.

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From gerv at mozilla.org  Sat Jan  8 19:49:21 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 08 Jan 2005 19:49:21 +0000
Subject: Need some more information about the #272620 bug
In-Reply-To: <20050108140906.GB28347@sukria.net>
References: <20050107133252.GA18014@sukria.net> <41DEC567.2020005@bugzilla.org> <20050107182632.GD20930@sukria.net> <41DFE2EF.6030004@mozilla.org> <20050108140906.GB28347@sukria.net>
Message-ID: <41E03941.2080109@mozilla.org>

Alexis Sukrieh wrote:
> That's definitely my point of view, the nearest Debian release is to
> upstream, the best it is for everyone.
> 
> As soon as Bugzilla 2.18 (or 2.20, I'm not sure about the best timetable
> to adopt) is out, I'll start a new packaging, and every collaborative
> work with you guys will be strongly appreciated :)

If it's an effort to package it, and if it doesn't make any difference 
if it's a week or a couple of months, wait for 2.20.

Gerv


From gerv at mozilla.org  Sat Jan  8 20:27:45 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 08 Jan 2005 20:27:45 +0000
Subject: Development process analysis
Message-ID: <41E04241.7080902@mozilla.org>

Guys,

We're doing a lot of thinking about the development process at the 
moment. However, it seems to me that we haven't yet had a chance to 
implement the last round of thinking, and see whether the things we 
wanted to do then actually improve matters. This means that a lot of the 
discussion is merely rehashing the same points from six months ago.

I seem to remember that the consensus was that the following things 
needed to happen:

- More frequent upgrading of b.m.o. for testing purposes
- Shorter development cycles to avoid long stabilisation periods

However, as we haven't yet released 2.18 or 2.20, we haven't had a 
chance to put this into practice!

If, once we branch for 2.20, instead of saying "according to the 
schedule, we are now three quarters of the way through the 2.22 
development cycle; so we only have a month to get patches in", we say 
"OK, the 2.22 development cycle starts now", we can get back on track 
and start trying out some of the last round of process improvements. 
Then, we can see if they actually work! :-)

(I'd argue we actually want to move to nine-month cycles, but that's a 
different discussion.)

Gerv


From vladd at bugzilla.org  Sat Jan  8 21:33:12 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Sat, 08 Jan 2005 23:33:12 +0200
Subject: Development process analysis
In-Reply-To: <41E04241.7080902@mozilla.org>
References: <41E04241.7080902@mozilla.org>
Message-ID: <41E05198.9010008@bugzilla.org>

To be blunt, I don't like this very much.

First, because we'd broke in this way kind of a promise about scheduled 
feature freezes.

Secondly, this 6-month thing never got the chance to run in a normal 
state. 2.18 had to catch up with several years of 2.17.x development and 
its regressions. 2.20 apparently will put things back on track if indeed 
is released shortly after 2.18, like David insists nowadays.

Thirdly, the whole aim of "Shorter development cycles" would be broken 
if we'd do what you suggest, by pushing/enlarging this particular 
development cycle.

4thly, this rule has some kind of negative feedback loop. If it takes 3 
months to clean up after 3 months of development, then we'll have 3 
months of devel and 3 months of stabilization. If it takes 6 months of 
clean up for 3 months of development, then we'll have only 2 months of 
devel and 4 months of stabilization. It automatically adjusts the scale 
to 6 months, by keeping the proportions.

If you mess with it, probably it will reflect in a longer stabilization 
period for 2.22, because you won't be able to change the stabilization 
versus devel ratio with this artificial extension. Although, suggestions 
for changhing the ratio are most welcomed!

Vlad.

Gervase Markham wrote:

> Guys,
>
> We're doing a lot of thinking about the development process at the 
> moment. However, it seems to me that we haven't yet had a chance to 
> implement the last round of thinking, and see whether the things we 
> wanted to do then actually improve matters. This means that a lot of 
> the discussion is merely rehashing the same points from six months ago.
>
> I seem to remember that the consensus was that the following things 
> needed to happen:
>
> - More frequent upgrading of b.m.o. for testing purposes
> - Shorter development cycles to avoid long stabilisation periods
>
> However, as we haven't yet released 2.18 or 2.20, we haven't had a 
> chance to put this into practice!
>
> If, once we branch for 2.20, instead of saying "according to the 
> schedule, we are now three quarters of the way through the 2.22 
> development cycle; so we only have a month to get patches in", we say 
> "OK, the 2.22 development cycle starts now", we can get back on track 
> and start trying out some of the last round of process improvements. 
> Then, we can see if they actually work! :-)
>
> (I'd argue we actually want to move to nine-month cycles, but that's a 
> different discussion.)
>
> Gerv
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>



From justdave at bugzilla.org  Sat Jan  8 22:12:23 2005
From: justdave at bugzilla.org (David Miller)
Date: Sat, 08 Jan 2005 17:12:23 -0500
Subject: Development process analysis
In-Reply-To: <41E05198.9010008@bugzilla.org>
References: <41E04241.7080902@mozilla.org> <41E05198.9010008@bugzilla.org>
Message-ID: <41E05AC7.4050809@bugzilla.org>

Vlad Dascalu wrote:

> Secondly, this 6-month thing never got the chance to run in a normal 
> state. 2.18 had to catch up with several years of 2.17.x development and 
> its regressions. 2.20 apparently will put things back on track if indeed 
> is released shortly after 2.18, like David insists nowadays.

Yup.

> 4thly, this rule has some kind of negative feedback loop. If it takes 3 
> months to clean up after 3 months of development, then we'll have 3 
> months of devel and 3 months of stabilization. If it takes 6 months of 
> clean up for 3 months of development, then we'll have only 2 months of 
> devel and 4 months of stabilization. It automatically adjusts the scale 
> to 6 months, by keeping the proportions.

The stabilization period for 2.20 has actually been artificially 
lengthened by my insisting that we release 2.18 first before we do a 
2.20 release candidate.  2.20 was in theory ready to go when we released 
2.19.1.  Granted, there have been several more blockers found for 2.20 
since then, but most of that is a result of the b.m.o upgrade, and would 
have happened even if we had declared that the RC.  Seeing how 2.20 went 
with a 2 month checkin window before we froze for 2.20, I have very high 
hopes that 2.22 will go even smoother once we reopen the trunk. 
Development didn't stop, we just have several patches sitting in 
Bugzilla waiting on hold to be checked in.  It's a little frustrating 
because they're not in CVS, but they're still coming anyway.  Once the 
trunk opens, those will go in, and we'll have 2 months (or slightly 
less) to keep going with feature development before we have to freeze 
for 2.22 in March, which is within a reasonable distance of how long we 
had for 2.20 after 2.18 branched.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Sat Jan  8 22:12:12 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 08 Jan 2005 22:12:12 +0000
Subject: Development process analysis
In-Reply-To: <41E05198.9010008@bugzilla.org>
References: <41E04241.7080902@mozilla.org> <41E05198.9010008@bugzilla.org>
Message-ID: <41E05ABC.4050800@mozilla.org>

Vlad Dascalu wrote:
> Secondly, this 6-month thing never got the chance to run in a normal 
> state. 

That's my point! So we shouldn't be doing re-analysis until we've had a 
chance to see what will happen when we actually implement this plan.

> Thirdly, the whole aim of "Shorter development cycles" would be broken 
> if we'd do what you suggest, by pushing/enlarging this particular 
> development cycle.

Oh, you mean the 9 month thing. That was just an add-on to the main 
point of what I'm saying - like I said, a separate discussion.

Gerv


From gerv at mozilla.org  Sun Jan  9 00:43:06 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 09 Jan 2005 00:43:06 +0000
Subject: Truce
Message-ID: <41E07E1A.7030001@mozilla.org>

Here's my suggestion:

- Everyone stops discussing all of Vlad's analysis posts
- No-one, including Vlad, posts any new ones
- We all work together to release 2.18 and 2.19.2
- Dave prepares an email summarising how he thinks things should work 
post-2.18, taking into account feedback received thusfar
- We then reopen discussion on that, and the analysis posts.

Basically, it's a temporary hold on discussion so we can get the release 
done. It's not a suppression of debate - it's clear people have views 
they want to express. I'm just suggesting now is not quite the right time.

I'm also not saying "everyone say whether they want to do this" or 
anything like that, but if you think it's a good idea, follow it :-)

Gerv


From mkanat at kerio.com  Sun Jan  9 03:15:50 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Sat,  8 Jan 2005 19:15:50 -0800
Subject: Truce
In-Reply-To: <41E07E1A.7030001@mozilla.org>
Message-ID: <20050108191550.47a5d820@mail.kerio.com>

> Here's my suggestion:
> 
> - Everyone stops discussing all of Vlad's analysis posts

  Is this in relation to reviewers@? Because I don't see any such posts from Vlad on this list, except in response to your "Development process analysis" thread.

> - We all work together to release 2.18 and 2.19.2

  Hooray! I agree. :-) So far we've gotten a bit of contribution on the release process, which has been awesome. And thanks for getting those release-note additions in so fast.

> - Dave prepares an email summarising how he thinks things should work 
> post-2.18, taking into account feedback received thusfar

  I think he already did -- we'll probably release 2.19.2, and then we'll keep freezing like we are now. We don't even know if this thing works yet -- we haven't had the chance to have a "real" six-month freeze period yet.

  -Max




From gerv at mozilla.org  Sun Jan  9 09:52:03 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 09 Jan 2005 09:52:03 +0000
Subject: Truce
In-Reply-To: <20050108191550.47a5d820@mail.kerio.com>
References: <20050108191550.47a5d820@mail.kerio.com>
Message-ID: <41E0FEC3.9030805@mozilla.org>

Maxwell Kanat-Alexander wrote:
> Is this in relation to reviewers@? Because I don't see any such posts
> from Vlad on this list, except in response to your "Development
> process analysis" thread.

Oops. Yes, I haven't been paying attention. Those on developers@ who 
aren't on reviewers@ should ignore this :-)

Gerv


From justdave at bugzilla.org  Mon Jan 10 11:47:30 2005
From: justdave at bugzilla.org (David Miller)
Date: Mon, 10 Jan 2005 06:47:30 -0500
Subject: Release schedule plans
Message-ID: <41E26B52.20308@bugzilla.org>

A few of us had a pretty good conversation late last night on IRC about 
our plans for current and future releases.  I think it's definitely 
worth a read and further discussion.  Nothing discussed here has had any 
final decisions made yet.

http://www.justdave.net/bz/irc20040110-releaseplans.html

A quick summary of some of the ideas that were hashed out (but it'll 
make better sense if you actually read the log a the above URL) :

1) Should we abort the 2.20 freeze and make our March 15 freeze be for 
2.20 instead of 2.22?

This sits at an undecided Maybe from the existing discussion on IRC, but 
leaning towards releasing 2.20 in the immediate near future anyway, 
thanks to the discussion in point number 5 below.

2) Should we attempt an "eased transition" into the 6 month cycle where 
we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would 
freeze March 15 as above), then 9 months for 2.22 (making it Jan 1 
2006), then 6 months from there on out?

We generally decided that the "overlapping freezes" was very unlikely to 
ever happen again, so the 9 months for the next release probably 
wouldn't be necessary.

3) Our newly frequent releases (if we can stick to them) are going to 
create a lot of branches to simultaneously maintain.  Should we have 
branch managers for each branch?

I pointed out that we attempted to do this in the past, and nobody ever 
took me up on it.  Most of the people with the motivation to do such a 
thing (at least when I asked around last time) like to stay on the tip, 
and would feel constrained quickly if they had to stay on a branch.  I 
still kind of like the idea if we can find people to do it though.

4) b.m.o upgrade schedule was discussed.

I felt that b.m.o should stay on the "current stable" branch from this 
point onward, with it upgrading to the next stable branch as soon as the 
branch was cut (coinciding with the rc1 release for that branch).  This 
would allow b.m.o to update frequently (every week or two if needed?) 
within that branch to continue to pick up bugfixes without it being a 
major deal to upgrade and with minimal chance of picking up regressions. 
  The 6 months between getting new features would be much quicker than 
b.m.o's historical upgrade frequency, so mozilla.org folks would still 
be happy.  Since b.m.o still, to this day, finds 90% of our release 
blockers, giving them our first release candidate should get this part 
out of the way quickly both for them and for us. :)

5) What kind of branch lifetime and support level should we provide?

Our previous branch management policy was brought up...  originally, 
*nothing* got checked in on a stable branch unless it fixed a 
regression, a security issue, or a dataloss problem.  Recently we've 
been a bit lax with that, allowing minor bugfixes to be checked in on 
the branches as well.  It was felt that this was at least partially the 
fault of the 2.16 branch being so freaking old (3 years!) and still 
supported as the "current stable release".  Everyone pretty much agreed 
that we need to set up some clear-cut rules for what can go on the 
branches when, and get those rules posted on the website for reference. 
  The idea that everyone (that was there) seemed to like the best was to 
go ahead and provide general bugfixes on the stable branch for 6 months 
after release, and after that 6 months, provide *only* security and 
dataloss fixes for an additional 12 months.  This would give each 
release a security-supported lifetime of 18 months.

Correcting for accuracy from the IRC log (after I drew the little 
chart), this would actually give us 6 active branches (eek!) at one 
point (counting the trunk), but we'll always have 4 in the long run once 
the dust settles.  This is easier to visualize with said little chart:

== Bugfixes provided
-- Security only

      Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
2.16 --|
2.18 ======-----------|
2.20 =======-----------|
2.22   |======-----------|
2.24         |======-----------|
2.26               |======-----------|
2.28                     |======-----------|

We might call it 3.0 at some point in there, but these are good enough 
examples to get the gist of it.

OK, that about covers it.  Discussion?  :)

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From Nick.Barnes at pobox.com  Mon Jan 10 12:40:26 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Mon, 10 Jan 2005 12:40:26 +0000
Subject: Release schedule plans
In-Reply-To: <41E26B52.20308@bugzilla.org> 
   from David Miller <justdave@bugzilla.org> 
   of "Mon, 10 Jan 2005 06:47:30 -0500"
Message-ID: <65482.1105360826@thrush.ravenbrook.com>

At 2005-01-10 11:47:30+0000, David Miller writes:

2) Should we attempt an "eased transition" into the 6 month cycle where 
we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would 
freeze March 15 as above), then 9 months for 2.22 (making it Jan 1 
2006), then 6 months from there on out?

This sounds OK.

> Correcting for accuracy from the IRC log (after I drew the little 
> chart), this would actually give us 6 active branches (eek!) at one 
> point (counting the trunk), but we'll always have 4 in the long run once 
> the dust settles.  This is easier to visualize with said little chart:
> 
> == Bugfixes provided
> -- Security only
> 
>       Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
> 2.16 --|
> 2.18 ======-----------|
> 2.20 =======-----------|
> 2.22   |======-----------|
> 2.24         |======-----------|
> 2.26               |======-----------|
> 2.28                     |======-----------|
> 
> We might call it 3.0 at some point in there, but these are good enough 
> examples to get the gist of it.
> 
> OK, that about covers it.  Discussion?  :)

I think this is OK.  The branch proliferation isn't too bad.  After
things settle down it's (typically):

trunk : bug fixes and development;
2.28  : bug fixes only;
2.26  : security fixes only;
2.24  : security fixes only.

This is not very dissimilar from what we have handled in the past.
There's some pain in the near future, but that's just the tailing off
of the pain which we're already in (waiting for 2.18, 2.20 frozen,
etc).  The main unknown is: how long is a freeze likely to be?  Given
more frequent releases, and more frequent upgrades of b.m.o, the
overall quality shouldn't decay too much and so the freezes should
stay fairly short.  My favoured software process avoids all freezes by
keeping the trunk releasable at all times (for more information see
<http://www.ravenbrook.com/doc/1999/05/20/pqtcm/>, for instance), but
this might not apply at all well to Bugzilla.

We do need a better ASCIIgram to distinguish between when the branch
is cut and when the release is made, because the extra effort starts
from when the branch is cut (that's when we start having to test every
change in an extra place).  But when the first release is made for a
branch, the rate of change goes down quite a bit.  The ideal ASCIIgram
would also mark freezes etc.

I think it would be a mistake to roll out 2.20 within about three
months of 2.18.  If you plan that then people will wait for 2.20
rather than upgrade twice in rapid succession.

Nick B


From gerv at mozilla.org  Mon Jan 10 18:37:45 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 10 Jan 2005 18:37:45 +0000
Subject: Release schedule plans
In-Reply-To: <65482.1105360826@thrush.ravenbrook.com>
References: <65482.1105360826@thrush.ravenbrook.com>
Message-ID: <41E2CB79.8060102@mozilla.org>

Nick Barnes wrote:
> At 2005-01-10 11:47:30+0000, David Miller writes:

Having checked my spam folder, I don't seem to have the original in this 
thread - did anyone else get it?

>>Correcting for accuracy from the IRC log (after I drew the little 
>>chart), this would actually give us 6 active branches (eek!) at one 
>>point (counting the trunk), but we'll always have 4 in the long run once 
>>the dust settles.  

I don't like the sound of that at all. Currently we are managing three, 
and it's more than enough. I'd argue this is a reason to either extend 
the development cycle or shorten the support cycle.

Gerv


From chicks at chicks.net  Mon Jan 10 18:53:11 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Mon, 10 Jan 2005 13:53:11 -0500 (EST)
Subject: Release schedule plans
In-Reply-To: <41E2CB79.8060102@mozilla.org>
References: <65482.1105360826@thrush.ravenbrook.com> <41E2CB79.8060102@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501101345260.2117@skippy.fini.net>

On Mon, 10 Jan 2005, Gervase Markham wrote:
> Having checked my spam folder, I don't seem to have the original in this 
> thread - did anyone else get it?

Yes.

>>> Correcting for accuracy from the IRC log (after I drew the little chart), 
>>> this would actually give us 6 active branches (eek!) at one point 
>>> (counting the trunk), but we'll always have 4 in the long run once the 
>>> dust settles. 
>
> I don't like the sound of that at all. Currently we are managing three, and 
> it's more than enough. I'd argue this is a reason to either extend the 
> development cycle or shorten the support cycle.

I think a mixture of those options would be best.  Folks tend to not want 
to make radical changes to something so critical to their daily lives such 
as bugzilla is for some of us.  Having a long-term stable branch, such as 
2.16 has ended up being inadvertantly, makes it easy for those folks to 
sit with the features they have and avoid radical changes.  So, what if 
every other (or every third as circumstances dictate) "stable" release 
will be a "very stable" release that gets supported for a longer period of 
time.  I'd say that 2.20 or 2.22 should be our next "very stable" release. 
Supporting it for twice as long could mean that the support effort for the 
"stable but not very" releases wouldn't need to be as long.  Maintaining a 
2.18 branch could be cut very short so that folks could focus on 2.20 
maintenance instead for instance.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From vladd at bugzilla.org  Mon Jan 10 18:57:42 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Mon, 10 Jan 2005 20:57:42 +0200 (EET)
Subject: Release schedule plans
In-Reply-To: <41E26B52.20308@bugzilla.org>
References: <41E26B52.20308@bugzilla.org>
Message-ID: <3864.217.156.83.1.1105383462.squirrel@syndicomm.com>

> Everyone pretty much agreed
> that we need to set up some clear-cut rules for what can go on the
> branches when, and get those rules posted on the website for reference.

I haven't seen from the log that "everyone pretty much agreed". Can you
get some names to back up this statement?

I strongly object to the idea of enforcing clear-cut rules. What Bugzilla
development needs is a set of guidelines that should aid people into
making a decision about branches.

Commiting to clear-cut rules doesn't help anybody. It doesn't help the
users, and it doesn't help Bugzilla. You no longer have the discretion
needed in order to take decisions on a case by case basis. It gives you an
opportunity to hide behind the rules, and the ability to say that we were
simply doing things "by the book" in case something goes wrong or the
progress is not fast enough.

The first rule about people management is that there is no rule. While in
software devel and software management this changes slightly due to the
precise character that software can sometimes have, discretion is stil an
important thing to be kept as an available thing to most decision takers.

I strongly suggest to put any kind of rules for driving the branches as
mere guidelines, and to leave the branch drivers (justdave nowadays, or
branch managers if that ever picks up) the freedom to act on the best
interests of that branch and not behind some mecanical rule.

Vlad.




From gerv at mozilla.org  Mon Jan 10 19:44:20 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 10 Jan 2005 19:44:20 +0000
Subject: Release schedule plans
In-Reply-To: <3864.217.156.83.1.1105383462.squirrel@syndicomm.com>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com>
Message-ID: <41E2DB14.4050606@mozilla.org>

Vlad Dascalu wrote:
> The first rule about people management is that there is no rule. 

No, the first rule about people management is that you do not tear into 
them relentlessly in public, because it makes them defensive, angry, 
bitter and upset.

I've tried to hint, now let me be more direct:

Vlad, please stop attacking Dave on this mailing list. You have a lot of 
valid points to make, but the good is being swallowed up by the 
unnecessarily aggressive, relentless and personal way in which you are 
making them.

Unless you have plans for a coup d'etat, or have already decided to 
leave the project after venting your anger, then you should bear in mind 
that you will need to work with Dave again after all this is over.

Because a section like this seems to need including in every post I make 
to avoid people misunderstanding me:

- This is NOT trying to start a flamewar with Vlad
- This is NOT saying that he or anyone else is right or wrong about
   anything they have said regarding the development process
- This is NOT defending the status quo in the face of calls for change
- This is NOT suppressing debate

It is saying that aggressive rudeness is both unnecessary and extremely 
counter-productive.

Gerv

P.S. I am very aware of the possible irony, and have tried very hard not 
to break the rule outlined in the first paragraph, by making my point 
forcefully but not rudely. I apologise if I haven't quite succeeded.


From john.fisher at znyx.com  Mon Jan 10 19:57:45 2005
From: john.fisher at znyx.com (john fisher)
Date: Mon, 10 Jan 2005 11:57:45 -0800
Subject: Modifying Bugzilla to track a bug across multiple versions with
In-Reply-To: <41DE3E98.5040803@myrealbox.com>
References: <20050107070323.23283.qmail@sunni.gummiwisdom.com>
	 <41DE3E98.5040803@myrealbox.com>
Message-ID: <1105387065.7542.70.camel@johnf.znyx.com>

No doubt worthy suggestions, but they violate the following principles,
which may (?) be helpful:
1) Minimal training allowed for Bugzilla - UI must be obvious.
1A) Things from the real world must be represented as straightforwardly
as possible in the db-
One change to code is tied to one bug, a different change to code has a
separate bug ( though there can be a clone association).
A version is exactly tied to real software versions in CVS, e.g. no
version exists in BZ which is not a tag in CVS.


Caveat: my shop is populated by cranky geezers ( like me ) with no love
for learning new tools.

I didn't say before, but we also made platform and OS product-dependent,
but not multiple- we are going to have a problem when a single release
of our driver runs on multiple platforms. I will probably have to make a
table of legal versions by platform, and change to multiple platforms.

HTH
John


On Thu, 2005-01-06 at 23:47 -0800, timeless wrote:

> Keoni Jacobsen wrote:
> > I am the Bugzilla guru ...would you suggest?
> > 
> > -KJ
> > 
> 
> the approach mozilla.org took was to use keywords.
> 	this requires no coding effort.
> 
> the approach i'm hoping to use for my company is dependencies on aliases.

...

> 
> one could of course "simply" change the version and target milestone 
> fields from single selects to multi selects ...suppose you took it a step further and 
> allowed multiselect for os/hardware (and really, we should),...
> 
> lastly, i suppose, you can go for a system where you have at least two 
> types of bugs, the first type tracks analysis and resolution, the second 
> type is filed for each case where a fix is committed,...

-- 
John Fisher at Znyx Networks
Santa Barbara office
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050110/02285b5b/attachment.html>

From mkanat at kerio.com  Mon Jan 10 20:29:42 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Mon, 10 Jan 2005 12:29:42 -0800
Subject: Release schedule plans
In-Reply-To: <3864.217.156.83.1.1105383462.squirrel@syndicomm.com>
Message-ID: <20050110122942.3f1d797b@mail.kerio.com>

> Commiting to clear-cut rules doesn't help anybody.

  PHBs and System Administrators need some idea of how long a release will be supported for. It's an important selling point.

  -Max




From vladd at bugzilla.org  Mon Jan 10 21:06:47 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Mon, 10 Jan 2005 23:06:47 +0200
Subject: Release schedule plans
In-Reply-To: <41E2DB14.4050606@mozilla.org>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com> <41E2DB14.4050606@mozilla.org>
Message-ID: <41E2EE67.4000503@bugzilla.org>

Gerv, could you please leave your personal interpretations of what you 
consider rude and what not when you push the "Reply" button?

We aren't going to get very far away if we keep replying to the 
"emotional" part of the emails. Let's focus instead of the "rationale" 
part of them. If some of us finds it useful, including me, I propose to 
re-wrote in our minds each email so that all emotions, rudeness etc are 
dropped and all the rationale thing is kept. Then reply only to that one.

I've tried to do that, and I've also tried to do it when writing an 
email. Sometimes, it's difficult. Sometimes, it doesn't work. Either you 
all believe me that my purpose is not to be rude or something like that, 
but to express valid points related to Bugzilla development, and you try 
to reply to that one, or you don't.

I'd suggest you guys try the "rationale" thing approach and ignore 
whatever you might consider rude or impolite, because it really wasn't 
in my intention. The alternative, if you can't filter emotions out, is 
for me to stop writing anything at all, which I think will be less 
productive for Bugzilla development.

Vlad.

Gervase Markham wrote:

> Vlad Dascalu wrote:
>
>> The first rule about people management is that there is no rule. 
>
>
> No, the first rule about people management is that you do not tear 
> into them relentlessly in public, because it makes them defensive, 
> angry, bitter and upset.
>
> I've tried to hint, now let me be more direct:
>
> Vlad, please stop attacking Dave on this mailing list. You have a lot 
> of valid points to make, but the good is being swallowed up by the 
> unnecessarily aggressive, relentless and personal way in which you are 
> making them.
>
> Unless you have plans for a coup d'etat, or have already decided to 
> leave the project after venting your anger, then you should bear in 
> mind that you will need to work with Dave again after all this is over.
>
> Because a section like this seems to need including in every post I 
> make to avoid people misunderstanding me:
>
> - This is NOT trying to start a flamewar with Vlad
> - This is NOT saying that he or anyone else is right or wrong about
>   anything they have said regarding the development process
> - This is NOT defending the status quo in the face of calls for change
> - This is NOT suppressing debate
>
> It is saying that aggressive rudeness is both unnecessary and 
> extremely counter-productive.
>
> Gerv
>
> P.S. I am very aware of the possible irony, and have tried very hard 
> not to break the rule outlined in the first paragraph, by making my 
> point forcefully but not rudely. I apologise if I haven't quite 
> succeeded.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>



From gerv at mozilla.org  Mon Jan 10 22:29:23 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 10 Jan 2005 22:29:23 +0000
Subject: Release schedule plans
In-Reply-To: <41E2EE67.4000503@bugzilla.org>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com> <41E2DB14.4050606@mozilla.org> <41E2EE67.4000503@bugzilla.org>
Message-ID: <41E301C3.1010808@mozilla.org>

Vlad Dascalu wrote:
> Gerv, could you please leave your personal interpretations of what you 
> consider rude and what not when you push the "Reply" button?

This has really gone beyond my personal opinion. I really don't think 
telling the project maintainer that: "You no longer have the discretion
needed in order to take decisions on a case by case basis" could be 
considered as anything but rude.

> We aren't going to get very far away if we keep replying to the 
> "emotional" part of the emails. Let's focus instead of the "rationale" 
> part of them. If some of us finds it useful, including me, I propose to 
> re-wrote in our minds each email so that all emotions, rudeness etc are 
> dropped and all the rationale thing is kept. Then reply only to that one.

That simply doesn't work.

For a long time, I found that people reacted badly to things I said. 
(Some people on this list may remember that time; one or two may argue 
it's still not completely behind me.) My thought was always "oh, come 
on, disregard that part you think is rude and focus on my point" - just 
as you've suggested we do to your emails.

But I finally realised that people just can't do that. Humans react in a 
certain way to both the content and the tone of communications, and you 
can't separate the two out. If you want people to take on board and 
consider your thoughts, the way you express them is at least as 
important as the point you are making.

I found that a really hard lesson to learn - and I only learnt it when 
someone sat me down and explained to me how important it is, and why. 
(It took them a few goes - I'm someone who finds it hard to do something 
without understanding exactly why I'm doing it.) Which is why I'm 
writing this email to you now. I'm no communications wizard, but I want 
to pass on what I've learned, because it works. I get my way around the 
office a lot more these days, not because I argue more forcefully, or 
because my points are better, but because I say things more in a way 
that makes people want to listen to and accommodate my views.

> I'd suggest you guys try the "rationale" thing approach and ignore 
> whatever you might consider rude or impolite, because it really wasn't 
> in my intention. The alternative, if you can't filter emotions out, is 
> for me to stop writing anything at all, which I think will be less 
> productive for Bugzilla development.

I think that if you do that until we release 2.18, it will be *more* 
productive for Bugzilla development - both because we'll release 2.18 
faster, and because your good suggestions will make the releasing of 
2.20 and onwards better and faster too.

Gerv


From gerv at mozilla.org  Mon Jan 10 22:41:12 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 10 Jan 2005 22:41:12 +0000
Subject: Release schedule plans
Message-ID: <41E30488.9000708@mozilla.org>

[Apologies for the lack of threading; I was missing the message and so 
had to cut and paste from the archives.]

> A quick summary of some of the ideas that were hashed out (but it'll 
> make better sense if you actually read the log a the above URL) :
> 
> 1) Should we abort the 2.20 freeze and make our March 15 freeze be for 
> 2.20 instead of 2.22?
 >
 > This sits at an undecided Maybe from the existing discussion on IRC,
 > but leaning towards releasing 2.20 in the immediate near future
 > anyway, thanks to the discussion in point number 5 below.

It seems that we have three choices:

a) Release 2.18 and release 2.20 soon afterwards
b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
c) Abandon 2.18 and just release 2.20

 From the point of view of our customers, who don't want to upgrade too 
frequently, and from our point of view, where we don't want to have to 
maintain too many branches, a) is the worst case scenario.

It puts two releases close together, which will affect maintenance and 
release management for at least 18 months. It also means we have a 
confused story. "Upgrade to our shiny new 2.18! It's the first stable 
release for three years! Except unless you can wait another month or 
two, in which case 2.20 is coming right along behind it, and it's 
better." It's like buses. You wait three years for one...

So IMO we should either unfreeze the trunk and develop some more (which 
seems reasonable; we don't have that many new features yet anyway) or we 
should scrap 2.18 altogether and release 2.20, if it's so close.

> 2) Should we attempt an "eased transition" into the 6 month cycle where 
> we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would 
> freeze March 15 as above), then 9 months for 2.22 (making it Jan 1 
> 2006), then 6 months from there on out?

Remind me again why we are so keen to do a *six* month release cycle? 
What was the rationale there?

> 4) b.m.o upgrade schedule was discussed.

<snip>

I agree with everything that was said, apart from the fact that we 
should upgrade just _before_ we branch rather than just after. That 
means that, if there's more fallout than expected, we don't have to do 
lots of work applying patches to two near-identical branches, and the 
people who would fix the fallout aren't distracted by checking shiny new 
features into the trunk.

Gerv


From kevin.benton at amd.com  Mon Jan 10 22:58:10 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Mon, 10 Jan 2005 15:58:10 -0700
Subject: Release schedule plans
In-Reply-To: <41E30488.9000708@mozilla.org>
Message-ID: <20050110225810.965BE1FA0@ldcmail.amd.com>

<soapbox>
I thought the whole point of branching was to have a clear-cut line in the
sand where the thought was that it's time to move to the next stage.  If
there are bugs past the branch, then it just helps underscore the need for
high-level QA.  On the other hand, if you wait, it's harder to say - here's
the line.  Let's move on.
</soapbox>

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Gervase Markham
> Sent: Monday, January 10, 2005 3:41 PM
> To: developers at bugzilla.org
> Subject: Re: Release schedule plans
> 
> [Apologies for the lack of threading; I was missing the message and so
> had to cut and paste from the archives.]
> 
> > A quick summary of some of the ideas that were hashed out (but it'll
> > make better sense if you actually read the log a the above URL) :
> >
> > 1) Should we abort the 2.20 freeze and make our March 15 freeze be for
> > 2.20 instead of 2.22?
>  >
>  > This sits at an undecided Maybe from the existing discussion on IRC,
>  > but leaning towards releasing 2.20 in the immediate near future
>  > anyway, thanks to the discussion in point number 5 below.
> 
> It seems that we have three choices:
> 
> a) Release 2.18 and release 2.20 soon afterwards
> b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
> c) Abandon 2.18 and just release 2.20
> 
>  From the point of view of our customers, who don't want to upgrade too
> frequently, and from our point of view, where we don't want to have to
> maintain too many branches, a) is the worst case scenario.
> 
> It puts two releases close together, which will affect maintenance and
> release management for at least 18 months. It also means we have a
> confused story. "Upgrade to our shiny new 2.18! It's the first stable
> release for three years! Except unless you can wait another month or
> two, in which case 2.20 is coming right along behind it, and it's
> better." It's like buses. You wait three years for one...
> 
> So IMO we should either unfreeze the trunk and develop some more (which
> seems reasonable; we don't have that many new features yet anyway) or we
> should scrap 2.18 altogether and release 2.20, if it's so close.
> 
> > 2) Should we attempt an "eased transition" into the 6 month cycle where
> > we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 would
> > freeze March 15 as above), then 9 months for 2.22 (making it Jan 1
> > 2006), then 6 months from there on out?
> 
> Remind me again why we are so keen to do a *six* month release cycle?
> What was the rationale there?
> 
> > 4) b.m.o upgrade schedule was discussed.
> 
> <snip>
> 
> I agree with everything that was said, apart from the fact that we
> should upgrade just _before_ we branch rather than just after. That
> means that, if there's more fallout than expected, we don't have to do
> lots of work applying patches to two near-identical branches, and the
> people who would fix the fallout aren't distracted by checking shiny new
> features into the trunk.
> 
> Gerv
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From travis at SEDSystems.ca  Mon Jan 10 22:56:09 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Mon, 10 Jan 2005 16:56:09 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E30488.9000708@mozilla.org>
References: <41E30488.9000708@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501101638070.5554@milhouse.SEDSystems.ca>



On Mon, 10 Jan 2005, Gervase Markham wrote:

> c) Abandon 2.18 and just release 2.20

This is a very interesting idea. Dave, you keep speaking about how stable
2.20 is, and how it would have had an RC a while back if 2.18 weren't in the
way. Since that's the case, what about amalgamating the existing code for
2.18 and 2.20 into one release, and *calling* it 2.18? That would allow us
to make use of the existing stability in (IMHO) a more effective way.
Basically... branch again with the EXISTING tip, and call that 2.18.

This way, the tip could be re-opened again for development, and the waiting
patches checked in. We then freeze again in March, just like originally
planned, but we freeze for 2.20 instead of 2.22.

Yes, I know that slips the posted schedule by six months out to infinity...
but in case nobody had noticed we're already at least six months behind. Why
not just *acknowledge* that fact and work with that reality so as to cause
ourselves as little pain as possible, rather than rushing three releases out
the door in four months? I mean, the thought of supporting six branches...
<shudder>

It just seems to me that if we've got two almost-completely-stable branches,
it's a damn shame to waste the publicity generated by releasing Our First
New Release In Three Years by putting out another one a couple of weeks
later, and then a third one a month or two after that.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From vladd at bugzilla.org  Mon Jan 10 23:11:13 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 11 Jan 2005 01:11:13 +0200
Subject: Release schedule plans
In-Reply-To: <41E301C3.1010808@mozilla.org>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com> <41E2DB14.4050606@mozilla.org> <41E2EE67.4000503@bugzilla.org> <41E301C3.1010808@mozilla.org>
Message-ID: <41E30B91.9010707@bugzilla.org>

Gervase Markham wrote:

> This has really gone beyond my personal opinion. I really don't think 
> telling the project maintainer that: "You no longer have the discretion
> needed in order to take decisions on a case by case basis" could be 
> considered as anything but rude.

But, once you leave the emotional part of your statement out of it, it's 
becoming true, isn't it? :-)

Every rule that we give as a rule is that: a rule. That restricts your 
liberty of decision and your discretion. Take for example the fact that 
we said to do freezes on a regular scheduled. It has its advantages and 
its disadvantages. We pushed that as a rule, so now we have less 
flexibility in changing it. If instead we would have pushed that as a 
guideline, probably we would be more light-hearted nowadays to go on a 
9-month freeze, aka to break our promise, because at that time it 
wouldn't have been a rule, but a simple guideline.

When evaluating rudeness it's really only a personal opinion, because 
there are no general accepted criterias for classifying things as rude 
or not. Only general guidelines :-) that vary from culture to culture. 
So what might be rude for you might be a bless (literally :-) ) for 
another one. I don't object to hints on PRIVATE email about things that 
I said about YOU that you might consider rude. But I do thing that 
steering a what wants to be a PUBLIC rational discussion with your 
personal opinions about what is rude or not in regard to ANOTHER person 
is a little worrying.

David has a mouth of himself and like we've seen he can stand pretty 
good on his own. He will even repeat your words if you say them before 
he goes to say them, so I wouldn't be worried about that too much to 
such a degree that I'd steer the discussion on emotionale issues.

More, what you said about "working together" seemed like the mit of 
"people have to like each other, be buds/friends/blood brothers in order 
to work together", a nit that appeared on my evaluation as a harming 
thing to the Bugzilla development. If you believe that working together 
depends on us liking each other, then that's an issue in the development 
process and it will have to be discussed further when we reopen the 
evaluation process (right after the 2.18 shipment).

> But I finally realised that people just can't do that.

That's a general statement. :-) People can try, and that is what should 
everybody should do. If you want to write my email to me "now", please 
do it in private without steering the discussion towards emotional 
issues. Even if people can't keep only the rationale part of it, they 
can follow the simple rule of trying to reply to rationale things on the 
public list and to the emotional stuff on private emails. At least I'm 
sure you can try.

> I think that if you do that until we release 2.18, it will be *more* 
> productive for Bugzilla development - both because we'll release 2.18 
> faster, and because your good suggestions will make the releasing of 
> 2.20 and onwards better and faster too.

You asked if I think that this discussion will improve the 3 blockers 
left. As a matter a fact, I do - see 
https://bugzilla.mozilla.org/show_bug.cgi?id=275108#c37. But anyway, I 
don't want to be a "whiner" here, so let's take it another way. You see 
nowadays David discussing about 2.20 and future roadmap plans. If your 
theory is correct, this discussion about the roadmap and he future 
wouldn't help the 3 blockers left. But yet, he does it. For a very good 
reason - 2.18 will go out hand in hand with 2.19.2 or 2.20rc1, and with 
the status update it will be nice to let folks know about the future. 
2.18 goes hand in hand with a lot of community-related documents; policy 
and general discussion like justdave's roadmap&future thing or my 
evaluation thing goes hand in hand with those. You can't really separate 
them; you could strictly resolve those 3 bugs and ignore everything 
else, but that would mean missing a lot of things, code driving-related 
included.

Vlad.


From kevin.benton at amd.com  Mon Jan 10 23:15:34 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Mon, 10 Jan 2005 16:15:34 -0700
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501101638070.5554@milhouse.SEDSystems.ca>
Message-ID: <20050110231534.D55DC1FA0@ldcmail.amd.com>

Raising hand to vote for Shane's modified version of Gerv's suggestion!
Great ideas!

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Shane H. W. Travis
> Sent: Monday, January 10, 2005 3:56 PM
> To: developers at bugzilla.org
> Subject: Re: Release schedule plans
> 
> 
> 
> On Mon, 10 Jan 2005, Gervase Markham wrote:
> 
> > c) Abandon 2.18 and just release 2.20
> 
> This is a very interesting idea. Dave, you keep speaking about how stable
> 2.20 is, and how it would have had an RC a while back if 2.18 weren't in
> the
> way. Since that's the case, what about amalgamating the existing code for
> 2.18 and 2.20 into one release, and *calling* it 2.18? That would allow us
> to make use of the existing stability in (IMHO) a more effective way.
> Basically... branch again with the EXISTING tip, and call that 2.18.
> 
> This way, the tip could be re-opened again for development, and the
> waiting
> patches checked in. We then freeze again in March, just like originally
> planned, but we freeze for 2.20 instead of 2.22.
> 
> Yes, I know that slips the posted schedule by six months out to
> infinity...
> but in case nobody had noticed we're already at least six months behind.
> Why
> not just *acknowledge* that fact and work with that reality so as to cause
> ourselves as little pain as possible, rather than rushing three releases
> out
> the door in four months? I mean, the thought of supporting six branches...
> <shudder>
> 
> It just seems to me that if we've got two almost-completely-stable
> branches,
> it's a damn shame to waste the publicity generated by releasing Our First
> New Release In Three Years by putting out another one a couple of weeks
> later, and then a third one a month or two after that.
> 
> Shane H.W. Travis       | The greatest of all mistakes is to do nothing
> travis at sedsystems.ca    |  because you can only do a little.
> Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From gerv at mozilla.org  Mon Jan 10 23:51:57 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 10 Jan 2005 23:51:57 +0000
Subject: Release schedule plans
In-Reply-To: <20050110231534.D55DC1FA0@ldcmail.amd.com>
References: <20050110231534.D55DC1FA0@ldcmail.amd.com>
Message-ID: <41E3151D.90009@mozilla.org>

Kevin Benton wrote:
> Raising hand to vote for Shane's modified version of Gerv's suggestion!
> Great ideas!

If we were to do this, to avoid confusion, I would suggest abandoning 
the "2.18" designation and shipping "2.20" rather than renumbering all 
the releases and branches. But that's not a big point.

Gerv


From travis at SEDSystems.ca  Mon Jan 10 23:42:42 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Mon, 10 Jan 2005 17:42:42 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E3151D.90009@mozilla.org>
References: <20050110231534.D55DC1FA0@ldcmail.amd.com> <41E3151D.90009@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501101740460.5554@milhouse.SEDSystems.ca>



On Mon, 10 Jan 2005, Gervase Markham wrote:

> If we were to do this, to avoid confusion, I would suggest abandoning
> the "2.18" designation and shipping "2.20" rather than renumbering all
> the releases and branches. But that's not a big point.

My feeling is that having to do all this renumbering would entail some
short-term pain, to be sure... but it's better than the long-term pain of
explaining ad infinitum why there was never a 2.18 release, and why
the release numbering goes from 2.16 straight to 2.20.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith






From mkanat at kerio.com  Mon Jan 10 23:56:09 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Mon, 10 Jan 2005 15:56:09 -0800
Subject: "Map" of checksetup.pl
Message-ID: <20050110155609.7627d865@mail.kerio.com>

Hey Bugzilla developers. Just to let you know, I just spent a few hours "mapping out" checksetup, and I now have an English description of what it does, step-by-step. You can see it attached to bug 277502:

  https://bugzilla.mozilla.org/attachment.cgi?id=170860

  Have fun. :-)

  -Max




From mkanat at kerio.com  Tue Jan 11 00:06:14 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Mon, 10 Jan 2005 16:06:14 -0800
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501101638070.5554@milhouse.SEDSystems.ca>
Message-ID: <20050110160614.145b8d7c@mail.kerio.com>

> what about amalgamating the existing code for
> 2.18 and 2.20 into one release, and *calling* it 2.18?

  I was thinking about that all last night while we were discussing the plans. I hate that idea, but only because it pushes 2.18 out further, and it's been SO HARD to get 2.18 out the door. We've already gotten all the release blockers out of what we're calling "2.20", though, for the most part, and it's *not very different* from 2.20.

  And yet, I almost want to do that. It will make branch maintenance so much easier...

  But there are too many "blocking2.20?" bugs, and we wouldn't be unfrozen before March. We'd end up in this situation again, with a freeze affecting tip development. I think we should release 2.18 -- it works, it's releaseable, and we NEED to release something.

  If branch management is the long-term concern, then we should release the hold on 2.20 for now and freeze again for it in March. That will still give us only about 7 - 9 months of open development on 2.20, which should be easily manageable.

  -Max




From justdave at bugzilla.org  Tue Jan 11 00:31:21 2005
From: justdave at bugzilla.org (David Miller)
Date: Mon, 10 Jan 2005 19:31:21 -0500
Subject: Release schedule plans
In-Reply-To: <41E30B91.9010707@bugzilla.org>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com> <41E2DB14.4050606@mozilla.org> <41E2EE67.4000503@bugzilla.org> <41E301C3.1010808@mozilla.org> <41E30B91.9010707@bugzilla.org>
Message-ID: <41E31E59.9060904@bugzilla.org>

Vlad Dascalu wrote:

> David has a mouth of himself and like we've seen he can stand pretty 
> good on his own.

I've kept my mouth shut so far since yesterday because I wasn't able to 
reply to this thread in a way that wouldn't be defensive and 
inflammatory to someone.  I've started more than once, then nuked it 
because I realized I wasn't going to do anything but fan the flames.  I 
may reply later when I can do it more rationally.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From virajdhumal at yahoo.co.in  Tue Jan 11 07:03:22 2005
From: virajdhumal at yahoo.co.in (viraj dhumal)
Date: Tue, 11 Jan 2005 07:03:22 +0000 (GMT)
Subject: Modifying Bugzilla for Accessing Different Mysql bugs instances
Message-ID: <20050111070322.50974.qmail@web8504.mail.in.yahoo.com>

Hello developers,

Pls anybody will guide me , how to 
modify Bugzilla for accessing different Mysql
instances 
depending on the URL.
There will be different aliases(URLS) for the document
root in httpd.conf file of apache.

regards,
Viraj. 

________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


From gerv at mozilla.org  Tue Jan 11 08:45:31 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 11 Jan 2005 08:45:31 +0000
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501101740460.5554@milhouse.SEDSystems.ca>
References: <20050110231534.D55DC1FA0@ldcmail.amd.com> <41E3151D.90009@mozilla.org> <Pine.GHP.4.58.0501101740460.5554@milhouse.SEDSystems.ca>
Message-ID: <41E3922B.3090800@mozilla.org>

Shane H. W. Travis wrote:
> My feeling is that having to do all this renumbering would entail some
> short-term pain, to be sure... but it's better than the long-term pain of
> explaining ad infinitum why there was never a 2.18 release, and why
> the release numbering goes from 2.16 straight to 2.20.

Word went from 6 to 95. Mozilla went from M18 to 0.6. Patch Maker went 
from 0.75 to 2.0. This really isn't a big deal :-)

Gerv


From timeless at myrealbox.com  Tue Jan 11 08:55:50 2005
From: timeless at myrealbox.com (timeless)
Date: Tue, 11 Jan 2005 00:55:50 -0800
Subject: Release schedule plans
In-Reply-To: <41E3922B.3090800@mozilla.org>
References: <20050110231534.D55DC1FA0@ldcmail.amd.com> <41E3151D.90009@mozilla.org> <Pine.GHP.4.58.0501101740460.5554@milhouse.SEDSystems.ca> <41E3922B.3090800@mozilla.org>
Message-ID: <41E39496.5070306@myrealbox.com>

for the record, i'm explicitly against releasing 2.20 as 2.18. because 
i've been filing bugs against 2.19.1 which is deployed. i don't want my 
bugmail archives to be confused.


From chicks at chicks.net  Tue Jan 11 15:11:15 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Tue, 11 Jan 2005 10:11:15 -0500 (EST)
Subject: Release schedule plans
In-Reply-To: <41E31E59.9060904@bugzilla.org>
References: <41E26B52.20308@bugzilla.org> <3864.217.156.83.1.1105383462.squirrel@syndicomm.com>
 <41E2DB14.4050606@mozilla.org> <41E2EE67.4000503@bugzilla.org>
 <41E301C3.1010808@mozilla.org> <41E30B91.9010707@bugzilla.org>
 <41E31E59.9060904@bugzilla.org>
Message-ID: <Pine.LNX.4.61.0501111006380.22995@skippy.fini.net>

On Mon, 10 Jan 2005, David Miller wrote:
> I've kept my mouth shut so far since yesterday because I wasn't able to 
> reply to this thread in a way that wouldn't be defensive and 
> inflammatory to someone.  I've started more than once, then nuked it 
> because I realized I wasn't going to do anything but fan the flames.  I 
> may reply later when I can do it more rationally.

If people get a bit inflamed to get past this thing and move on then 
that's just tough.

Some of the ensuing discussion is worthy of your comment I think.  Whether 
skipping a real 2.18 release is an option and why would be the biggest 
thing I'd like to see your reaction too.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From Nick.Barnes at pobox.com  Tue Jan 11 17:07:30 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Tue, 11 Jan 2005 17:07:30 +0000
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501101638070.5554@milhouse.SEDSystems.ca> 
   from "Shane H. W. Travis" <travis@SEDSystems.ca> 
   of "Mon, 10 Jan 2005 16:56:09 -0600"
Message-ID: <71844.1105463250@thrush.ravenbrook.com>

At 2005-01-10 22:56:09+0000, "Shane H. W. Travis" writes:

> what about amalgamating the existing code for 2.18 and 2.20 into one
> release, and *calling* it 2.18?

Yes.  Consider that our biggest and best beta site is running 2.19.1+,
i.e. is testing "2.20" code, not "2.18" code.

Nick


From travis at SEDSystems.ca  Tue Jan 11 17:23:35 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Tue, 11 Jan 2005 11:23:35 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E3922B.3090800@mozilla.org>
References: <20050110231534.D55DC1FA0@ldcmail.amd.com> <41E3151D.90009@mozilla.org>
 <Pine.GHP.4.58.0501101740460.5554@milhouse.SEDSystems.ca> <41E3922B.3090800@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501111112210.8415@milhouse.SEDSystems.ca>



On Tue, 11 Jan 2005, Gervase Markham wrote:

> Word went from 6 to 95. Mozilla went from M18 to 0.6. Patch Maker went
> from 0.75 to 2.0.

Right... and notice how all of those are major jumps, not just 'gaps'?

We have a long-established pattern of releasing 2.even-numbered stable
branches, and 2.odd-numbered development branches *in order*. This is a good
thing. Our customers know what to expect, and they know that 2.16 follows
2.14, which followed 2.12.  I'll have no problem in completely violating
that, however, when we go from 2.xx to 3.00, even if we don't make it to
2.98 first (*please* don't let us make it to 2.98 first...) because that
represents a significant shift, and SHOULD reset the numbering.

If we amalgamate 2.18 and 2.20 into one release, then the 'significant
thing' about that is that we haven't been able to meet our own self-imposed
release dates; that we've been too slow in some areas and too fast in
others, so we've ended up overlapping ourselves.  (Not a criticism, simply
an analysis.) Learn from the mistakes and do better next time... but I don't
personallt see any need to *advertise* the mistakes both now and forever by
creating a hiccup in the release numbering.

(*IF* we amalgamate 2.18 and 2.20, of course.)

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From LpSolit at netscape.net  Tue Jan 11 17:59:55 2005
From: LpSolit at netscape.net (Fr=?ISO-8859-1?B?6WTpcmljIEJ1Y2xpbik=?=)
Date: Tue, 11 Jan 2005 12:59:55 -0500
Subject: Release schedule plans
Message-ID: <0B661A2D.1AB7704A.001883BF@netscape.net>

Maxwell Kanat-Alexander <mkanat at kerio.com> wrote:
>I think we should release 2.18 -- it works, it's releaseable, and we NEED to release something.

I agree with mkanat, we should release 2.18 soon with the 3 remaining blockers fixed (if they really need to be fixed for 2.18.0, or can they be for the 2.18.1 release only?). Administrators who have already upgraded to 2.18rc3 may be confused to see 2.18 final (or even 2.18rc4) with so much differences compared to 2.18rc3 if we merge it with 2.19.1+. 2.18 is much better than 2.16; let's go and release it.


>  If branch management is the long-term concern, then we should release the hold on 2.20 for now and freeze again for it in March. That will still give us only about 7 - 9 months of open development on 2.20, which should be easily manageable.

Opening the trunk again and checking in all these waiting patches sounds good to me. We could also decide to release 2.20 only when Bugzilla is fully templatized. Bug 190226 (editversions.cgi) is ready for approval and bug 119485 (editusers.cgi) is awaiting review. Only two bugs (about templatization) are waiting for some developers to write a patch. This is doable in the following few months and would be a good occasion to release 2.20, IMO.

Then, we could freeze the trunk and open it again as soon as 2.20rc1 is released, so that we don't block patch checkins for a too long time.


Fr?d?ric Buclin


__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp


From sukria at sukria.net  Tue Jan 11 18:10:25 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Tue, 11 Jan 2005 19:10:25 +0100
Subject: Need some more information about the #272620 bug
In-Reply-To: <41E03941.2080109@mozilla.org>
References: <20050107133252.GA18014@sukria.net> <41DEC567.2020005@bugzilla.org> <20050107182632.GD20930@sukria.net> <41DFE2EF.6030004@mozilla.org> <20050108140906.GB28347@sukria.net> <41E03941.2080109@mozilla.org>
Message-ID: <20050111181024.GA18230@sukria.net>

* Gervase Markham (gerv at mozilla.org) disait :
> If it's an effort to package it, and if it doesn't make any difference 
> if it's a week or a couple of months, wait for 2.20.

Then I'll wait for 2.20, using all the time before it's available for
fixing current Debian's bugs.

Regards.

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From gerv at mozilla.org  Tue Jan 11 20:22:49 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 11 Jan 2005 20:22:49 +0000
Subject: Modifying Bugzilla for Accessing Different Mysql bugs instances
In-Reply-To: <20050111070322.50974.qmail@web8504.mail.in.yahoo.com>
References: <20050111070322.50974.qmail@web8504.mail.in.yahoo.com>
Message-ID: <41E43599.9020202@mozilla.org>

viraj dhumal wrote:
> Pls anybody will guide me , how to 
> modify Bugzilla for accessing different Mysql
> instances 
> depending on the URL.
> There will be different aliases(URLS) for the document
> root in httpd.conf file of apache.

Please use the newsgroup netscape.public.mozilla.webtools.

Gerv


From gerv at mozilla.org  Tue Jan 11 20:37:51 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 11 Jan 2005 20:37:51 +0000
Subject: Release schedule plans
Message-ID: <41E4391F.8010500@mozilla.org>

> When evaluating rudeness it's really only a personal opinion, because 
> there are no general accepted criterias for classifying things as rude 
> or not. Only general guidelines :-) that vary from culture to culture. 

You can't use that to conclude that therefore rudeness doesn't exist.

The obvious measure of rudeness is whether the person you are talking to 
considers it rude. I think that Dave's comment that he hasn't said 
anything in this discussion yet because he can't trust himself not to 
get into a flamewar speaks volumes about how you have made him feel.

> More, what you said about "working together" seemed like the mit of 
> "people have to like each other, be buds/friends/blood brothers in order 
> to work together", a nit that appeared on my evaluation as a harming 
> thing to the Bugzilla development. 

A person definitely works better with another person if they don't have 
hostile or resentful feelings towards them. I'm extremely surprised that 
you disagree that an atmosphere of cordiality and respect is an 
important part of any team.

>> But I finally realised that people just can't do that.
> 
> That's a general statement. :-) People can try, and that is what should 
> everybody should do. 

If people had perfect control over their emotional reactions to things, 
then this might be possible. But they don't. And even if they did, what 
you would be saying here is that "I am not going to take the time to 
present my arguments in a polite fashion, and so everyone else needs to 
make an effort to carefully hold their emotions in check and ignore my 
rudeness."

Again, I used to feel this way (although I wouldn't have expressed it 
like that), but I found that people don't do this, because it's a great 
deal of effort. It's much easier for them to just think "wow, I don't 
like the way that person said things; they can't have anything important 
to say" and ignore you. And that's what people did to me.

> If you want to write my email to me "now", please 
> do it in private without steering the discussion towards emotional 
> issues.

I'm not emailing you in private partly because I think this discussion 
is of interest to other members of the list, and partly because I hope 
that everyone will read about my mistakes in the past in this area and 
not make them themselves.

Gerv



From vladd at bugzilla.org  Tue Jan 11 20:59:01 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 11 Jan 2005 22:59:01 +0200
Subject: Release schedule plans
In-Reply-To: <41E4391F.8010500@mozilla.org>
References: <41E4391F.8010500@mozilla.org>
Message-ID: <41E43E15.8040501@bugzilla.org>

Gervase,

> A person definitely works better with another person if they don't 
> have hostile or resentful feelings towards them. I'm extremely 
> surprised that you disagree that an atmosphere of cordiality and 
> respect is an important part of any team.

I never said that. I said that people should reply to the rationale part 
of the discussion and leave emotions out of it.

People, including me and you (and people in general, like you said), 
can't leave emotions out of the communication, and implicitely can't 
leave rudeness out of it either, at least not completely. I suggested 
that it's much more better to receive rationale feedback and some 
emotions, compared to no feedback at all. I also suggested that people 
should reply to the rational part and leave emotions out of it, 
especially when those have the potential to degenerate into a flame. I 
never said what you're trying to imply and put in my mouth.

I think we're on the same page here. The difference between us is that 
you're trying to slap people for something that you by yourself agreed 
that it's impossible to leave out (emotions that can explode in flames 
and rudeness), while I suggest to ignore the flame component of the 
emails and focus instead of things that matters.

Vlad.


From chicks at chicks.net  Tue Jan 11 20:59:32 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Tue, 11 Jan 2005 15:59:32 -0500 (EST)
Subject: Release schedule plans
In-Reply-To: <41E4391F.8010500@mozilla.org>
References: <41E4391F.8010500@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>

On Tue, 11 Jan 2005, Gervase Markham wrote:
>> When evaluating rudeness it's really only a personal opinion, because there 
>> are no general accepted criterias for classifying things as rude or not. 
>> Only general guidelines :-) that vary from culture to culture. 
>
> You can't use that to conclude that therefore rudeness doesn't exist.
>
> The obvious measure of rudeness is whether the person you are talking to 
> considers it rude. I think that Dave's comment that he hasn't said anything 
> in this discussion yet because he can't trust himself not to get into a 
> flamewar speaks volumes about how you have made him feel.

Gerv - thank you for standing up and pointing out what should be 
self-evident here.

> If people had perfect control over their emotional reactions to things, then 
> this might be possible. But they don't. And even if they did, what you would 
> be saying here is that "I am not going to take the time to present my 
> arguments in a polite fashion, and so everyone else needs to make an effort 
> to carefully hold their emotions in check and ignore my rudeness."

This is sadly a common trap for intelligent folk who may not be as well 
developed in other areas.  Vlad - I'm not belittling you for repeating a 
common human fault, but I hope to you realize that many brilliant people 
before you have fallen into the same trap.

> I'm not emailing you in private partly because I think this discussion 
> is of interest to other members of the list, and partly because I hope 
> that everyone will read about my mistakes in the past in this area and 
> not make them themselves.

It is quite admirable to have a strong enough sense of what is right to 
stand up despite your past failings in this area.  Thank you.

Should we have a flame war anonymous?  :)

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From gerv at mozilla.org  Tue Jan 11 21:06:13 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 11 Jan 2005 21:06:13 +0000
Subject: Release schedule plans
In-Reply-To: <0B661A2D.1AB7704A.001883BF@netscape.net>
References: <0B661A2D.1AB7704A.001883BF@netscape.net>
Message-ID: <41E43FC5.9030903@mozilla.org>

Fr?d?ric Buclin wrote:
> I agree with mkanat, we should release 2.18 soon with the 3 remaining
> blockers fixed (if they really need to be fixed for 2.18.0, or can
> they be for the 2.18.1 release only?). Administrators who have
> already upgraded to 2.18rc3 may be confused to see 2.18 final (or
> even 2.18rc4) with so much differences compared to 2.18rc3 if we
> merge it with 2.19.1+. 2.18 is much better than 2.16; let's go and
> release it.

I'd be happy with either this scheme or the abandon-2.18 scheme - b) or 
c). I just want to avoid a).

> Opening the trunk again and checking in all these waiting patches
> sounds good to me. We could also decide to release 2.20 only when
> Bugzilla is fully templatized. 

I don't think we should start setting feature goals - but I do agree it 
would be a good opportunity to get this finished.

Gerv


From vladd at bugzilla.org  Tue Jan 11 21:17:00 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 11 Jan 2005 23:17:00 +0200
Subject: Release schedule plans
In-Reply-To: <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
Message-ID: <41E4424C.2070508@bugzilla.org>

Christopher Hicks wrote:

> This is sadly a common trap for intelligent folk who may not be as 
> well developed in other areas.  Vlad - I'm not belittling you for 
> repeating a common human fault, but I hope to you realize that many 
> brilliant people before you have fallen into the same trap.

I don't. I think many brilliant people managed to realise that what 
matters are the results and that getting things done by the book is 
sometimes not the ideal solution. I think that saying the right things 
(even if they will not be liked by everybody) is in the project's interests.

Vlad.


From chicks at chicks.net  Tue Jan 11 23:10:18 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Tue, 11 Jan 2005 18:10:18 -0500 (EST)
Subject: Release schedule plans
In-Reply-To: <41E4424C.2070508@bugzilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
 <41E4424C.2070508@bugzilla.org>
Message-ID: <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>

On Tue, 11 Jan 2005, Vlad Dascalu wrote:
> Christopher Hicks wrote:
>
>> This is sadly a common trap for intelligent folk who may not be as well 
>> developed in other areas.  Vlad - I'm not belittling you for repeating a 
>> common human fault, but I hope to you realize that many brilliant people 
>> before you have fallen into the same trap.
>
> I don't. I think many brilliant people managed to realise that what matters 
> are the results and that getting things done by the book is sometimes not the 
> ideal solution. I think that saying the right things (even if they will not 
> be liked by everybody) is in the project's interests.

So if we're working on optimizing things, lets include examining the 
effectiveness of your communication.  You attempted to communicate with 
superfulous noise and emotion and it proved to be ineffective yet you're 
continuing to try to explain what really matters seemingly oblivious to 
valid constructive criticism.  The book isn't relevant here and I haven't 
seen anybody quoting any verse yet.  Saying the right things was fine, 
nobody is discouraging you from saying the things that need to be said 
because we disagree with you.  But if its worth saying these things isn't 
it worth saying them in the mildest way possible that also happens to be 
the least prone to misinterpretation, confusion and the ensuing 
"off-topic" discussion?  You seem to be frustrated by the response your 
posts received, but this could have been avoided if you were willing to 
engage in moderate self-editing.

Promoting recipient editing in the Internet world is really rather 
ridiculous.  Which uses less energy - the sender editing things until its 
worthy to be shared with the group or every recipient in the group having 
the filter out the superfulous garbage added by the sender?  One of IETF 
credos is "Be liberal in what you accept, and conservative in what you 
send" and applies rather well to human communications.

While it might not be pleasant to find that you've been shown to be rather 
off base in a public way I'm confidant that noone involved did so out of 
disrespect.  If you weren't respected it wouldn't have been worth the 
trouble to explain what you seem to be so resilient to accepting.

If you find yourself interpreting any of this as discouraging dissent, 
discussion, or honesty you're missing my point.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From gerv at mozilla.org  Tue Jan 11 23:27:11 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 11 Jan 2005 23:27:11 +0000
Subject: Release schedule plans
In-Reply-To: <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
Message-ID: <41E460CF.2000302@mozilla.org>

Christopher Hicks wrote:
> While it might not be pleasant to find that you've been shown to be 
> rather off base in a public way I'm confidant that noone involved did so 
> out of disrespect.  If you weren't respected it wouldn't have been worth 
> the trouble to explain what you seem to be so resilient to accepting.

Absolutely.

Gerv


From vladd at bugzilla.org  Tue Jan 11 23:36:17 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 01:36:17 +0200
Subject: Release schedule plans
In-Reply-To: <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
Message-ID: <41E462F1.2050701@bugzilla.org>

Christopher Hicks wrote:

> So if we're working on optimizing things, lets include examining the 
> effectiveness of your communication.  You attempted to communicate 
> with superfulous noise and emotion and it proved to be ineffective yet 
> you're continuing to try to explain what really matters seemingly 
> oblivious to valid constructive criticism.  The book isn't relevant 
> here and I haven't seen anybody quoting any verse yet.  Saying the 
> right things was fine, nobody is discouraging you from saying the 
> things that need to be said because we disagree with you.  But if its 
> worth saying these things isn't it worth saying them in the mildest 
> way possible that also happens to be the least prone to 
> misinterpretation, confusion and the ensuing "off-topic" discussion?  
> You seem to be frustrated by the response your posts received, but 
> this could have been avoided if you were willing to engage in moderate 
> self-editing.

I'm not frustrated, I'm very pleased on how the evaluation thing went. 
It seemed to make people re-evaluate things that took for granted, 
including the communication process. The first good effects are already 
here.

> Promoting recipient editing in the Internet world is really rather 
> ridiculous.  Which uses less energy - the sender editing things until 
> its worthy to be shared with the group or every recipient in the group 
> having the filter out the superfulous garbage added by the sender?  
> One of IETF credos is "Be liberal in what you accept, and conservative 
> in what you send" and applies rather well to human communications.

It's not about 80-20, it's about building a community tollerant to 
emotion-like flames. Trimming down senders makes the network vulnerable 
to the first non-compliant sender :-). Building up responses in every 
receiver makes the network invulnerable :-) The important thing is to 
learn how to receive a message, because in this way we'll end up 
invulnerable to every sender. Learning senders how to behave is still 
important, but it doesn't make the network bullet-proof to the first 
non-compliant sender.

> While it might not be pleasant to find that you've been shown to be 
> rather off base in a public way I'm confidant that noone involved did 
> so out of disrespect.  If you weren't respected it wouldn't have been 
> worth the trouble to explain what you seem to be so resilient to 
> accepting.

Once again, try to understand that I'm not looking for respect or public 
appreciation. My goal was to improve the development process and I 
partially managed that. Once 2.18 is released rest assure that I'll 
continue my evaluation process. That reminds me - a lot of the 
discussion went in private on reviewers@, and you might miss critical 
information in understanding the background of the discussion.

> If you find yourself interpreting any of this as discouraging dissent, 
> discussion, or honesty you're missing my point.

You're missing my point. :-) But I guess that is fine. We're all free 
and stuff after all :-)

Vlad.



From travis at SEDSystems.ca  Tue Jan 11 23:44:09 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Tue, 11 Jan 2005 17:44:09 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E462F1.2050701@bugzilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
 <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
 <41E462F1.2050701@bugzilla.org>
Message-ID: <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca>



On Wed, 12 Jan 2005, Vlad Dascalu wrote:

> The important thing is to learn how to receive a message, because in this
> way we'll end up invulnerable to every sender.

Vlad, respectfully, I disagree.

Since you want to talk about it in computer terms... if a message is
garbled -- full of noise and insignificant information -- then it is not up
to the receiver to try and find the signal in there; it is up to the sender
to try and clean up the message until it is clearly understood.

> Learning senders how to behave is still important, but it doesn't make the
> network bullet-proof to the first non-compliant sender.

See, that's the thing. We shouldn't have to be bulletproof *from each
other*. We're all in this together. You may honestly have the intentions of
trying to 'trying to make everyone better', but I believe that I'm about the
fourth or fifth person now to tell you that HOW you are conveying your
message is interfering with the message itself. Your signal -- the good
parts of your message -- are having a harder time getting through because of
all the noise -- the emotion and negativity.

If you start swinging a baseball bat around, and someone gets hurt, then the
fault is not theirs for failing to have a thick enough head.  Furthermore,
if you continue to swing the bat around after people ask you repeatedly to
stop, then people are going to start avoiding you because you're painful and
dangerous to be around.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From vladd at bugzilla.org  Wed Jan 12 00:31:19 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 02:31:19 +0200
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net> <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca>
Message-ID: <41E46FD7.60407@bugzilla.org>

Shane H. W. Travis wrote:

>Since you want to talk about it in computer terms... if a message is
>garbled -- full of noise and insignificant information -- then it is not up
>to the receiver to try and find the signal in there; it is up to the sender
>to try and clean up the message until it is clearly understood.
>  
>
Yeah. But it's more important for the network to keep its internal 
"security cohesion" rather than to have any sender understood, at any cost.

Anyway, in this case, I think the message got across better due to its 
direct and straightforward path.

Like Nick, you don't have access to reviewers@ and you're missing a lot 
of background, including Gerv's speech due to which (and other factors 
to be fair) he and me ended up in this "defensive" state (to which 
people only contribute more by trying to straight up things without 
having access to the original background).

>See, that's the thing. We shouldn't have to be bulletproof *from each
>other*. We're all in this together. You may honestly have the intentions of
>trying to 'trying to make everyone better', but I believe that I'm about the
>fourth or fifth person now to tell you that HOW you are conveying your
>message is interfering with the message itself. Your signal -- the good
>parts of your message -- are having a harder time getting through because of
>all the noise -- the emotion and negativity.
>  
>
I don't agree. Ironically, I think the emotion and negativity is what 
made people question the communication process in the first place. :-)

>If you start swinging a baseball bat around, and someone gets hurt, then the
>fault is not theirs for failing to have a thick enough head.  Furthermore,
>if you continue to swing the bat around after people ask you repeatedly to
>stop, then people are going to start avoiding you because you're painful and
>dangerous to be around.
>  
>
That would be kind of cool because we could encourage an environment 
where you don't have to be bud buddies in order to work together. Sadly, 
the current is true in Bugzilla development and some straighten up would 
be cool to do.

Vlad.


From harri.vartiainen at prosys.fi  Tue Jan 11 22:00:43 2005
From: harri.vartiainen at prosys.fi (Harri Vartiainen)
Date: Wed, 12 Jan 2005 00:00:43 +0200
Subject: Release schedule plans
In-Reply-To: <41E30488.9000708@mozilla.org>
References: <41E30488.9000708@mozilla.org>
Message-ID: <41E44C8B.10304@prosys.fi>

Gervase Markham wrote:

> It seems that we have three choices:
>
> a) Release 2.18 and release 2.20 soon afterwards
> b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
> c) Abandon 2.18 and just release 2.20

 From the users point of view, release  "official stable version" as 
fast as possible. Don't care if it is 2.18 or 2.20. There's huge gap 
between "developer versions" and version 2.16.x.



From jake at bugzilla.org  Wed Jan 12 01:02:42 2005
From: jake at bugzilla.org (Jake)
Date: Tue, 11 Jan 2005 20:02:42 -0500
Subject: Release schedule plans
In-Reply-To: <41E26B52.20308@bugzilla.org>
References: <41E26B52.20308@bugzilla.org>
Message-ID: <41E47732.9020406@bugzilla.org>

David Miller wrote:

> 1) Should we abort the 2.20 freeze and make our March 15 freeze be for 
> 2.20 instead of 2.22?

I don't think anybody would be surprised to hear that I'm in favor of 
doing this. I think an RC for the next version being released at the 
same time as a long awaited current stable isn't really a good idea.

That does raise a question. What major features are contained in 2.20 
that aren't in 2.18? I've seen it suggested that the whining patch is 
about the only one. It's a nice feature, but IMHO the UI could use a 
little work. It's my opinion that a few more features and a little more 
time between 2.18 and 2.20 would be a good thing.

> 2) Should we attempt an "eased transition" into the 6 month cycle 
> where we start at 12 months between 2.18 and 2.20 (freezewise - 2.20 
> would freeze March 15 as above), then 9 months for 2.22 (making it Jan 
> 1 2006), then 6 months from there on out?

Personally, I'm not even sure if 6 months is the ideal release cycle. 
But more on that in another message. If 6 months is decided upon, then I 
don't think we'd necessarily need an "eased transition." This mostly 
seems to be a way to cover up our overlapping feature freezes. Perhaps 
the best thing to do would be to simply "un-overlap" them (eg, reopen 
the trunk, do a March 15th freeze [if that's the date you want], and 
move on with life).

> 3) Our newly frequent releases (if we can stick to them) are going to 
> create a lot of branches to simultaneously maintain.  Should we have 
> branch managers for each branch?

I guess the big question I'd have is: what's the benefit of a branch 
maintainer? Is it just somebody other than Dave that can say whether or 
not a specific patch can land on that particular branch? I suppose that 
could be a useful thing, especially if we end up supporting a lot 
branches at the same time (more in another message, again).

> 4) b.m.o upgrade schedule was discussed.

I do like this idea, though I'm also in favor of Gerv's suggestion of 
doing the upgrade right after the feature freeze but before the branch. 
That would give roughly a two week time frame in which nothing could 
land on the trunk except for bug fixes before we branch for a new version.

> 5) What kind of branch lifetime and support level should we provide?

Now this is one of those interesting questions in life. The ongoing 
battle between software coders who want users to constantly be enjoying 
the newest features and the administrators who actually have to go 
through the pain of upgrades. So the real question here is, how often 
should we "force" somebody to upgrade. And how compatible is this with 
other means of distribution than downloading it via bugzilla.org. For 
example, I've seen some things recently where Debian's stable distro is 
in need of security patches, but it's something we abandoned long ago. 
Perhaps branch maintainers will help solve this problem. We tell them 
what our minimum support time is and if they want to continue to support 
it after that (because it's still being used somewhere special), that's 
entirely up to them.

> == Bugfixes provided
> -- Security only
>
>      Apr05 Oct05 Apr06 Oct06 Apr07 Oct07 Apr08
> 2.16 --|
> 2.18 ======-----------|
> 2.20 =======-----------|
> 2.22   |======-----------|
> 2.24         |======-----------|
> 2.26               |======-----------|
> 2.28                     |======-----------|
>
Obviously, part of the problem that's going to be causing us to have to 
support 6 branches at the same time is the overlapping feature freezes 
which is the who point of this discussion. If we do away with that and 
simply normalize right now, we'll only need to support 4 branches at 
once (which is still a lot).


From kevin.benton at amd.com  Wed Jan 12 01:16:08 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Tue, 11 Jan 2005 18:16:08 -0700
Subject: Release schedule plans
In-Reply-To: <41E46FD7.60407@bugzilla.org>
Message-ID: <20050112011608.C82981FA0@ldcmail.amd.com>

I don't think anyone is trying to bash you or force you to accept a point.
More than anything, I think people are asking themselves in disbelief, "How
far is he willing to take this?"  On the other hand, what would generate the
most happiness for you?  Look back and ask yourself if the current approach
is working for you.

What's more important?  Being right or being happy?  It's a lot easier to
work toward happiness if you can balance being right with being happy.  Is
it really that important to be right in this case?  Think about it.  I have
to think about that every day with my wife.  Is what I'm thinking about more
important than being happy?  There are times when it is, but I choose those
battles very carefully.  There are other times when it's better to say "yes,
dear" or "I'm sorry" or "you're right."  This is not about being "bud
buddies" but about being effective relating to others.  When someone acts
offensively toward another person (as we all do from time to time whether
intentional or not it's appropriate), recognize it, apologize, and move
forward with the knowledge of what happened with the goal of not reproducing
those results.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Vlad Dascalu
> Sent: Tuesday, January 11, 2005 5:31 PM
> To: developers at bugzilla.org
> Subject: Re: Release schedule plans
> 
> Shane H. W. Travis wrote:
> 
> >Since you want to talk about it in computer terms... if a message is
> >garbled -- full of noise and insignificant information -- then it is not
> up
> >to the receiver to try and find the signal in there; it is up to the
> sender
> >to try and clean up the message until it is clearly understood.
> >
> >
> Yeah. But it's more important for the network to keep its internal
> "security cohesion" rather than to have any sender understood, at any
> cost.
> 
> Anyway, in this case, I think the message got across better due to its
> direct and straightforward path.
> 
> Like Nick, you don't have access to reviewers@ and you're missing a lot
> of background, including Gerv's speech due to which (and other factors
> to be fair) he and me ended up in this "defensive" state (to which
> people only contribute more by trying to straight up things without
> having access to the original background).
> 
> >See, that's the thing. We shouldn't have to be bulletproof *from each
> >other*. We're all in this together. You may honestly have the intentions
> of
> >trying to 'trying to make everyone better', but I believe that I'm about
> the
> >fourth or fifth person now to tell you that HOW you are conveying your
> >message is interfering with the message itself. Your signal -- the good
> >parts of your message -- are having a harder time getting through because
> of
> >all the noise -- the emotion and negativity.
> >
> >
> I don't agree. Ironically, I think the emotion and negativity is what
> made people question the communication process in the first place. :-)
> 
> >If you start swinging a baseball bat around, and someone gets hurt, then
> the
> >fault is not theirs for failing to have a thick enough head.
> Furthermore,
> >if you continue to swing the bat around after people ask you repeatedly
> to
> >stop, then people are going to start avoiding you because you're painful
> and
> >dangerous to be around.
> >
> >
> That would be kind of cool because we could encourage an environment
> where you don't have to be bud buddies in order to work together. Sadly,
> the current is true in Bugzilla development and some straighten up would
> be cool to do.
> 
> Vlad.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From vladd at bugzilla.org  Wed Jan 12 01:35:42 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 03:35:42 +0200
Subject: Release schedule plans
In-Reply-To: <20050112011608.C82981FA0@ldcmail.amd.com>
References: <20050112011608.C82981FA0@ldcmail.amd.com>
Message-ID: <41E47EEE.1020300@bugzilla.org>

Kevin Benton wrote:

>More than anything, I think people are asking themselves in disbelief, "How
>far is he willing to take this?"
>
I'm asking myself how far are you guys going to keep this unproductive 
discussion on emotional issues and what it takes to focus on the topic 
(see subject).

>On the other hand, what would generate the
>most happiness for you?
>
My current happiness is related to Bugzilla devel improvements. I stated 
this in the past. Are we going over this again? *sigh*

>  Look back and ask yourself if the current approach
>is working for you.
>  
>
Yes it is.

>What's more important?  Being right or being happy?
>
Being happy. That is, making Bugzilla devel improvements, even if I'm wrong.

>  It's a lot easier to
>work toward happiness if you can balance being right with being happy.
>
There's no need to balance because I don't have any primary goal as 
being right. Of course, if that proves a secondary goal in order to 
fulfill the primary one, then ok, but there's no conflict then and no 
balance thing needed.

>  Is
>it really that important to be right in this case?
>
I don't want to be right about it, and it's not important. However, I 
don't follow you. How did you end up to think that it's important for me 
to be right? And how it's more productive to pshyco-emotionally analyse 
me rather then stick with the topic? :)

>When someone acts
>offensively toward another person (as we all do from time to time whether
>intentional or not it's appropriate), recognize it, apologize, and move
>forward with the knowledge of what happened with the goal of not reproducing
>those results.
>  
>
I already appologized generically for all the things that came out rude 
without me wanting to say them that way. That is not the issue here. ;-)

Vlad.



From jake at bugzilla.org  Wed Jan 12 02:01:55 2005
From: jake at bugzilla.org (Jake)
Date: Tue, 11 Jan 2005 21:01:55 -0500
Subject: Release schedule plans
In-Reply-To: <41E2CB79.8060102@mozilla.org>
References: <65482.1105360826@thrush.ravenbrook.com> <41E2CB79.8060102@mozilla.org>
Message-ID: <41E48513.8070909@bugzilla.org>

Gervase Markham wrote:

> I don't like the sound of that at all. Currently we are managing 
> three, and it's more than enough. I'd argue this is a reason to either 
> extend the development cycle or shorten the support cycle.


I have to agree with this, though I don't think shorten the support 
cycle is the right answer. I wonder if a 9 or even 12 month release 
cycle might be better suited for us.


From djm at mindrot.org  Wed Jan 12 05:47:15 2005
From: djm at mindrot.org (Damien Miller)
Date: Wed, 12 Jan 2005 16:47:15 +1100
Subject: Release schedule plans
In-Reply-To: <41E44C8B.10304@prosys.fi>
References: <41E30488.9000708@mozilla.org> <41E44C8B.10304@prosys.fi>
Message-ID: <41E4B9E3.9060100@mindrot.org>

Harri Vartiainen wrote:
> Gervase Markham wrote:
> 
>> It seems that we have three choices:
>>
>> a) Release 2.18 and release 2.20 soon afterwards
>> b) Release 2.18, unfreeze for a bit, and release 2.20 in (say) June
>> c) Abandon 2.18 and just release 2.20
> 
> 
>  From the users point of view, release  "official stable version" as 
> fast as possible. Don't care if it is 2.18 or 2.20. There's huge gap 
> between "developer versions" and version 2.16.x.

(delurk)

Since we are talking about users, I'll add my opinion :) I run the
OpenSSH bugzilla, currently using 2.16 and I'm waiting for the next
stable release because it has features that would be useful for myself
and the other developers.

I don't care even a little bit what the next stable version is numbered,
but I don't want to have to do the upgrade dance repeatedly in the space
of a month or two to track the latest stable version.

I'll also mention that I don't consider it acceptable to sit for over
one month on a security bugfix, just because it doesn't fit with your
releasing plans. That is putting the cart before the proverbial horse.

-d


From mkanat at kerio.com  Wed Jan 12 06:05:39 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Tue, 11 Jan 2005 22:05:39 -0800
Subject: Status Update: Please Help...
Message-ID: <1105509939.25138.32.camel@localhost.localdomain>

	OK, so the last major remaining administrative task before we release
2.18 is the Status Update. This is the big one.

	Who wants to do it? It'll make me happy. It'll make Dave happy.

	It will make *everybody* happy.

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

	-Max




From gerv at mozilla.org  Wed Jan 12 09:48:22 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 12 Jan 2005 09:48:22 +0000
Subject: Release schedule plans
In-Reply-To: <41E46FD7.60407@bugzilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net> <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca> <41E46FD7.60407@bugzilla.org>
Message-ID: <41E4F266.9040207@mozilla.org>

Vlad Dascalu wrote:
> Like Nick, you don't have access to reviewers@ and you're missing a lot 
> of background, including Gerv's speech due to which (and other factors 
> to be fair) he and me ended up in this "defensive" state (to which 
> people only contribute more by trying to straight up things without 
> having access to the original background).

I'm not in a defensive state.

Vlad, I think you are mistaken - the entire conversation about your way 
of communicating has taken place on developers at . I can't see any message 
on reviewers@ which could be classified as a 'speech'.

Several people are now politely pointing out that they have difficulties 
with your communications style. You can continue to ignore this feedback 
(in which case, you are still swinging the baseball bat, and the obvious 
consequences will probably follow) or you could think "hmm, now three 
people have told me the same thing - perhaps they have a point".

I should note again here that it took several people telling me this 
over a long period before I actually got it. Perhaps you just have to 
say "I don't understand why it is that people react in this way, and 
don't like people communicating like that, but they don't. So I just 
have to accept that fact."

After all, if the goal of communication is to communicate, one should 
make every effort to communicate in a way that people appreciate.

Gerv


From Nick.Barnes at pobox.com  Wed Jan 12 12:03:51 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Wed, 12 Jan 2005 12:03:51 +0000
Subject: Release schedule plans
In-Reply-To: <41E462F1.2050701@bugzilla.org> 
   from Vlad Dascalu <vladd@bugzilla.org> 
   of "Wed, 12 Jan 2005 01:36:17 +0200"
Message-ID: <74627.1105531431@thrush.ravenbrook.com>

At 2005-01-11 23:36:17+0000, Vlad Dascalu writes:

> The important thing is to learn how to receive a message, because in
> this way we'll end up invulnerable to every sender.

Yes.  Speaking as a recipient[*], I have learned to totally ignore
flamers, because in my experience[*2] the result of winnowing the value
from the flames is rarely worth the effort.

I believe that there are a lot of other recipients who operate a
similar filter.

Nick B

[*] irony intended.

[*2] now lengthy.


From vladd at bugzilla.org  Wed Jan 12 15:41:44 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 17:41:44 +0200
Subject: Release schedule plans
In-Reply-To: <41E4F266.9040207@mozilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net> <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca> <41E46FD7.60407@bugzilla.org> <41E4F266.9040207@mozilla.org>
Message-ID: <41E54538.3080401@bugzilla.org>

Gervase Markham wrote:

> I'm not in a defensive state.

Gerv, I think you are. But you don't realise that. At least you were in 
a specific defensive state when you started this whole flame thing while 
writting at the same time:

 >> This is NOT trying to start a flamewar with Vlad

Post-mortem, that's exactly what you did. And I believe pretty high 
about your intelligence, so I doubt you would have missed what you were 
about to do, unless for the defensive state in which you were.

> Vlad, I think you are mistaken - the entire conversation about your 
> way of communicating has taken place on developers at . I can't see any 
> message on reviewers@ which could be classified as a 'speech'.

Replace 'speech' with 'arguments' pending between you and me on 
developers@ and you'll get a much bigger picture of what I intended. The 
sentence:

>> please stop attacking Dave



came after the long reviewers@ discussion. It's not something that you 
would have said to me out of the blue, only after that single 
developers@ email, or without you in a defensive state. Assuming by 
absurd that indeed this is the case, that email is only about the 
"discretion" thing that I explained in a follow up (to which you didn't 
reply). So I think you have to agree that the reviewers@ thing was the 
source that started this flame.

> Several people are now politely pointing out that they have 
> difficulties with your communications style. You can continue to 
> ignore this feedback (in which case, you are still swinging the 
> baseball bat, and the obvious consequences will probably follow) or 
> you could think "hmm, now three people have told me the same thing - 
> perhaps they have a point".

Several people, including you, keep feeding to this thread its flames. 
Several people are replying to emotional stuff instead of focusing on 
the topic, the Release schedule. Several people are derailing the 
conversation. I'm certainly not ignoring the feedback. It's a thing that 
will reflect upon your evaluation.

I suggest to stop formulating things in a threatning way: "obvious 
consequences will probably follow". I am very much aware of the 
consequences of my actions and I am partially pleased on how that went. 
If you instead would be more focused on improving the Bugzilla's goals 
and interests instead of improving the communication environment, then 
Bugzilla would be better in the long term. You have to learn that not 
always "by the book" communication is in the project's interests.

People don't have difficulties with my communication style, because, if 
anything, you could have learned over the past years that my regular 
contributor style of discussion is quite relaxed and welcomed. What 
people have difficulties with is understanding that they can't comment 
out on the situation without having the background knowledge on 
reviewers@ (all the people that jumped in your wagon train, Nick, Shane, 
Kevin, lacked that). Also, they have difficulties understanding that 
this is a specific case where I made communication the #2 priority and 
moved Bugzilla's interests to the first place. Otherwise, I wouldn't 
classify those as "difficulties".

> I should note again here that it took several people telling me this 
> over a long period before I actually got it. Perhaps you just have to 
> say "I don't understand why it is that people react in this way, and 
> don't like people communicating like that, but they don't. So I just 
> have to accept that fact."

I understand perfectly why people reacted in this spirit. It's due to 
parts of your and my emails that don't have anything to do with the 
topic. The inability to focus on the issues that matters is worthy to be 
further analysed and solutions developed to that, although I reckon it's 
a human trace :-)

> After all, if the goal of communication is to communicate, one should 
> make every effort to communicate in a way that people appreciate.

No. The goal of communication is in this case to reach the Bugzilla 
goals. If it were to simply communicate, we wouldn't have reached this 
point in the first place.

Vlad.


From vladd at bugzilla.org  Wed Jan 12 15:43:18 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 17:43:18 +0200
Subject: Release schedule plans
In-Reply-To: <74627.1105531431@thrush.ravenbrook.com>
References: <74627.1105531431@thrush.ravenbrook.com>
Message-ID: <41E54596.7000305@bugzilla.org>

Nick Barnes wrote:

>Yes.  Speaking as a recipient[*], I have learned to totally ignore
>flamers
>
I think you just proved that you haven't :-). Out of 3 mails that you 
sent in this thread, 2 are dedicated to the flame thing. :-) And one of 
those only gave food to the flame to grow bigger.

Vlad.


From Nick.Barnes at pobox.com  Wed Jan 12 16:10:10 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Wed, 12 Jan 2005 16:10:10 +0000
Subject: Release schedule plans
In-Reply-To: <41E54596.7000305@bugzilla.org> 
   from Vlad Dascalu <vladd@bugzilla.org> 
   of "Wed, 12 Jan 2005 17:43:18 +0200"
Message-ID: <75834.1105546210@thrush.ravenbrook.com>

At 2005-01-12 15:43:18+0000, Vlad Dascalu writes:
> Nick Barnes wrote:
> 
> >Yes.  Speaking as a recipient[*], I have learned to totally ignore
> >flamers
> >
> I think you just proved that you haven't :-). Out of 3 mails that you 
> sent in this thread, 2 are dedicated to the flame thing. :-) And one of 
> those only gave food to the flame to grow bigger.

You are incorrect.  I have sent three mails in this thread:

1. Message-ID: <65482.1105360826 at thrush.ravenbrook.com>
   Date: Mon, 10 Jan 2005 12:40:26 +0000

   Direct response to justdave's initial message, discussing freezes,
   ASCIIgrams, etc.

2. Message-ID: <71844.1105463250 at thrush.ravenbrook.com>
   Date: Tue, 11 Jan 2005 17:07:30 +0000

   Pointing out that b.m.o is testing 2.20 more than 2.18.

3. Message-ID: <74627.1105531431 at thrush.ravenbrook.com>
   Date: Wed, 12 Jan 2005 12:03:51 +0000

   The message to which you are responding, and which was not, of
   course, responding to a flame.  I was responding to a fairly polite
   message discussing flame-handling policies.

Nick B


From travis at SEDSystems.ca  Wed Jan 12 16:46:17 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Wed, 12 Jan 2005 10:46:17 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E4F266.9040207@mozilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
 <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
 <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca>
 <41E46FD7.60407@bugzilla.org> <41E4F266.9040207@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501121032340.10878@milhouse.SEDSystems.ca>



On Wed, 12 Jan 2005, Gervase Markham wrote:

> Vlad Dascalu wrote:
> > Like Nick, you don't have access to reviewers@ and you're missing a lot
> > of background,

(that comment was aimed at me, but I'm responding to Gerv's message that
includes it.)

I may not be on the reviewers mailing list, but I'm well aware of everything
that has been said on it, as one of its recipients has been (at my request)
forwarding the relevant discussion to me as it takes place.

So I'm *not* missing any background. I am aware of every word written
by both you and those responding to you... and I stand by my earlier
statements.


> Several people are now politely pointing out that they have difficulties
> with your communications style. You can continue to ignore this feedback
> (in which case, you are still swinging the baseball bat, and the obvious
> consequences will probably follow) or you could think "hmm, now three
> people have told me the same thing - perhaps they have a point".

/me nods at Gerv

Vlad, what you seem to be missing is that quite a number of people are
trying to help you out. They (and I) are collectively saying, "From what I
know of you and your past behaviour, I judge that you aren't intending to
piss anyone off or hurt anyone's feelings. Nonetheless, you are doing so.
Here is how what you are saying is being interpreted, and here are some
suggestions on how you could change that."

This isn't being done because people *dis*like you; quite the contrary. If
people didn't like and respect you, they wouldn't bother trying to help;
they'd just tune you out. Would that we all had people who respected us and
cared enough about us to be gently honest with us.

If you continue to rebuff any attempts to help and to reject all feedback,
however, then the logical assumption to make is that you *knnow* that you
are hurting people and pissing them off, and that you don't care. Having
made that logical leap, a lot of people will end up losing that 'like' and
'respect', and a lot more of them will tune you out.

This is neither a threat nor an attempt to shut you up; it is simply my
observations of human nature.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From vladd at bugzilla.org  Wed Jan 12 17:52:14 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 19:52:14 +0200
Subject: Release schedule plans
In-Reply-To: <Pine.GHP.4.58.0501121032340.10878@milhouse.SEDSystems.ca>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net> <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net> <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca> <41E46FD7.60407@bugzilla.org> <41E4F266.9040207@mozilla.org> <Pine.GHP.4.58.0501121032340.10878@milhouse.SEDSystems.ca>
Message-ID: <41E563CE.3010104@bugzilla.org>

Shane H. W. Travis wrote:

>I may not be on the reviewers mailing list, but I'm well aware of everything
>that has been said on it, as one of its recipients has been (at my request)
>forwarding the relevant discussion to me as it takes place.
>  
>
I think we should discourage such practices. Either that or we make the 
reviewers@ thing public.

>If you continue to rebuff any attempts to help and to reject all feedback,
>however, then the logical assumption to make is that you *knnow* that you
>are hurting people and pissing them off, and that you don't care.
>
I will continue to do things that make me happy, that is continue the 
improvement of the devel process.

I don't reject any feedback at all, I welcome suggestions like everybody 
else should. But I'm not steering away from my direction.

You guys are free to understand what you want, to make whatever 
assumptions you might like, and to react accordingly.

Vlad.


From travis at SEDSystems.ca  Wed Jan 12 17:50:53 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Wed, 12 Jan 2005 11:50:53 -0600 (CST)
Subject: Release schedule plans
In-Reply-To: <41E563CE.3010104@bugzilla.org>
References: <41E4391F.8010500@mozilla.org> <Pine.LNX.4.61.0501111550250.22995@skippy.fini.net>
 <41E4424C.2070508@bugzilla.org> <Pine.LNX.4.61.0501111738130.22995@skippy.fini.net>
 <41E462F1.2050701@bugzilla.org> <Pine.GHP.4.58.0501111731510.9264@milhouse.SEDSystems.ca>
 <41E46FD7.60407@bugzilla.org> <41E4F266.9040207@mozilla.org>
 <Pine.GHP.4.58.0501121032340.10878@milhouse.SEDSystems.ca>
 <41E563CE.3010104@bugzilla.org>
Message-ID: <Pine.GHP.4.58.0501121140550.10878@milhouse.SEDSystems.ca>



On Wed, 12 Jan 2005, Vlad Dascalu wrote:

> Shane H. W. Travis wrote:
>
> >I may not be on the reviewers mailing list, but I'm well aware of everything
> >that has been said on it, as one of its recipients has been (at my request)
> >forwarding the relevant discussion to me as it takes place.
> >
> I think we should discourage such practices. Either that or we make the
> reviewers@ thing public.

I would generally agree, and I would bet that the person who sent them to me
would generally agree too. It's a closed list for a reason -- so that only
people who have permission to view those messages may do so.

I have such permission. Dave has said that he would put me on the list if
I want to be there, so I have a right to view those messages; the fact that
I get those messages second-hand does not change the legitimacy of my
accessing them. The person who forwarded them to me did nothing wrong.

As I said, I stand by my earlier comments; your message may be important,
but how you are choosing to get it across is interfering with its reception.
If you truly care as much about people paying attention as you have
repeatedly claimed, then I would think that you would welcome -- and utilize
-- any suggestions on how to make people *more* willing to listen to it.

Perhaps you are listening to all the feedback... but so far, I've seen very
little of it put to use.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From kevin.benton at amd.com  Wed Jan 12 18:23:11 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Wed, 12 Jan 2005 11:23:11 -0700
Subject: FW: email notification in windows installation
Message-ID: <20050112182311.727CA1FBD@ldcmail.amd.com>

I wonder - how difficult it would be for us to move to Mail::Sender rather
than relying on Sendmail?

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

-----Original Message-----
From: mozilla-webtools-admin at mozilla.org
[mailto:mozilla-webtools-admin at mozilla.org] On Behalf Of Torsten
Sent: Wednesday, January 12, 2005 10:03 AM
To: mozilla-webtools at mozilla.org
Subject: email notification in windows installation

Hi,

I am using  Bugzilla Version 2.18rc3 on Windows XP. Is it possible to have 
email notification setup in this installations? I checked alread the 
Token.pm

open SENDMAIL, "|/usr/lib/sendmail -t -i";

What do I have to install?

Thanks
Torsten 


_______________________________________________
mozilla-webtools mailing list
mozilla-webtools at mozilla.org
http://mail.mozilla.org/listinfo/mozilla-webtools





From vladd at bugzilla.org  Wed Jan 12 18:49:32 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Wed, 12 Jan 2005 20:49:32 +0200
Subject: FW: email notification in windows installation
In-Reply-To: <20050112182311.727CA1FBD@ldcmail.amd.com>
References: <20050112182311.727CA1FBD@ldcmail.amd.com>
Message-ID: <41E5713C.4010606@bugzilla.org>

It's already done. It expects the tip to reopen to features. See 
https://bugzilla.mozilla.org/show_bug.cgi?id=277437 .

Vlad.

Kevin Benton wrote:

>I wonder - how difficult it would be for us to move to Mail::Sender rather
>than relying on Sendmail?
>
>---
>Kevin Benton
>Perl/Bugzilla Developer
>Advanced Micro Devices
> 
>The opinions stated in this communication do not necessarily reflect the
>view of Advanced Micro Devices and have not been reviewed by management.
>This communication may contain sensitive and/or confidential and/or
>proprietary information.  Distribution of such information is strictly
>prohibited without prior consent of Advanced Micro Devices.  This
>communication is for the intended recipient(s) only.  If you have received
>this communication in error, please notify the sender, then destroy any
>remaining copies of this communication.
> 
> 
>
>-----Original Message-----
>From: mozilla-webtools-admin at mozilla.org
>[mailto:mozilla-webtools-admin at mozilla.org] On Behalf Of Torsten
>Sent: Wednesday, January 12, 2005 10:03 AM
>To: mozilla-webtools at mozilla.org
>Subject: email notification in windows installation
>
>Hi,
>
>I am using  Bugzilla Version 2.18rc3 on Windows XP. Is it possible to have 
>email notification setup in this installations? I checked alread the 
>Token.pm
>
>open SENDMAIL, "|/usr/lib/sendmail -t -i";
>
>What do I have to install?
>
>Thanks
>Torsten 
>
>
>_______________________________________________
>mozilla-webtools mailing list
>mozilla-webtools at mozilla.org
>http://mail.mozilla.org/listinfo/mozilla-webtools
>
>
>
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>
>  
>



From gerv at mozilla.org  Wed Jan 12 23:15:20 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 12 Jan 2005 23:15:20 +0000
Subject: Release timing
Message-ID: <41E5AF88.6030405@mozilla.org>

While just dumping 2.18 and going straight to 2.20 (under whatever name) 
seems very attractive, our users are clamouring for a stable release 
ASAP. See, for example, the posts on this list from the SSH guy and 
others. I think that, having put all this work in (all we need is a 
status update), we need to kick it out of the door. So abandoning 2.18 
is really not an option at this stage.

So what are the possible reasons for branching for 2.20 very soon?

- Have we got many features over 2.18? Not really.
- Has it been around six months since our last release? No :-)

The only reason I can see to release 2.20 soon is because now is about 
the time we said we'd release it when we did the initial plan a year 
ago. There's a much-parodied but useful saying in my company: "A plan is 
a basis for change". So much has changed in the circumstances; is now 
not time to change the plan?

If we are really planning to support every release for 18 months, having 
releases closer than 6 months apart would be horrible. I suggest that 
option c) is correct.

We should unfreeze the trunk, check in all those patches which are 
waiting, and refreeze about four months after the date we release 2.18, 
aiming to release 2.20 six months after that date.

Gerv


From kevin.benton at amd.com  Thu Jan 13 01:21:14 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Wed, 12 Jan 2005 18:21:14 -0700
Subject: FW: email notification in windows installation
In-Reply-To: <41E5713C.4010606@bugzilla.org>
Message-ID: <20050113012114.3F6AA1FBD@ldcmail.amd.com>

Fantastic :)

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Vlad Dascalu
> Sent: Wednesday, January 12, 2005 11:50 AM
> To: developers at bugzilla.org
> Subject: Re: FW: email notification in windows installation
> 
> It's already done. It expects the tip to reopen to features. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=277437 .
> 
> Vlad.
> 
> Kevin Benton wrote:
> 
> >I wonder - how difficult it would be for us to move to Mail::Sender
> rather
> >than relying on Sendmail?
> >
> >---
> >Kevin Benton
> >Perl/Bugzilla Developer
> >Advanced Micro Devices
> >
> >The opinions stated in this communication do not necessarily reflect the
> >view of Advanced Micro Devices and have not been reviewed by management.
> >This communication may contain sensitive and/or confidential and/or
> >proprietary information.  Distribution of such information is strictly
> >prohibited without prior consent of Advanced Micro Devices.  This
> >communication is for the intended recipient(s) only.  If you have
> received
> >this communication in error, please notify the sender, then destroy any
> >remaining copies of this communication.
> >
> >
> >
> >-----Original Message-----
> >From: mozilla-webtools-admin at mozilla.org
> >[mailto:mozilla-webtools-admin at mozilla.org] On Behalf Of Torsten
> >Sent: Wednesday, January 12, 2005 10:03 AM
> >To: mozilla-webtools at mozilla.org
> >Subject: email notification in windows installation
> >
> >Hi,
> >
> >I am using  Bugzilla Version 2.18rc3 on Windows XP. Is it possible to
> have
> >email notification setup in this installations? I checked alread the
> >Token.pm
> >
> >open SENDMAIL, "|/usr/lib/sendmail -t -i";
> >
> >What do I have to install?
> >
> >Thanks
> >Torsten
> >
> >
> >_______________________________________________
> >mozilla-webtools mailing list
> >mozilla-webtools at mozilla.org
> >http://mail.mozilla.org/listinfo/mozilla-webtools
> >
> >
> >
> >-
> >To view or change your list settings, click here:
> ><http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
> >
> >
> >
> >
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From vladd at bugzilla.org  Thu Jan 13 10:14:41 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Thu, 13 Jan 2005 12:14:41 +0200
Subject: Release timing
In-Reply-To: <41E5AF88.6030405@mozilla.org>
References: <41E5AF88.6030405@mozilla.org>
Message-ID: <41E64A11.9070800@bugzilla.org>

Gervase Markham wrote:

> - Has it been around six months since our last release? No :-)

We never said that releases should be 6 months apart. We only talked 
about freezes.

We could modify the plan and say that freezes happen 6 months after the 
last release is out. So the time distance between releases would be 6 
months + the time required for stabilization. This would still allow 
time-based releases, but would prevent situations like this one. Just 
brainstorming.

Vlad.

>
> The only reason I can see to release 2.20 soon is because now is about 
> the time we said we'd release it when we did the initial plan a year 
> ago. There's a much-parodied but useful saying in my company: "A plan 
> is a basis for change". So much has changed in the circumstances; is 
> now not time to change the plan?
>
> If we are really planning to support every release for 18 months, 
> having releases closer than 6 months apart would be horrible. I 
> suggest that option c) is correct.
>
> We should unfreeze the trunk, check in all those patches which are 
> waiting, and refreeze about four months after the date we release 
> 2.18, aiming to release 2.20 six months after that date.
>
> Gerv
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>



From Nick.Barnes at pobox.com  Thu Jan 13 13:04:15 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Thu, 13 Jan 2005 13:04:15 +0000
Subject: Release timing
In-Reply-To: <41E64A11.9070800@bugzilla.org> 
   from Vlad Dascalu <vladd@bugzilla.org> 
   of "Thu, 13 Jan 2005 12:14:41 +0200"
Message-ID: <79808.1105621455@thrush.ravenbrook.com>

At 2005-01-13 10:14:41+0000, Vlad Dascalu writes:
> Gervase Markham wrote:
> 
> > - Has it been around six months since our last release? No :-)
> 
> We never said that releases should be 6 months apart. We only talked 
> about freezes.

I thought we *did* say that releases should be 6 months apart.
Archives, anyone?

There are two quite separate aspects to this.  

1. The customer view

The first aspect is the view of Bugzilla 'customers'.  They like a
steady stream of releases; "every six months" is good for them.  This
relates to evolutionary development models: if you release often, you
get good feedback, can adjust your model of customer requirements, and
end up with a better product (i.e. one which better fits
requirements).  Unsurprisingly, customers like this, and greatly
prefer it to big-bang models (one release after five years, then fold
the project) or to when-its-ready models (which, more-or-less,
Bugzilla has been following until now: release 2.x will be when
features X, Y, and Z are complete).  Predictable release dates are
also good for customer relations because they allow customers to plan
their upgrade path.  This should not be underestimated for large sites
which have a lot invested in templates, customizations, integrations,
plugins, administrative procedures, training of admins and users, and
so on.

Depending on the frequency of regular releases, some customers may
choose to skip a release.  Few will actually *object* to more frequent
releases, as long as they remain regular, as they like being given the
choice, to balance the cost of an upgrade against the benefit of new
features or bug fixes.  However, there is a frequency, a point of
diminishing returns, at which too few customers actually take up each
new release (you need some customers to take up the new releases in
order to get good feedback, which is the whole point of the
evolutionary model).  The actual best frequency will depend on the
nature of your software, the number of your customers, and the cost of
making new releases.  For some projects, this frequency may be
monthly, weekly, or even more often (how often is the BBC News website
"re-released"?).  I strongly suspect that Bugzilla customers would be
very happy with a six-month release cycle.  They are demonstrably
unhappy with a 2-to-3-year cycle, and the consensus here is that a
3-month cycle is too short.

The notion of a "freeze" is totally meaningless to customers (although
problems in change management processes, which freezes are intended to
solve, do have effects on customers, in reducing the responsiveness of
development).

2. The developer view

The second aspect is entirely internal to the Bugzilla development
process.  With the current process, the trunk is frozen for the
"stabilization period" between rc1 (at the branch point) and .0, while
we fix bugs on the branch to make it acceptable as .0.  The length of
this freeze depends on three things.

1. how bad the branch point is, 
2. how quickly we fix it, and 
3. how good it needs to be to become .0.

How bad the branch point is depends on:

1.1. how bad the previous branch point was, and

1.2. how long ago that was.  If the previous branch point was fairly
     recent, we haven't had much chance to mess up the trunk.
     Furthermore, this is not a linear process (see 1.3).

1.3. the net defect introduction rate, i.e. how quickly we mess it up.
     This depends on development practices and also on defect
     discovery (i.e. testing, for Bugzilla), which depends in turn on
     the active users of the trunk.  For instance, there's a plausible
     belief that it depends quite sensitively on how far b.m.o is from
     the trunk (because b.m.o finds bugs and motivates us to fix
     them).  This also depends on how long ago the previous branch
     was, as bug fixes (negative defect introductions) are usually
     applied both to a branch and to the trunk, when the branch is
     recent.  So there's a non-linear process here.

How quickly we fix the branch (the net defect removal rate) depends
on:

2.1. the developers available;

2.2. the motivation of those developers to make it to .0;

2.3. the defect discovery rate (for Bugzilla, this translates as
     testing).

How good the branch needs to be to become .0 depends on:

3.1. how well tested it is, and

3.2. a bunch of other factors, which this message is already too long
     to contain.

Now obviously a long freeze is a bad thing.  Consider it a just
punishment for introducing so many defects into the trunk!  But the
purpose of the above analysis is to show that a long freeze is a
*consequence* of a long release cycle.  It's a non-linear effect (see
1.3 above): if you double your cycle time then you may triple or
quadruple your freeze time.  If you multiply your cycle time by, say,
five (from six months to 2.5 years), then who knows what happens to
the freeze time.

Given a short release cycle, freezes will shorten.  Given a six-month
cycle, I would be surprised if we get freezes of more than about six
weeks.  It might be much less.

How does one move forwards from this observation?  I recommend
planning a six-month release cycle, with two-month freezes.  Announce
a plan like this:

2005-06-01 branch for 2.20, release 2.20rc1, freeze trunk.

2005-07-31 release 2.20.0, thaw trunk.

2005-12-01 branch for 2.22, release 2.22rc1, freeze trunk.

2006-01-31 release 2.22.0, thaw trunk.

Do not set any dates more than two releases ahead.  Sketch a feature
plan for 2.20 and 2.22 based on this timescale, but say that if a
feature is not done at freeze time then it gets yanked.  It's good to
be firm about this, and be prepared to *yank a new feature out of the
trunk* at freeze time, *or even during the freeze*, if it's too buggy
to fix in time.  And if you get a short freeze (i.e. if .0 is ready
*before* the planned release date) then bring the release forward and
you get bonus thaw time.

I promised myself I'd get some paid work done today.

Nick B


From gerv at mozilla.org  Thu Jan 13 21:39:59 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 13 Jan 2005 21:39:59 +0000
Subject: Documentation for the release
Message-ID: <41E6EAAF.9070201@mozilla.org>

Our usual practice is to try to fix all docs bugs before the release. Is 
that what's going to happen here?

Is anyone allowed to dive in and fix docs, or do I need to coordinate 
with someone?

Gerv


From justdave at bugzilla.org  Thu Jan 13 21:51:49 2005
From: justdave at bugzilla.org (David Miller)
Date: Thu, 13 Jan 2005 16:51:49 -0500
Subject: Documentation for the release
In-Reply-To: <41E6EAAF.9070201@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org>
Message-ID: <41E6ED75.6060807@bugzilla.org>

Gervase Markham wrote:
> Our usual practice is to try to fix all docs bugs before the release. Is 
> that what's going to happen here?
> 
> Is anyone allowed to dive in and fix docs, or do I need to coordinate 
> with someone?

That's been almost the entirety of what Shane, Jake, and Vlad have been 
working on for the last 2 months or so.  We're so far behind on docs 
it's not funny (and we're light-years ahead of where we were two months 
ago).  If we held the release to have the docs up-to-date, you're 
talking about delaying the release by at least another month, minimum.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From justdave at bugzilla.org  Thu Jan 13 22:09:36 2005
From: justdave at bugzilla.org (David Miller)
Date: Thu, 13 Jan 2005 17:09:36 -0500
Subject: 2.20 Freeze status
Message-ID: <41E6F1A0.2010607@bugzilla.org>

The decision has been made.

We will be reopening the trunk for development and aborting the 2.20 
freeze.  Our previous release schedule will be pushed back 6 months, so 
that we will now be freezing for 2.20 on March 15th 2005, and for 2.22 
(or 3.0, or whatever the next version winds up being) on September 15th, 
2005.  We have very good faith still that this whole mess was caused 
because of the huge development window that 2.18 used, and as long as we 
keep to this schedule from now on, we shouldn't have to do this again.

In order to keep everyone focused on the release process, the trunk will 
not reopen until 2.16.8, 2.18, and 2.19.2 are released.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From travis at SEDSystems.ca  Thu Jan 13 22:07:08 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Thu, 13 Jan 2005 16:07:08 -0600 (CST)
Subject: Documentation for the release
In-Reply-To: <41E6EAAF.9070201@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca>



On Thu, 13 Jan 2005, Gervase Markham wrote:

> Our usual practice is to try to fix all docs bugs before the release. Is
> that what's going to happen here?

It is? Then how did *any* previous releases make it out the door? ;)

In this case, it's just not going to get done -- not completely, anyway.
Jake has been away for a year, and was briefly active again but has now lost
the access he had during that period. I'm the only other one that has really
done any work on docs during most of that time (that I can see), although
vlad was kind enough to review and check things in before I had privs to do
so myself.

I've been helping push 2.18 from a code standpoint in the last two weeks;
prior to that I was doing almost exclusively documentation and trying to get
things caught up. My intent is to get back to docs in the immediate future
(i.e. next 7 days or so). First priority is new docs for enhancements, then
after that I'll start fixing up the errors.


> Is anyone allowed to dive in and fix docs, or do I need to coordinate
> with someone?

Jake, Dave, Vlad and I had a discussion about this, and it resulted in the
following consensus;

1) Anyone can make a patch for a docs bug, same as for a regular bug.
2) Someone else on the docs team has to give it an r+ before it can be
	checked in. It should be correct in three ways before it gets
	that r+; grammatically, informationally, and SGML-wise.
3) Approval is unnecessary. r+ == a+ so it can be checked in after one
	positive review.

If you (Gerv) want to help review my docs patches, that'd be very useful; I
expect there to be a fair few of them in the next few days. There have been
two already sitting in the review queue for at least a couple of weeks while
Jake is busy in Iraq and vlad is... well, I don't know why vlad isn't
reviewing them, honestly.

If you (Gerv) want to help by *writing* docs... please hit the ones in the
Bugzilla Documentation Component... especially the ones you know the answers
to  -- 274509, 275701, anything you originated, and probably anything to do
with LDAP.

If anyone *else* wants to help on docs bugs, I'd appreciate it, especially
if it's a docs bug for an enhancement that you wrote. You don't even have to
be perfect; just get down as much info as you can in a .txt file and attach
it to the bug. Some of these enhancements I don't know anything about, so
more information will stop me from having to hunt you down. ;)


Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From gerv at mozilla.org  Thu Jan 13 22:29:14 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 13 Jan 2005 22:29:14 +0000
Subject: Documentation for the release
In-Reply-To: <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca>
Message-ID: <41E6F63A.7010405@mozilla.org>

Shane H. W. Travis wrote:
> It is? Then how did *any* previous releases make it out the door? ;)

See below.

>>Is anyone allowed to dive in and fix docs, or do I need to coordinate
>>with someone?
> 
> Jake, Dave, Vlad and I had a discussion about this, and it resulted in the
> following consensus;
> 
> 1) Anyone can make a patch for a docs bug, same as for a regular bug.
> 2) Someone else on the docs team has to give it an r+ before it can be
> 	checked in. It should be correct in three ways before it gets
> 	that r+; grammatically, informationally, and SGML-wise.
> 3) Approval is unnecessary. r+ == a+ so it can be checked in after one
> 	positive review.

Ah. Without wanting to blow my own trumpet, the reason the 2.16 docs 
were reasonable was that I sat down one weekend and spent 12 hours 
straight hacking on them. Doing that within any sort of review procedure 
just isn't practical.

However, in that case, I had the field to myself. If there are other 
people doing docs things, that would make it very hard to do.

I could make time for such a hackathon this weekend, if others can get 
their patches in before then and stay out of the way ;-). You can then 
review the result in its entirety, by reading it, rather than as 
patches. Does that sound do-able?

> If you (Gerv) want to help by *writing* docs... please hit the ones in the
> Bugzilla Documentation Component... especially the ones you know the answers
> to  -- 274509, 275701, anything you originated, and probably anything to do
> with LDAP.

I know nothing about LDAP :-)

Gerv


From justdave at bugzilla.org  Thu Jan 13 23:03:45 2005
From: justdave at bugzilla.org (David Miller)
Date: Thu, 13 Jan 2005 18:03:45 -0500
Subject: Documentation for the release
In-Reply-To: <41E6F63A.7010405@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org>
Message-ID: <41E6FE51.60301@bugzilla.org>

Gervase Markham wrote:

> I could make time for such a hackathon this weekend, if others can get 
> their patches in before then and stay out of the way ;-). You can then 
> review the result in its entirety, by reading it, rather than as 
> patches. Does that sound do-able?

Quite frankly, that makes me a bit nervous.  I'm still remembering a 
major docs checkin about a year ago or so that went something along the 
lines of "hey guys, I just checked in a major revision to the 
documentation", which none of us knew was coming, and nobody had time to 
go back and audit.  At the time I just said "oh, I trust Gerv, we'll 
just hope it was good" and then over the following months, it turned out 
important things disappeared, and all of those changes that were also 
applicable to 2.16 never got backported to the 2.16 docs.

I'd very much prefer patches to each of the docs bugs for the specific 
things they cover (some of those bugs are for reorganization type 
changes, if I recall correctly, so some of them are ripe for 
larger-sized patches).

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Thu Jan 13 23:21:23 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 13 Jan 2005 23:21:23 +0000
Subject: 2.20 Freeze status
In-Reply-To: <41E6F1A0.2010607@bugzilla.org>
References: <41E6F1A0.2010607@bugzilla.org>
Message-ID: <41E70273.5050004@mozilla.org>

David Miller wrote:
> We will be reopening the trunk for development and aborting the 2.20 
> freeze.  Our previous release schedule will be pushed back 6 months, so 
> that we will now be freezing for 2.20 on March 15th 2005, and for 2.22 
> (or 3.0, or whatever the next version winds up being) on September 15th, 
> 2005.  

I still suggest that we should only fix the proposed release date of 
version X + 2 when we've released version X, and try hard to make the X 
-> X + 2 difference about six months.

So say we release 2.18 on 20th January. We then say "OK, we want to 
release 2.20 on 20th July, so let's freeze on 20th April, two months 
before."

Again, I make the point that if we are supporting for 18 months, and 
doing "6-month development cycles", we must, must not release more often 
than every 6 months, or we'll end up in a five-or-more-branch support 
mess. To avoid releasing too close together, it makes sense to set the 
release date of X + 2 only when we've released X, and then work the 
freeze date back from it.

> We have very good faith still that this whole mess was caused 
> because of the huge development window that 2.18 used, and as long as we 
> keep to this schedule from now on, we shouldn't have to do this again.

That's optimistic :-)

> In order to keep everyone focused on the release process, the trunk will 
> not reopen until 2.16.8, 2.18, and 2.19.2 are released.

Good plan.

Gerv


From gerv at mozilla.org  Thu Jan 13 23:25:41 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 13 Jan 2005 23:25:41 +0000
Subject: Documentation for the release
In-Reply-To: <41E6FE51.60301@bugzilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org>
Message-ID: <41E70375.3080307@mozilla.org>

David Miller wrote:
> Quite frankly, that makes me a bit nervous.  I'm still remembering a 
> major docs checkin about a year ago or so that went something along the 
> lines of "hey guys, I just checked in a major revision to the 
> documentation", which none of us knew was coming, and nobody had time to 
> go back and audit.

So would anyone have had time to review it if I'd done it as a patch, 
then? :-)

> At the time I just said "oh, I trust Gerv, we'll 
> just hope it was good" and then over the following months, it turned out 
> important things disappeared, 

I was never made aware of such problems. Would that not have been a 
sensible thing to do? No one gets better if they are unaware of their 
mistakes...

> and all of those changes that were also 
> applicable to 2.16 never got backported to the 2.16 docs.

That's different. I don't think fixing the 2.18 docs obligates one to 
fix all versions of the docs in existence.

> I'd very much prefer patches to each of the docs bugs for the specific 
> things they cover (some of those bugs are for reorganization type 
> changes, if I recall correctly, so some of them are ripe for 
> larger-sized patches).

I assert that if the documentation's in the state you say, without a 
12-hour hackathon style thing, it's not going to be ready.

Having said that, I'm quite happy for there to be more warning, review 
and oversight :-) If I promise to carve out my weekend for this, can 
others promise to read the result and perhaps compare it with the 
previous version to see if I've accidentally nuked important information?

Gerv


From gerv at mozilla.org  Thu Jan 13 23:32:47 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 13 Jan 2005 23:32:47 +0000
Subject: Release timing
In-Reply-To: <41E64A11.9070800@bugzilla.org>
References: <41E5AF88.6030405@mozilla.org> <41E64A11.9070800@bugzilla.org>
Message-ID: <41E7051F.6040302@mozilla.org>

Vlad Dascalu wrote:
> We could modify the plan and say that freezes happen 6 months after the 
> last release is out. So the time distance between releases would be 6 
> months + the time required for stabilization. This would still allow 
> time-based releases, but would prevent situations like this one. Just 
> brainstorming.

I just proposed something like this without crediting Vlad for 
suggesting it first :-) Sorry, Vlad. Good idea :-)

Gerv


From travis at SEDSystems.ca  Thu Jan 13 23:39:34 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Thu, 13 Jan 2005 17:39:34 -0600 (CST)
Subject: Documentation for the release
In-Reply-To: <41E70375.3080307@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca>
 <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org>
 <41E70375.3080307@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca>



On Thu, 13 Jan 2005, Gervase Markham wrote:

> > and all of those changes that were also
> > applicable to 2.16 never got backported to the 2.16 docs.
>
> That's different. I don't think fixing the 2.18 docs obligates one to
> fix all versions of the docs in existence.

I agree that docs for versions we no longer support don't have to be kept
current, but IMHO all documentation for supported versions should be fixed
simultaneously.

The places they should differ are;
- Feature is new to a newer version
- Feature was changed from an older version to a newer version
- Feature was phased out after an older version

Other than that... my feeling is that they should be pretty much identical.
It sure makes patching (and diffs, for those who want to see what has
changed) a whole lot easier.

(Those are just my thoughts; Dave and Jake get the final say.)


> > I'd very much prefer patches to each of the docs bugs for the specific
> > things they cover
>
> I assert that if the documentation's in the state you say, without a
> 12-hour hackathon style thing, it's not going to be ready.

You may be right; in fact, I'll bet your right.

Despite that, my personal preference is that I'd rather not have it done
that way.


> If I promise to carve out my weekend for this, can others promise to read
> the result and perhaps compare it with the previous version to see if I've
> accidentally nuked important information?

So on top of your herculean hackathon, there would need to be a herculean
reviewathon too... which I don't have time for, and which would delay
release even further. I just cannot think of a time when I'll be able to sit
down and r= the whole bugzilla documentation manual at once.

(If you were talking about just checking it all in when you were done, and
having it reviewed in retrospect... then I'm even less copacetic with the
idea. Things benefit from having more than one pair of eyes look at it
before it becomes a fait accompli.)

There's lots of specific patches to attack. As I said, I'm planning to get
to as many as I can in the near future, but I'd welcome some help. All I ask
is that you assign it to yourself if you're going to do it (so that there
isn't a duplication of effort) and don't check anything in until it's been
reviewed... same as anywhere else in Bugzilla.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From justdave at bugzilla.org  Fri Jan 14 06:05:10 2005
From: justdave at bugzilla.org (David Miller)
Date: Fri, 14 Jan 2005 01:05:10 -0500
Subject: Watching Bugzilla heads-up
Message-ID: <41E76116.6070900@bugzilla.org>

If you are among the folks who attempt to watch all Bugzilla bugs by 
watching MattyT's account (since he was the default QA), take note that 
the default QA for all components in the Bugzilla product has now been 
changed to default-qa at bugzilla.bugs.  You'll need to add this to your 
watch list if you were previously watching all Bugzilla bugs and want to 
continue doing so.  Note that I have only changed the default, so 
existing bugs still have Matty listed on them.  At some point in the 
future, we'll probably change all the open ones, but for the time being, 
you'll need to watch both.

Once that transition is complete, the main benefit this gets us is that 
you can watch Bugzilla bugs without getting everything else MattyT is 
involved in (all the Mozilla bugs he's filed, all the other Webtools 
products he QAs for, etc).

I've also created "component-name at bugzilla.bugs" style accounts for 
several of the components which I only owned because there was no one 
else to own them.  These accounts contain the same text for the "real 
name" field that the nobody at bugzilla.org account does ("No one is 
working on this yet, feel free to take it").  The remaining components 
that still list me as the owner are the ones that I have (or should 
have) an active role in maintaining.  I'm thinking it probably wouldn't 
be a bad idea to do this with many of the other components that don't 
have particularly strong ownership also.  Components that should keep 
their owners are ones where a specific person usually has an active role 
in anything that happens in that component, such as Gerv with Reports or 
Erik with Whining.

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

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Fri Jan 14 22:55:27 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 14 Jan 2005 22:55:27 +0000
Subject: Documentation for the release
In-Reply-To: <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org> <41E70375.3080307@mozilla.org> <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca>
Message-ID: <41E84DDF.9020701@mozilla.org>

Shane H. W. Travis wrote:
  >>If I promise to carve out my weekend for this, can others promise to 
read
>>the result and perhaps compare it with the previous version to see if I've
>>accidentally nuked important information?
> 
> So on top of your herculean hackathon, there would need to be a herculean
> reviewathon too... which I don't have time for, and which would delay
> release even further. I just cannot think of a time when I'll be able to sit
> down and r= the whole bugzilla documentation manual at once.

Well, then we are completely doomed :-|

Seriously, you wouldn't have to review it all - people could review 
different bits. We could share it out.

> (If you were talking about just checking it all in when you were done, and
> having it reviewed in retrospect... then I'm even less copacetic with the
> idea. Things benefit from having more than one pair of eyes look at it
> before it becomes a fait accompli.)

It wouldn't be a fait accompli - I'd be happy to change stuff back if 
necessary.

> There's lots of specific patches to attack. 

The problem I find with docs is that if you approach it like code, in a 
"patching", you just work really slowly. The fact that we store the docs 
as XML shouldn't fool us. What other authoring group uses a "patching" 
approach to writing prose? People edit, and re-edit as they pass over 
and re-read the document. That's the only way you get something that's 
coherent, consistent and flowing.

Gerv


From myk at mozilla.org  Sat Jan 15 01:09:15 2005
From: myk at mozilla.org (Myk Melez)
Date: Fri, 14 Jan 2005 17:09:15 -0800
Subject: Watching Bugzilla heads-up
In-Reply-To: <41E76116.6070900@bugzilla.org>
References: <41E76116.6070900@bugzilla.org>
Message-ID: <41E86D3B.5090606@mozilla.org>

David Miller wrote:

> I'm thinking it probably wouldn't be a bad idea to do this with many 
> of the other components that don't have particularly strong ownership 
> also.  Components that should keep their owners are ones where a 
> specific person usually has an active role in anything that happens in 
> that component, such as Gerv with Reports or Erik with Whining.

Right.  You can do this for all my components except UI as well, since I 
haven't been strongly owning the others for a while now.

-myk



From jake at bugzilla.org  Sat Jan 15 09:54:37 2005
From: jake at bugzilla.org (Jake)
Date: Sat, 15 Jan 2005 04:54:37 -0500
Subject: Documentation for the release
In-Reply-To: <41E70375.3080307@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org> <41E70375.3080307@mozilla.org>
Message-ID: <41E8E85D.6020307@bugzilla.org>

Gervase Markham wrote:

> David Miller wrote:
>
>> Quite frankly, that makes me a bit nervous.  I'm still remembering a 
>> major docs checkin about a year ago or so that went something along 
>> the lines of "hey guys, I just checked in a major revision to the 
>> documentation", which none of us knew was coming, and nobody had time 
>> to go back and audit.
>
>
> So would anyone have had time to review it if I'd done it as a patch, 
> then? :-)

If it were a patch per issue, it should be possible for people to find 
time to review it. Unfortunately, I'm in a huge period of flux right now 
so the chances of me doing many reviews are quite low. I know it can be 
a bit of a pain, but it really is easier to review the charting portion 
of the docs separate from, say, random changes in the FAQ.

>> At the time I just said "oh, I trust Gerv, we'll just hope it was 
>> good" and then over the following months, it turned out important 
>> things disappeared, 
>
>
> I was never made aware of such problems. Would that not have been a 
> sensible thing to do? No one gets better if they are unaware of their 
> mistakes...

A good place to look would be documentation changes that were made since 
your massive checkin. A couple in particular that had to be undone was 
the massive gutting of the Credits section and the removal of the 
security section (which should have been, and now is, a chapter).

>> and all of those changes that were also applicable to 2.16 never got 
>> backported to the 2.16 docs.
>
>
> That's different. I don't think fixing the 2.18 docs obligates one to 
> fix all versions of the docs in existence.
>
In existence? No, not once has anybody asked you to update 2.14, which 
does technically still exist. However, all supported version should be 
updated where appropriate. Obviously the new whining system doesn't have 
to be documented in the 2.18 or 2.16 versions of the guide, but docs on, 
say, the flag system certainly should be.

>> I'd very much prefer patches to each of the docs bugs for the 
>> specific things they cover (some of those bugs are for reorganization 
>> type changes, if I recall correctly, so some of them are ripe for 
>> larger-sized patches).
>
>
> I assert that if the documentation's in the state you say, without a 
> 12-hour hackathon style thing, it's not going to be ready.

If documentation were a one person effort, I may agree. However, there 
are many people who do (at least some) work on the docs. As such, one 
should keep their work focused as much as possible and attempt to let 
others know what they are working on. The best and easiest way to do 
this is to simply use the tool for which the documentation is being 
written: Bugzilla. When you have a bug ASSIGNED to you, it lets others 
know that you are working on it. It also allows the others to ascertain, 
to some extent, what parts of the guide you're likely to change.

> Having said that, I'm quite happy for there to be more warning, review 
> and oversight :-) If I promise to carve out my weekend for this, can 
> others promise to read the result and perhaps compare it with the 
> previous version to see if I've accidentally nuked important information?

As I mentioned above, I personally, can make no such promise. I wish I 
could, but to be honest, I'm not even sure that weekends still exist. 
Another advantage of the multiple small(er) patch approach is that one 
person doesn't have to carve enough time to review everything. Many 
people can review much smaller portions.

I know this can be more of a pain for the person writing the patches as 
instead of simply doing one huge update in place, you now have to juggle 
a bunch of patch files, but I think we've certainly learned in the 
codebase that one huge patch that fixes everything ends up being a waste 
of time because nobody has the chance to review it.


From jake at bugzilla.org  Sat Jan 15 10:09:18 2005
From: jake at bugzilla.org (Jake)
Date: Sat, 15 Jan 2005 05:09:18 -0500
Subject: Documentation for the release
In-Reply-To: <41E84DDF.9020701@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org> <41E70375.3080307@mozilla.org> <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca> <41E84DDF.9020701@mozilla.org>
Message-ID: <41E8EBCE.4070505@bugzilla.org>

Gervase Markham wrote:

> Well, then we are completely doomed :-|

This is a bit dramatic, don't you think?

> Seriously, you wouldn't have to review it all - people could review 
> different bits. We could share it out.

An act which is made much easier by submitting small and more focused 
patches. This is especially true where new features are concerned as you 
can ask not only a docs reviewer to look at it, but also somebody who's 
familiar with how the feature works.

> The problem I find with docs is that if you approach it like code, in 
> a "patching", you just work really slowly. The fact that we store the 
> docs as XML shouldn't fool us. What other authoring group uses a 
> "patching" approach to writing prose? People edit, and re-edit as they 
> pass over and re-read the document. That's the only way you get 
> something that's coherent, consistent and flowing.
>
Yes, we are writing something kind of like prose, but at the same time 
we're not writing a novel, we're we're writing a technical manual. But 
even in the novel example, if you find an error in chapter 13, you don't 
have to rewrite chapter 27 nor does the editor have to reread (review) 
chapter 27. True, one there's a final version (rc), the book should be 
read in its entirety to make sure that it makes sense. But truthfully, 
we're a long way away from a final version of the Bugzilla Guide. At 
this point I'm much more concerned with technical accuracy followed by 
spelling and basic grammar. Things like smooth flow throughout the 
entire manual and overall first/third person agreement may be nice, but 
they are a much lower priority.

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




From gerv at mozilla.org  Sat Jan 15 11:29:23 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 15 Jan 2005 11:29:23 +0000
Subject: Documentation for the release
In-Reply-To: <41E8EBCE.4070505@bugzilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca> <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org> <41E70375.3080307@mozilla.org> <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca> <41E84DDF.9020701@mozilla.org> <41E8EBCE.4070505@bugzilla.org>
Message-ID: <41E8FE93.8080407@mozilla.org>

Jake wrote:
> An act which is made much easier by submitting small and more focused 
> patches. 

IMO, the reason documentation falls behind code is the requirement to 
submit small and focussed patches for every change. It's much more 
effort this way, and people just don't bother.

Docs aren't like code - you can't "break" them, thereby making the whole 
document useless. (Yes, I know about SGML well-formedness. That's not 
what I meant.) Problems are localised to a particular mistake, and there 
are no weird side-effects. This means you can take a much more free 
attitude to changing them than you can to code.

If you take the patch approach to docs, the document slowly but surely 
becomes incoherent and inconsistent, because no-one takes an overall 
view and edits the entire manuscript to bring it back to a good and 
consistent state. I suggest that if you want good docs, this process, 
which is only really feasible in a "do it and then review it all" way, 
needs to happen at least once before every release.

Granted, it should probably happen a bit earlier in the process than now :-)

>> The problem I find with docs is that if you approach it like code, in 
>> a "patching", you just work really slowly. The fact that we store the 
>> docs as XML shouldn't fool us. What other authoring group uses a 
>> "patching" approach to writing prose? People edit, and re-edit as they 
>> pass over and re-read the document. That's the only way you get 
>> something that's coherent, consistent and flowing.
>>
> Yes, we are writing something kind of like prose, but at the same time 
> we're not writing a novel, we're we're writing a technical manual. But 
> even in the novel example, if you find an error in chapter 13, you don't 
> have to rewrite chapter 27 nor does the editor have to reread (review) 
> chapter 27. 

Unless the bit you change in chapter 13 actually is supposed to go in 
chapter 27. This doesn't happen in a novel, but it does happen in 
technical documentation. I agree, technical docs are not like a novel - 
they undergo a vastly greater degree of change and rearrangement during 
editing.

> True, one there's a final version (rc), the book should be 
> read in its entirety to make sure that it makes sense. But truthfully, 
> we're a long way away from a final version of the Bugzilla Guide. 

Well, Dave's in the middle of releasing 2.18, so it seems a bit late now :-(

> At 
> this point I'm much more concerned with technical accuracy followed by 
> spelling and basic grammar. Things like smooth flow throughout the 
> entire manual and overall first/third person agreement may be nice, but 
> they are a much lower priority.

When I talk about a massive hackathon, that's not the stuff I mean. I 
mean (hypothetically) reorganising all the installation instructions, 
adding three new administration sections, trimming the FAQ drastically 
and moving half the content to various places within the manual, 
re-editing to incorporate that text in a nice way... Major changes, in 
other words, in line with the assertion (made earlier) that "the docs 
aren't even close to where we want them to be" (or whatever he said).

The last time I did this, I must have made ten or twenty editing passes 
over the document, changing unrelated things each time as I massaged it 
into shape. If every pass had to be at least one and possibly more 
reviewed patches, it would have taken three months rather than a weekend.

Gerv


From gerv at mozilla.org  Sat Jan 15 13:00:00 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 15 Jan 2005 13:00:00 +0000
Subject: 2.18 release
Message-ID: <41E913D0.6010809@mozilla.org>

The IRC topic currently says:

"releases tagged and tarballed, announcements will go out in the morning".

Topic for #mozwebtools was set by justdave!justdave at bugzilla.org on 
15/01/05 08:48:49 (presumably GMT, as it's from my IRC client).

Gerv


From travis at SEDSystems.ca  Sat Jan 15 18:07:50 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Sat, 15 Jan 2005 12:07:50 -0600 (CST)
Subject: Documentation for the release
In-Reply-To: <41E8FE93.8080407@mozilla.org>
References: <41E6EAAF.9070201@mozilla.org> <Pine.GHP.4.58.0501131535460.15073@milhouse.SEDSystems.ca>
 <41E6F63A.7010405@mozilla.org> <41E6FE51.60301@bugzilla.org>
 <41E70375.3080307@mozilla.org> <Pine.GHP.4.58.0501131715090.15073@milhouse.SEDSystems.ca>
 <41E84DDF.9020701@mozilla.org> <41E8EBCE.4070505@bugzilla.org>
 <41E8FE93.8080407@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501151112030.20349@milhouse.SEDSystems.ca>


On Sat, 15 Jan 2005, Gervase Markham wrote:

> Jake wrote:
> > Gerv wrote:
> > > Seriously, you wouldn't have to review it all - people could review
> > > different bits. We could share it out.
> >
> > An act which is made much easier by submitting small and more focused
> > patches.

Agreed.


> IMO, the reason documentation falls behind code is the requirement to
> submit small and focussed patches for every change. It's much more
> effort this way, and people just don't bother.

It's just as much bother for code too... yet somehow code still keeps
getting written. Why?
- writing new features is *way* more fun than writing new documentation
- people are much more confident in their ability to write good code than
	they are in their ability to write a good sentence

This is a generalization, of course, but I think it's a pretty fair
generalization. Even for myself -- and, from discussion with him, even for
Jake -- we both like doing new features and stuff as much as (if not more
than) doing docs... but we do it because we're capable of it, and it needs
doing.

One other reason that (IMHO) documentation lags is SGML formatting. Sure,
it's not difficult, but it's one more hurdle for the person who doesn't do
it often. What I'd like to see is a new procedure change, that when one
writes a Bugzilla enhancement, it will not be checked into the trunk until
there also exists a .txt file that explains how the enhancement works, what
it affects, and what it does. This would NOT have to be in polished prose or
proper SGML... but it would have to exist. That way the documentation team
at least has a starting point when they go to write up the docs.


> Docs aren't like code - you can't "break" them... This means you can take
> a much more free attitude to changing them than you can to code.

You are, of course, entitled to your opinion. Dave, myself, and now Jake
have all indicated that we disagree/are not comfortable with the 'do it all
at once in a paroxysm of verbiage' approach.


> If you take the patch approach to docs, the document slowly but surely
> becomes incoherent and inconsistent, because no-one takes an overall
> view and edits the entire manuscript to bring it back to a good and
> consistent state.

I would agree with you... if the only thing that was ever being done was
patches to add specific bits of information, or fix specific issues and
mistakes. Fortunately, that's not how it has been working in my (admittedly
short) experience.

Not all patches are of the same magnitude. Some are small ('link is
incorrect'), some are moderate ('need some more examples of how groups
permissions work'), and some are large ('Need docs on flags', 'windows docs
needs to be brought up-to-date'). Some of them are meta-issues ('FAQ
Overhaul', 'Integrate hacking FAQs and Developers Guides') that deal with
the documentation as a whole, rather than specific bits of information
contained therein.


> When I talk about a massive hackathon, ... I
> mean (hypothetically) reorganising all the installation instructions,
> adding three new administration sections, trimming the FAQ drastically
> and moving half the content to various places within the manual,
> re-editing to incorporate that text in a nice way... Major changes, in
> other words...

There is no overwhelming reason that any of these items you mention *must*
be done as part of an all-or-nothing approach; they're all perfectly suited
to being done as individual tasks. I would welcome bugs being opened on any
or all of these things. (I would welcome it even more if, after opening the
bugs, you took on the task of getting them done... :)

On a more general topic, I've been trying to get people to open more docs
bugs if they see something that's wrong, or can't find some information that
they're looking for, or find it in five different places and think it should
be amalgamated into one. I'd love it if people could get into the habit of
doing this, in the same way that they open bugs against Bugzilla if they see
something that doesn't work there. If information is missing from the docs,
don't assume that the doc-writers know about it.


> The last time I did this, I must have made ten or twenty editing passes
> over the document, changing unrelated things each time as I massaged it
> into shape. If every pass had to be at least one and possibly more
> reviewed patches, it would have taken three months rather than a weekend.

Then I assert that the time to ask the question about what shape the docs
are in would have been three months ago... not 48 hours before a planned
release, stating that "we are completely doomed" unless we let you do it
your way.


Fortunately, one way in which 'docs are not like code' (at least so far as
Bugzilla itself is concerned) is that code is only released at specific,
discrete intervals. The Bugzilla docs are updated www.bugzilla.org (which is
where I'd bet that >95% of English-speaking people come looking for
documentation) happen every fifteen minutes. When something gets checked in
to the docs, it is almost instantaneously available to the public at large.
This means that we do not have to make it through a specific window before
it closes on us.


Just for the record... I'm not *opposed* to the idea of large-scale
rewrites; I've already done one or two myself. I do think that trying to
do the whole docs at once when there are already >70 documentation issues
outstanding is not reasonable, however. Once things are caught up and the
bugs that we KNOW to exist have been addressed, I would be much more
receptive to the idea.

In the mean time, please post bugs on the issues you raise above, and feel
free to help reduce the time until that date by attacking the existing
documentation bugs.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From bugzilla at glob.com.au  Sun Jan 16 13:56:30 2005
From: bugzilla at glob.com.au (byron)
Date: Sun, 16 Jan 2005 21:56:30 +0800 (WST)
Subject: Documentation for the release
Message-ID: <20050116135630.D5E764BC23C@stutter.bur.st>

> One other reason that (IMHO) documentation lags is SGML formatting. Sure,
> it's not difficult, but it's one more hurdle for the person who doesn't do
> it often. 

i second that.  setting up the docs build envrionment is a pain (impossible on
windows).  while i have landfill access, it's pretty slow at times.

> Fortunately, one way in which 'docs are not like code' (at least so far as
> Bugzilla itself is concerned) is that code is only released at specific,
> discrete intervals. The Bugzilla docs are updated www.bugzilla.org (which is
> where I'd bet that >95% of English-speaking people come looking for
> documentation) happen every fifteen minutes. When something gets checked in
> to the docs, it is almost instantaneously available to the public at large.
> This means that we do not have to make it through a specific window before
> it closes on us.

i'd agree with that if the docs weren't bundled with the product.  if i
download a tarball that includes a manual, i'd expect it to be up to date,
with updates only occuring with a new versioned release of the product.  i
also don't think it's unreasonable to expect that the online docs for 2.18.0
always match the docs in the 2.18.0 tarball.


the other option is to only include the quickstart in the tarball, with a
reference to the bugzilla website.  then any documentation updates *will* be
instantaneously available to the public.


throwing ideas "into the wind" (with very little forethought) would it be a
good idea to use html as the base document format, and generate text and pdf
from the html?


begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From gerv at mozilla.org  Sun Jan 16 14:42:54 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 16 Jan 2005 14:42:54 +0000
Subject: Documentation for the release
In-Reply-To: <20050116135630.D5E764BC23C@stutter.bur.st>
References: <20050116135630.D5E764BC23C@stutter.bur.st>
Message-ID: <41EA7D6E.8010508@mozilla.org>

byron wrote:
> i'd agree with that if the docs weren't bundled with the product.  if i
> download a tarball that includes a manual, i'd expect it to be up to date,
> with updates only occuring with a new versioned release of the product.  i
> also don't think it's unreasonable to expect that the online docs for 2.18.0
> always match the docs in the 2.18.0 tarball.

Well, the online docs for 2.18 should match the latest release of 2.18 - 
we don't do online docs by point release, only by major release. But, as 
we will only be updating it with security fixes, the content shouldn't 
change much.

I certainly agree that the docs should not undergo major reorganisation 
post-release, for the reason you gave. The 2.18.7 docs should be 
substantially similar to the 2.18.0 docs, such that anyone familiar with 
the latter can easily find what they want in the former.

> the other option is to only include the quickstart in the tarball, with a
> reference to the bugzilla website.  then any documentation updates *will* be
> instantaneously available to the public.

I still think shipping docs is a good idea - some admins may want the 
machine disconnected from the network during the install (and, in fact, 
the Guide recommends this).

> throwing ideas "into the wind" (with very little forethought) would it be a
> good idea to use html as the base document format, and generate text and pdf
> from the html?

HTML doesn't really have the semantic range we need, IMO.

My copy of Mandrake had all the necessary packages installed; I just had 
to set up a few environment variables as it says in README.docs. Other 
distros may not be so lucky; but perhaps we should investigate why it's 
so hard on Windows, and try and provide documentation to make it easier?

Gerv




From jake at bugzilla.org  Sun Jan 16 14:59:20 2005
From: jake at bugzilla.org (Jake)
Date: Sun, 16 Jan 2005 09:59:20 -0500
Subject: Documentation for the release
In-Reply-To: <41EA7D6E.8010508@mozilla.org>
References: <20050116135630.D5E764BC23C@stutter.bur.st> <41EA7D6E.8010508@mozilla.org>
Message-ID: <41EA8148.2020408@bugzilla.org>

Gervase Markham wrote:

>> throwing ideas "into the wind" (with very little forethought) would 
>> it be a  good idea to use html as the base document format, and 
>> generate text and pdf
>> from the html?
>
> HTML doesn't really have the semantic range we need, IMO.
>
> My copy of Mandrake had all the necessary packages installed; I just 
> had to set up a few environment variables as it says in README.docs. 
> Other distros may not be so lucky; but perhaps we should investigate 
> why it's so hard on Windows, and try and provide documentation to make 
> it easier?
>
Redhat, IIRC, is much the same way. I may have had to get the stylesheet 
for tldp.org, I really don't remember, but Jade and friends were already 
installed. The docs (2.18 final and 2.19.2) are also compatible with 
xmlto. I don't know how well, or even if at all, this installs on 
Windows, but if it does, that could be an alternative. For the time 
being, the "official" docs will continue to be built by jade, but that 
may (or may not) change in the future.



From justdave at bugzilla.org  Sun Jan 16 23:33:24 2005
From: justdave at bugzilla.org (David Miller)
Date: Sun, 16 Jan 2005 18:33:24 -0500
Subject: Documentation for the release
In-Reply-To: <41EA7D6E.8010508@mozilla.org>
References: <20050116135630.D5E764BC23C@stutter.bur.st> <41EA7D6E.8010508@mozilla.org>
Message-ID: <41EAF9C4.40703@bugzilla.org>

Gervase Markham wrote:
> byron wrote:
> 
>> i'd agree with that if the docs weren't bundled with the product.  if i
>> download a tarball that includes a manual, i'd expect it to be up to 
>> date, with updates only occuring with a new versioned release of the 
>> product.  i
>> also don't think it's unreasonable to expect that the online docs for 
>> 2.18.0
>> always match the docs in the 2.18.0 tarball.
> 
> I certainly agree that the docs should not undergo major reorganisation 
> post-release, for the reason you gave. The 2.18.7 docs should be 
> substantially similar to the 2.18.0 docs, such that anyone familiar with 
> the latter can easily find what they want in the former.

If the docs were actually complete when we shipped, I would tend to 
agree.  But since they aren't, we continue to improve them until they 
are, or the branch gets EOLed, whichever happens first.  At the rate 
we're going, I suspect 2.20 will probably ship with reasonably complete 
documentation.  Neither 2.16 nor 2.18 did (although 2.18's is certainly 
more complete than the original docs that shipped with 2.16).

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From Tomas.Kopal at altap.cz  Mon Jan 17 10:45:12 2005
From: Tomas.Kopal at altap.cz (Tomas Kopal)
Date: Mon, 17 Jan 2005 21:15:12 +1030
Subject: Slashdot
Message-ID: <41EB9738.3000000@altap.cz>

Hi,
We are being slashdoted :-).

http://it.slashdot.org/article.pl?sid=05/01/16/2045245&tid=128

Note that qite a few people are requesting Postgres support :-).

Tomas


From mkanat at kerio.com  Tue Jan 18 00:05:35 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Mon, 17 Jan 2005 16:05:35 -0800
Subject: Slashdot
In-Reply-To: <41EB9738.3000000@altap.cz>
Message-ID: <20050117160535.a446d348@mail.kerio.com>

> We are being slashdoted :-).
> 
> http://it.slashdot.org/article.pl?sid=05/01/16/2045245&tid=128

  /me is psychic. :-)

> Note that qite a few people are requesting Postgres support :-).

  Hrm... have you got that new patch for me, yet? :-) Maybe we'll get it into 2.20, if we're quick.

  -Max




From justdave at bugzilla.org  Tue Jan 18 08:24:59 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 18 Jan 2005 03:24:59 -0500
Subject: Release timing
In-Reply-To: <79808.1105621455@thrush.ravenbrook.com>
References: <79808.1105621455@thrush.ravenbrook.com>
Message-ID: <41ECC7DB.4060307@bugzilla.org>

Nick Barnes wrote:

> I thought we *did* say that releases should be 6 months apart.
> Archives, anyone?

I'm quite sure we only said that the freezes would be.


I read through this whole message and got the idea that you were 
advocating a set release date, and was fairly skeptical because I know 
from past experience that there's no way we can hold to it.  Then I read 
your last paragraph here...

>  And if you get a short freeze (i.e. if .0 is ready
> *before* the planned release date) then bring the release forward and
> you get bonus thaw time.

..and the light is starting to dawn.  I think at this point that it's 
more than reasonable to expect a freeze time of a month or less for 
2.20.  But we can just put "2.20 release on or before May 15th" on the 
roadmap...  gives us 2 months, gives people a date to look for, and 
hopefully we can deliver early. :)  Sounds like a plan to me.

Of note is that the freeze tends to happen before rc1 unless the trunk 
it particularly stable.  We freeze the trunk on March 15th, and then 
release rc1 and branch once we feel it's ready (at which time the trunk 
thaws, but the release isn't out until the showstopper bugs reported 
against rc1 are fixed).

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From Tomas.Kopal at altap.cz  Tue Jan 18 08:42:03 2005
From: Tomas.Kopal at altap.cz (Tomas Kopal)
Date: Tue, 18 Jan 2005 19:12:03 +1030
Subject: Slashdot
In-Reply-To: <20050117160535.a446d348@mail.kerio.com>
References: <20050117160535.a446d348@mail.kerio.com>
Message-ID: <41ECCBDB.8090207@altap.cz>

On 01/18/05 10:35, Maxwell Kanat-Alexander wrote:
> 
>   Hrm... have you got that new patch for me, yet? :-) Maybe we'll get it into 2.20, if we're quick.
> 
>   -Max
> 

Not yet, sorry. Just polishing patch for bug #257315. DBcompat is next 
in line :-). Men, how I would like it to get in for 2.20, you have no 
idea ;-).

Tomas


From Nick.Barnes at pobox.com  Tue Jan 18 10:39:38 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Tue, 18 Jan 2005 10:39:38 +0000
Subject: Release timing
In-Reply-To: <41ECC7DB.4060307@bugzilla.org> 
   from David Miller <justdave@bugzilla.org> 
   of "Tue, 18 Jan 2005 03:24:59 -0500"
Message-ID: <449.1106044778@thrush.ravenbrook.com>

At 2005-01-18 08:24:59+0000, David Miller writes:
> Nick Barnes wrote:
> 
> > I thought we *did* say that releases should be 6 months apart.
> > Archives, anyone?
> 
> I'm quite sure we only said that the freezes would be.

OK.  As long as we're saying "the freeze for Y will start six months
after the freeze for X starts", and not "... X ends".  i.e. (freeze +
thaw) = six months, not thaw = six months.

Nick B


From sukria at sukria.net  Tue Jan 18 11:05:34 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Tue, 18 Jan 2005 12:05:34 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
Message-ID: <20050118110532.GA10952@sukria.net>

Hello there, 

There is a request for packaging Bugzilla 2.18 in order to let it enter 
Sarge[1].

I think that this is the time for cleaning up the Debian package and
that's why I started to package it from scratch.

Looking deeper in checksetup.pl, I've found that this script can create
the first Bugzilla's administrator, even in a non-interactive mode.

That's exactly what I need for the configuration phase of the package
and it seams to work the very first time.

The problem is that I cannot find if there is a way to tell
checksetup.pl to _update_ the administrator account.

For instance, if the user installed fist the package and then
re-install it with changing the admin email...

checksetup.pl will then create a second administrator, won't it?

Could you give me details on how to use this script the better way?

I attach here the "answer file" I use, could you tell me if it's right?

Second, to respect the Debian policy, I have to put *.cgi in
/usr/lib/cgi-bin/bugzilla/ and all the other files in
/usr/share/bugzilla, all the HTML outputs refers to local directories
(css/, js/, ...) what is the best way to update them in order to change
that locations to something like /bugzilla/css/, /bugzilla/js/, etc...?

Thanks a lot.

[1] : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290775

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: checksetup-answer.pl
Type: text/x-perl
Size: 334 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050118/48e32531/attachment.bin>

From gerv at mozilla.org  Tue Jan 18 11:37:42 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 18 Jan 2005 11:37:42 +0000
Subject: Release timing
In-Reply-To: <41ECC7DB.4060307@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
Message-ID: <41ECF506.7030505@mozilla.org>

David Miller wrote:
> ..and the light is starting to dawn.  I think at this point that it's 
> more than reasonable to expect a freeze time of a month or less for 
> 2.20.  But we can just put "2.20 release on or before May 15th" on the 
> roadmap...  gives us 2 months, gives people a date to look for, and 
> hopefully we can deliver early. :)  Sounds like a plan to me.

Remind me why delivering early is a good thing?

If we expect a freeze time of 1 month for 2.20, we should set the freeze 
date to be five months from last Sunday - i.e. June 16th, for release in 
mid-July. Then, we will be making releases approximately six months apart.

Aiming for six months apart and hitting seven months is no big deal. 
Aiming for and hitting five months apart is a big deal; with 18-month 
support cycles (are we still planning to do those?) we would have five 
branches on the go at once :-(

Gerv


From bugreport at peshkin.net  Tue Jan 18 11:42:06 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 18 Jan 2005 03:42:06 -0800
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050118110532.GA10952@sukria.net>
References: <20050118110532.GA10952@sukria.net>
Message-ID: <41ECF60E.3070807@peshkin.net>


Actually, what we need to do is to kill 2 birds with one stone.  It is 
useful to have a way to create an administrator from checksetup without 
requiring database hacking.  If we do that, the update portion should be 
a no-brainer.




From Nick.Barnes at pobox.com  Tue Jan 18 13:19:23 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Tue, 18 Jan 2005 13:19:23 +0000
Subject: schema doc update
Message-ID: <1545.1106054363@thrush.ravenbrook.com>

[also sent to webtools]

I have updated my online Bugzilla schema documentation to reflect the
recent releases.  The only schema changes are the additions of
flagtypes.grant_group_id and flagtypes.request_group_id in 2.19.2.
The 2.18 schema is the same as 2.18rc3; the 2.16.8 schema is the same
as 2.16.7.

<http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/>

Nick Barnes
P4DTI Project
Ravenbrook Limited



From bugzilla at glob.com.au  Tue Jan 18 14:40:07 2005
From: bugzilla at glob.com.au (byron)
Date: Tue, 18 Jan 2005 22:40:07 +0800 (WST)
Subject: Packaging of Bugzilla 2.18 in Debian
Message-ID: <20050118144007.56AD84BC13B@stutter.bur.st>

> Actually, what we need to do is to kill 2 birds with one stone.  It is 
> useful to have a way to create an administrator from checksetup without 
> requiring database hacking.  If we do that, the update portion should be 
> a no-brainer.

sounds like Bug 275477



begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From gerv at mozilla.org  Tue Jan 18 18:08:45 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 18 Jan 2005 18:08:45 +0000
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050118110532.GA10952@sukria.net>
References: <20050118110532.GA10952@sukria.net>
Message-ID: <41ED50AD.80106@mozilla.org>

Alexis Sukrieh wrote:
> Second, to respect the Debian policy, I have to put *.cgi in
> /usr/lib/cgi-bin/bugzilla/ and all the other files in
> /usr/share/bugzilla, all the HTML outputs refers to local directories
> (css/, js/, ...) what is the best way to update them in order to change
> that locations to something like /bugzilla/css/, /bugzilla/js/, etc...?

This was the thing that (may have) caused the problems with the older 
package. Probably the best thing for you to do is to get Bugzilla 
working with the new layout, and then make a list of what you had to 
change. We can then see if it's possible to parameterise those things in 
some way.

Gerv


From sukria at sukria.net  Tue Jan 18 18:43:48 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Tue, 18 Jan 2005 19:43:48 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED50AD.80106@mozilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org>
Message-ID: <20050118184347.GB15648@sukria.net>

* Gervase Markham (gerv at mozilla.org) disait :
> This was the thing that (may have) caused the problems with the older 
> package. Probably the best thing for you to do is to get Bugzilla 
> working with the new layout, and then make a list of what you had to 
> change. We can then see if it's possible to parameterise those things in 
> some way.

Well, the very first thing I need to do (and I have no choice here, else
the package would not be Policy compliant), is to split CGIs from other
scripts:

    - quite everything go in /usr/share/bugzilla (less confusing than
      the old package I think).
    - *.cgi in /usr/lib/cgi-bin/bugzilla
    - and the Bugzilla/ dir in /usr/share/perl5/Bugzilla

If this is an effort for you to change the way tempaltes work,
nevermind, I can make a patch and keep it as a patch file. When building
the package, the build process will then first apply the patch.

That would allow us to keep the same source tree.

The only thing I need to know is if this is possible only by patching
the template files?

Moreover, I noticed that the CVS dirs and files are provided by the
official 2.18 tarball. For the debian package to be lintian valid, CVS
files must be removed. Is it necessary to keep them in the tarball?

Using a cvs export can provide a nice tarball without the CVS stuff
inside ;)

Regards,

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From daa at rm.incc.net  Tue Jan 18 19:08:06 2005
From: daa at rm.incc.net (David Avery)
Date: Tue, 18 Jan 2005 12:08:06 -0700
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050118184347.GB15648@sukria.net>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net>
Message-ID: <41ED5E96.7040105@rm.incc.net>

Alexis Sukrieh wrote:
> 
> Moreover, I noticed that the CVS dirs and files are provided by the
> official 2.18 tarball. For the debian package to be lintian valid, CVS
> files must be removed. Is it necessary to keep them in the tarball?
> 
> Using a cvs export can provide a nice tarball without the CVS stuff
> inside ;)
> 
>

this is the default for all mozill.org tarballs , to allow people to 
grab a tarball and then upgrade the install to CVS HEAD

dave



From justdave at bugzilla.org  Tue Jan 18 19:43:45 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 18 Jan 2005 14:43:45 -0500
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050118184347.GB15648@sukria.net>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net>
Message-ID: <41ED66F1.1080902@bugzilla.org>

Alexis Sukrieh wrote:

> Well, the very first thing I need to do (and I have no choice here, else
> the package would not be Policy compliant), is to split CGIs from other
> scripts:
> 
>     - quite everything go in /usr/share/bugzilla (less confusing than
>       the old package I think).
>     - *.cgi in /usr/lib/cgi-bin/bugzilla
>     - and the Bugzilla/ dir in /usr/share/perl5/Bugzilla

Not sure if this is a good place for the Bugzilla modules, since they're 
not official CPAN modules and are only used in Bugzilla. 
/usr/lib/bugzilla might be a better place for them.  On the other hand, 
putting them into the official Perl path means you don't have to fiddle 
with the "use lib" line in every file to get it to find them, so the 
patch is smaller. :)

> If this is an effort for you to change the way tempaltes work,
> nevermind, I can make a patch and keep it as a patch file. When building
> the package, the build process will then first apply the patch.
> 
> That would allow us to keep the same source tree.
> 
> The only thing I need to know is if this is possible only by patching
> the template files?

It should be possible to do something like [% webpath %] in front of the 
pathname to all of the images, js, css, etc files.  We can and should do 
this upstream, but I'd be happy to take that if you did it, since you're 
in the best position to test it.  The global template variable 
declarations in Bugzilla/Template.pm could get webpath added to it, and 
as distributed upstream, could just contain an empty string.  In the 
Debian distribution, webpath could changed with a one-line patch to be 
"../../bugzilla/".  This would let you set urlbase to 
"http://machinname/cgi-bin/bugzilla/" and everything would work.

> Moreover, I noticed that the CVS dirs and files are provided by the
> official 2.18 tarball. For the debian package to be lintian valid, CVS
> files must be removed. Is it necessary to keep them in the tarball?
> 
> Using a cvs export can provide a nice tarball without the CVS stuff
> inside ;)

Yes, but it's very convenient to have those there as anyone downloading 
a tarball can then "cvs login" and "cvs update" to grab future updates 
if they have cvs available.  For people who customize their Bugzilla, 
this is a very attractive update option as it'll do some limited merging 
for you.

find $buildroot -name CVS -exec rm -rf {} \;

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From chicks at chicks.net  Tue Jan 18 20:11:28 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Tue, 18 Jan 2005 15:11:28 -0500 (EST)
Subject: Release timing
In-Reply-To: <41ECF506.7030505@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>

On Tue, 18 Jan 2005, Gervase Markham wrote:
> Remind me why delivering early is a good thing?

Because delivering late annoys people.

> If we expect a freeze time of 1 month for 2.20, we should set the freeze 
> date to be five months from last Sunday - i.e. June 16th, for release in 
> mid-July. Then, we will be making releases approximately six months 
> apart.

Dave has indicated that the freezes will be timed, not the releases so 
basing dates off of the release date does not fit with the logic that Dave 
feels was agreed upon.

> Aiming for six months apart and hitting seven months is no big deal.

For an open source project maybe.

> Aiming for and hitting five months apart is a big deal; with 18-month 
> support cycles (are we still planning to do those?) we would have five 
> branches on the go at once :-(

I've proposed a solution to this - have some releases be supported longer 
than others.  Some people need long-term stability (ala RHES).  Have other 
releases be supported until two releases have been made.  So if 2.20 
became a "long-term support" release, it would continue to be supported 
for three years.  During that time, six releases would come out (two per 
year).  So at any one time two "short term" releases would be in support 
and one or two "long term" releases.  This way there would never be five 
branches being supported at once and usually there would only be three - 
the long term one and two short term ones.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From chicks at chicks.net  Tue Jan 18 20:13:32 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Tue, 18 Jan 2005 15:13:32 -0500 (EST)
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED5E96.7040105@rm.incc.net>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org>
 <20050118184347.GB15648@sukria.net> <41ED5E96.7040105@rm.incc.net>
Message-ID: <Pine.LNX.4.61.0501181512590.27237@skippy.fini.net>

On Tue, 18 Jan 2005, David Avery wrote:
> this is the default for all mozill.org tarballs , to allow people to grab a 
> tarball and then upgrade the install to CVS HEAD

So one would assume that debian's mozilla, firefox, and thunderbird 
packages have to deal with the same problem.  How do they do it?

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From sukria at sukria.net  Tue Jan 18 21:12:23 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Tue, 18 Jan 2005 22:12:23 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ECF60E.3070807@peshkin.net>
References: <20050118110532.GA10952@sukria.net> <41ECF60E.3070807@peshkin.net>
Message-ID: <20050118211222.GA16208@sukria.net>

* Joel Peshkin (bugreport at peshkin.net) disait :
> 
> Actually, what we need to do is to kill 2 birds with one stone.  It is 
> useful to have a way to create an administrator from checksetup without 
> requiring database hacking.  If we do that, the update portion should be 
> a no-brainer.

Well, don't know if you guys will find this patch ok, but anyway, it
works ;)

If that patched checksetup.pl run with an answer file, it can update an existing account.

I plan to use this patch in the Debian package, that will be great for
the postinst phase : allways using checksetup.pl for updating the
Bugzilla's administrator.

Regards,

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.
-------------- next part --------------
--- checksetup.pl	2005-01-14 10:51:36.000000000 +0100
+++ checksetup.pl	2005-01-18 22:03:49.000000000 +0100
@@ -1,4 +1,5 @@
 #!/usr/bin/perl -w
+$|=1;
 # -*- Mode: perl; indent-tabs-mode: nil -*-
 #
 # The contents of this file are subject to the Mozilla Public
@@ -114,10 +115,11 @@
 #
 
 use strict;
-use lib ".";
+use lib "/usr/share/bugzilla";
 
 use vars qw( $db_name %answer );
 use Bugzilla::Constants;
+use constant MAX_PROMPT_CYCLE => 10;
 
 my $silent;
 
@@ -4195,7 +4197,9 @@
                     " WHERE name = 'admin' AND id = group_id");
 $sth->execute;
 # when we have no admin users, prompt for admin email address and password ...
-if ($sth->rows == 0) {
+# if we are in non-interactive mode, process anyway.
+if ($sth->rows == 0 or defined $answer{'ADMIN_EMAIL'}) {
+  my $update_only = 1 if $sth->rows > 0;
   my $login = "";
   my $realname = "";
   my $pass1 = "";
@@ -4220,12 +4224,19 @@
       and at least one \'.\' after the @.';
   }
 
+  unless ($update_only) {
   print "\nLooks like we don't have an administrator set up yet.  Either this is your\n";
   print "first time using Bugzilla, or your administrator's privileges might have accidently\n";
   print "been deleted.\n";
+  }
+
+  #this is useful when using this script in non-interactive mode.
+  my $cycle_count = 0;
+  
   while(! $admin_ok ) {
-    while( $login eq "" ) {
-      print "Enter the e-mail address of the administrator: ";
+    while( $login eq "") {
+      print "Enter the e-mail address of the administrator: " 
+      	unless defined $answer{'ADMIN_EMAIL'};
       $login = $answer{'ADMIN_EMAIL'} 
           || ($silent && die("cant preload ADMIN_EMAIL")) 
           || <STDIN>;
@@ -4241,14 +4253,19 @@
         # Go round, and ask them again
         $login = "";
       }
+      
+      die "Failed to get a valid email address: $login\n" if
+	      ($cycle_count++ > MAX_PROMPT_CYCLE);
     }
     $login = $dbh->quote($login);
     $sth = $dbh->prepare("SELECT login_name FROM profiles" .
                         " WHERE login_name=$login");
     $sth->execute;
     if ($sth->rows > 0) {
+      if (not $answer{'ADMIN_OK'}) {
       print "$login already has an account.\n";
       print "Make this user the administrator? [Y/n] ";
+      }
       my $ok = $answer{'ADMIN_OK'} 
           || ($silent && die("cant preload ADMIN_OK")) 
           || <STDIN>;
@@ -4275,17 +4293,21 @@
     }
   }
 
-  if ($admin_create) {
 
+    $cycle_count = 0;
     while( $realname eq "" ) {
-      print "Enter the real name of the administrator: ";
+      print "Enter the real name of the administrator: " 
+      	unless defined $answer{'ADMIN_REALNAME'};
       $realname = $answer{'ADMIN_REALNAME'} 
           || ($silent && die("cant preload ADMIN_REALNAME")) 
           || <STDIN>;
       chomp $realname;
+      
       if(! $realname ) {
         print "\nReally.  We need a full name.\n";
       }
+      die "Failed to get a valid realname: $realname\n" if
+	      ($cycle_count++ > MAX_PROMPT_CYCLE);
     }
 
     # trap a few interrupts so we can fix the echo if we get aborted.
@@ -4294,17 +4316,23 @@
     $SIG{QUIT} = \&bailout;
     $SIG{TERM} = \&bailout;
 
-    if ($^O !~ /MSWin32/i) {
+    # only on interactive mode !
+    if ((not $answer{'ADMIN_PASSWORD'}) and $^O !~ /MSWin32/i) {
         system("stty","-echo");  # disable input echoing
     }
+    my $interactive = 1;
+    $interactive = 0 if defined $answer{'ADMIN_PASSWORD'};
 
     while( $pass1 ne $pass2 ) {
+      $cycle_count = 0;
       while( $pass1 eq "" || $pass1 !~ /^[[:print:]]{3,16}$/ ) {
-        print "Enter a password for the administrator account: ";
+        print "Enter a password for the administrator account: "
+		unless defined $answer{'ADMIN_PASSWORD'};
         $pass1 = $answer{'ADMIN_PASSWORD'} 
             || ($silent && die("cant preload ADMIN_PASSWORD")) 
             || <STDIN>;
         chomp $pass1;
+	
         if(! $pass1 ) {
           print "\n\nAn empty password is a security risk. Try again!\n";
         } elsif ( $pass1 !~ /^.{3,16}$/ ) {
@@ -4312,8 +4340,13 @@
         } elsif ( $pass1 !~ /^[[:print:]]{3,16}$/ ) {
           print "\n\nThe password contains non-printable characters.\n";
         }
+        
+	die "Failed to get a valid password: $pass1\n" if
+	      ($cycle_count++ > MAX_PROMPT_CYCLE);
       }
-      print "\nPlease retype the password to verify: ";
+      print "\nPlease retype the password to verify: " 
+      	if $interactive;
+	
       $pass2 = $answer{'ADMIN_PASSWORD'} 
           || ($silent && die("cant preload ADMIN_PASSWORD")) 
           || <STDIN>;
@@ -4343,9 +4376,26 @@
     # Set default email flags for the Admin, same as for users
     my $defaultflagstring = $dbh->quote(Bugzilla::Constants::DEFAULT_EMAIL_SETTINGS);
 
-    $dbh->do("INSERT INTO profiles (login_name, realname, cryptpassword, emailflags) " .
-             "VALUES ($login, $realname, $cryptedpassword, $defaultflagstring)");
+  if ($admin_create) {
+    warn "Creating the administrator $login...\n"
+    	if ($answer{'ADMIN_REALNAME'});
+
+    unless($dbh->do("INSERT INTO profiles (login_name, realname, cryptpassword, emailflags) " .
+             "VALUES ($login, $realname, $cryptedpassword, $defaultflagstring)")) {
+	die "Unable to create the $login profile.";
   }
+  }
+
+  # The ADMIN_REALNAME exists already, but we have to update his profile.
+  else {
+	warn "Updating the $login account...\n";
+	unless ($dbh->do("UPDATE profiles SET realname=$realname, cryptpassword=$cryptedpassword ".
+		 "WHERE login_name=$login")) {
+		die "Unable to update the $login profile.";
+	}
+  }
+
+  unless ($update_only) {
     # Put the admin in each group if not already    
     my $query = "select userid from profiles where login_name = $login";    
     $sth = $dbh->prepare($query); 
@@ -4371,6 +4422,7 @@
             (member_id, grantor_id, isbless)
             VALUES ($admingroupid, $group, 1)");
     }
+  }
 
   print "\n$login is now set up as an administrator account.\n";
 }

From gerv at mozilla.org  Tue Jan 18 23:43:33 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 18 Jan 2005 23:43:33 +0000
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
Message-ID: <41ED9F25.9080106@mozilla.org>

Christopher Hicks wrote:
> On Tue, 18 Jan 2005, Gervase Markham wrote:
> 
>> Remind me why delivering early is a good thing?
> 
> Because delivering late annoys people.

You know what I meant :-)

"Remind me why delivering sooner than six months after the release we 
just did is a good thing?"

>> If we expect a freeze time of 1 month for 2.20, we should set the 
>> freeze date to be five months from last Sunday - i.e. June 16th, for 
>> release in mid-July. Then, we will be making releases approximately 
>> six months apart.
> 
> Dave has indicated that the freezes will be timed, not the releases so 
> basing dates off of the release date does not fit with the logic that 
> Dave feels was agreed upon.

I'm suggesting that we revisit that logic. One can make an argument for 
"releases every X months", for most sane values of X, but I can't see an 
argument for "freezes every X months". How is the date of a freeze 
important? Surely it's the release date you are trying to hit that's the 
important thing.

>> Aiming for six months apart and hitting seven months is no big deal.
> 
> For an open source project maybe.

Indeed, which is what we are discussing :-)

> I've proposed a solution to this - have some releases be supported 
> longer than others.  Some people need long-term stability (ala RHES).

We could do that, but it might get a bit confusing. Having release X 
still supported while X+1 is not might lead to some strange conversations.
"I need help with release X+1".
"Sorry, it's not supported."
"Yeah, but release X from six months before is supported! How is it hard 
to support release X+1?"
"Er..."

In practice, we'd end up supporting any release more recent than the 
oldest supported release.

But I'd certainly support this model over a "everything supported for 18 
months" model if we are releasing as often as seems to be the plan.

Gerv


From gerv at mozilla.org  Tue Jan 18 23:45:53 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 18 Jan 2005 23:45:53 +0000
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED66F1.1080902@bugzilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net> <41ED66F1.1080902@bugzilla.org>
Message-ID: <41ED9FB1.1050609@mozilla.org>

David Miller wrote:
> Not sure if this is a good place for the Bugzilla modules, since they're 
> not official CPAN modules and are only used in Bugzilla. 
> /usr/lib/bugzilla might be a better place for them.  On the other hand, 
> putting them into the official Perl path means you don't have to fiddle 
> with the "use lib" line in every file to get it to find them, so the 
> patch is smaller. :)

I don't think there's any chance of a name clash ;-) If Debian policy 
allows them to be there, let's put them there.

> It should be possible to do something like [% webpath %] in front of the 
> pathname to all of the images, js, css, etc files.  

Can we not do this automatically, or using some sort of TT variable? 
It's a shame to clutter all the templates. Or is that not what you are 
suggesting?

Gerv


From jake at bugzilla.org  Wed Jan 19 02:41:04 2005
From: jake at bugzilla.org (Jake)
Date: Tue, 18 Jan 2005 21:41:04 -0500 (EST)
Subject: Release timing
In-Reply-To: <41ECC7DB.4060307@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com>
    <41ECC7DB.4060307@bugzilla.org>
Message-ID: <59476.217.26.84.76.1106102464.squirrel@mail.steenhagen.us>

> Of note is that the freeze tends to happen before rc1 unless the trunk
> it particularly stable.  We freeze the trunk on March 15th, and then
> release rc1 and branch once we feel it's ready (at which time the trunk
> thaws, but the release isn't out until the showstopper bugs reported
> against rc1 are fixed).

So, if I understand this right, what we're currently thinking is that we
freeze March 15th. Depending on how stable the trunk is at that point (it
should be fairly stable, but we'll know for sure in early March) we
upgrade bmo on that date. Once we do the post-bmo stabilization (probably
about a 2 week timeframe) we put out 2.20rc1. Give that a week or so to
shake-down and if there's nothing major changed, put out 2.20. In an ideal
world, that would give us a release in the 1st week of April. That's still
only 3 months since 2.20 came out and seems entirely doable (manpower
permiting).


From jake at bugzilla.org  Wed Jan 19 02:46:08 2005
From: jake at bugzilla.org (Jake)
Date: Tue, 18 Jan 2005 21:46:08 -0500 (EST)
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com>
    <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>
    <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
Message-ID: <14242.217.26.84.76.1106102768.squirrel@mail.steenhagen.us>

> I've proposed a solution to this - have some releases be supported longer
>  than others.  Some people need long-term stability (ala RHES).  Have
> other releases be supported until two releases have been made.  So if 2.20
>  became a "long-term support" release, it would continue to be supported
> for three years.  During that time, six releases would come out (two per
> year).  So at any one time two "short term" releases would be in support
> and one or two "long term" releases.  This way there would never be five
> branches being supported at once and usually there would only be three -
> the long term one and two short term ones.

I think this is where the branch maintainers thing that Dave was talking
about may help things. We set a minimum support timeframe (6 months
bugfixes, 18 months security) and if a branch maintainer wants to carry
bugfixes for a year, so be it. If they want to support security fixes for
3 years, that's their choice. This would be ideal for situations where,
for example, there's a Debian package on a stable version of Debian that
only allows security fixes. The branch maintainer can keep up with
security on that branch until that version of Debian hits EOL. We should
set a strict policy, IMHO, for branch maintainers that no new features
land on a branch.


From justdave at bugzilla.org  Wed Jan 19 03:00:04 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 18 Jan 2005 22:00:04 -0500
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED9FB1.1050609@mozilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net> <41ED66F1.1080902@bugzilla.org> <41ED9FB1.1050609@mozilla.org>
Message-ID: <41EDCD34.4070104@bugzilla.org>

Gervase Markham wrote:
> David Miller wrote:
> 
>> It should be possible to do something like [% webpath %] in front of 
>> the pathname to all of the images, js, css, etc files.  
> 
> Can we not do this automatically, or using some sort of TT variable? 
> It's a shame to clutter all the templates. Or is that not what you are 
> suggesting?

If TT does it globally, it'll affect all of the cgi references as well, 
and we don't want that.

What I'm suggesting is (for example) in the header template, instead of:

     <link href="skins/standard/global.css" rel="stylesheet" 
type="text/css">
     <link href="skins/custom/global.css" rel="stylesheet" type="text/css">

We do:

     <link href="[% webpath %]skins/standard/global.css" 
rel="stylesheet" type="text/css">
     <link href="[% webpath %]skins/custom/global.css" rel="stylesheet" 
type="text/css">


-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From justdave at bugzilla.org  Wed Jan 19 03:04:04 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 18 Jan 2005 22:04:04 -0500
Subject: Release timing
In-Reply-To: <41ED9F25.9080106@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org>
Message-ID: <41EDCE24.40609@bugzilla.org>

Gervase Markham wrote:

> "Remind me why delivering sooner than six months after the release we 
> just did is a good thing?"
> 
> I'm suggesting that we revisit that logic. One can make an argument for 
> "releases every X months", for most sane values of X, but I can't see an 
> argument for "freezes every X months". How is the date of a freeze 
> important? Surely it's the release date you are trying to hit that's the 
> important thing.

But Nick's idea didn't say that.

We advertise to everyone "we're releasing every 6 months".

We make those dates be May 15 and November 15 every year.

In order to meet those release dates, we freeze 2 months in advance, i.e 
March 15 and September 15.

If things happen to get cleaned up faster than 2 months, then we release 
early.

So the releases could, in theory, range anywhere from 4 to 8 months 
apart from each other, but will very likely stay pretty close to 6 
months anyway.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From stu at asyn.com  Wed Jan 19 03:57:47 2005
From: stu at asyn.com (Stuart Donaldson)
Date: Tue, 18 Jan 2005 19:57:47 -0800
Subject: Release timing
In-Reply-To: <41EDCE24.40609@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org>
Message-ID: <41EDDABB.4000309@asyn.com>

Trying to reset on some arbitrary calendar basis, based on the last 
freeze, would appear to open Bugzilla up to an abnormally long 
stabilization effort, causing problems.

What about the idea of "Freezing" 4 months after a release, allowing for 
an estimated 2 month stabilization time, give or take some arbitrarily 
long time like Bugzilla just experienced.  During the freeze, the trunk 
is frozen, no new development branch is created, to encourage people to 
work on stabilization efforts. Basically, By not resetting the clock 
until the release goes out, you solve the problem of having releases 
stacking up, and you guarantee a suitable window for feature enhancement.

I thought I saw this suggested, and apparently hadn't been following 
this thread closely enough, or missed why this wouldn't work.

Thoughts?

-Stuart-



David Miller wrote:

> Gervase Markham wrote:
>
>> "Remind me why delivering sooner than six months after the release we 
>> just did is a good thing?"
>>
>> I'm suggesting that we revisit that logic. One can make an argument 
>> for "releases every X months", for most sane values of X, but I can't 
>> see an argument for "freezes every X months". How is the date of a 
>> freeze important? Surely it's the release date you are trying to hit 
>> that's the important thing.
>
>
> But Nick's idea didn't say that.
>
> We advertise to everyone "we're releasing every 6 months".
>
> We make those dates be May 15 and November 15 every year.
>
> In order to meet those release dates, we freeze 2 months in advance, 
> i.e March 15 and September 15.
>
> If things happen to get cleaned up faster than 2 months, then we 
> release early.
>
> So the releases could, in theory, range anywhere from 4 to 8 months 
> apart from each other, but will very likely stay pretty close to 6 
> months anyway.
>



From bugreport at peshkin.net  Wed Jan 19 06:26:47 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Tue, 18 Jan 2005 22:26:47 -0800
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED9FB1.1050609@mozilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net> <41ED66F1.1080902@bugzilla.org> <41ED9FB1.1050609@mozilla.org>
Message-ID: <41EDFDA7.2000401@peshkin.net>

Gervase Markham wrote:

> David Miller wrote:
>
>> Not sure if this is a good place for the Bugzilla modules, since 
>> they're not official CPAN modules and are only used in Bugzilla. 
>> /usr/lib/bugzilla might be a better place for them.  On the other 
>> hand, putting them into the official Perl path means you don't have 
>> to fiddle with the "use lib" line in every file to get it to find 
>> them, so the patch is smaller. :)
>
>
> I don't think there's any chance of a name clash ;-) If Debian policy 
> allows them to be there, let's put them there.
>
That ould be only for Debuan, right?   I woun't want to REQUIRE all 
installations to do that.



From sukria at sukria.net  Wed Jan 19 07:39:25 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Wed, 19 Jan 2005 08:39:25 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41ED9FB1.1050609@mozilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net> <41ED66F1.1080902@bugzilla.org> <41ED9FB1.1050609@mozilla.org>
Message-ID: <20050119073924.GB20866@sukria.net>

* Gervase Markham (gerv at mozilla.org) disait :
> I don't think there's any chance of a name clash ;-) If Debian policy 
> allows them to be there, let's put them there.

I completely agree with you Gervase.

Moreover, I spoke about this issue with some Debian Developers
yesterday, telling them that I'd like to put a specific Perl Module in
/usr/share/perl5/$package and asking them if it violateis the Debian
Policy.

They answered that it's up to me. Nothing in the Policy says that _only_
CPAN modules go in that place.

Second, I package another piece of software wich has also Perl modules
and I used /usr/share/perl5/$package too; and you know what, it was
accepted to enter Debian by my sponsor... (IIRC my sponsor adviced me to
use that place for my modules).

To conclude, I think that if a piece of software has to use its own
Foo::Bar Perl package, one good place to install the .pm files is
/usr/share/perl5/Foo.

Best regards,

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From sukria at sukria.net  Wed Jan 19 08:09:13 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Wed, 19 Jan 2005 09:09:13 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41EDCD34.4070104@bugzilla.org>
References: <20050118110532.GA10952@sukria.net> <41ED50AD.80106@mozilla.org> <20050118184347.GB15648@sukria.net> <41ED66F1.1080902@bugzilla.org> <41ED9FB1.1050609@mozilla.org> <41EDCD34.4070104@bugzilla.org>
Message-ID: <20050119080912.GA21314@sukria.net>

* David Miller (justdave at bugzilla.org) disait :
> What I'm suggesting is (for example) in the header template, instead of:
> 
>     <link href="skins/standard/global.css" rel="stylesheet" 
> type="text/css">
>     <link href="skins/custom/global.css" rel="stylesheet" type="text/css">
> 
> We do:
> 
>     <link href="[% webpath %]skins/standard/global.css" 
> rel="stylesheet" type="text/css">
>     <link href="[% webpath %]skins/custom/global.css" rel="stylesheet" 
> type="text/css">

In my opinion, that's the best solution to that issue.
I'm working on it for the Debian package and will send you the patch
when it's ok.

I've added $Bugzilla::Config::WEBPATH which should be blank in your
upstream default and should be '/bugzilla/' in the debian package.

Regards.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From Nick.Barnes at pobox.com  Wed Jan 19 14:13:53 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Wed, 19 Jan 2005 14:13:53 +0000
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41EDCD34.4070104@bugzilla.org> 
   from David Miller <justdave@bugzilla.org> 
   of "Tue, 18 Jan 2005 22:00:04 -0500"
Message-ID: <15762.1106144033@thrush.ravenbrook.com>

At 2005-01-19 03:00:04+0000, David Miller writes:
> Gervase Markham wrote:
> > David Miller wrote:
> > 
> >> It should be possible to do something like [% webpath %] in front of 
> >> the pathname to all of the images, js, css, etc files.  
> > 
> > Can we not do this automatically, or using some sort of TT variable? 
> > It's a shame to clutter all the templates. Or is that not what you are 
> > suggesting?
> 
> If TT does it globally, it'll affect all of the cgi references as well, 
> and we don't want that.
> 
> What I'm suggesting is (for example) in the header template, instead of:
> 
>      <link href="skins/standard/global.css" rel="stylesheet" 
> type="text/css">
>      <link href="skins/custom/global.css" rel="stylesheet" type="text/css">
> 
> We do:
> 
>      <link href="[% webpath %]skins/standard/global.css" 
> rel="stylesheet" type="text/css">
>      <link href="[% webpath %]skins/custom/global.css" rel="stylesheet" 
> type="text/css">

Could the same thing be achieved by symlinks?

Nick B


From sukria at sukria.net  Wed Jan 19 14:44:55 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Wed, 19 Jan 2005 15:44:55 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41EDCD34.4070104@bugzilla.org>
References: <41EDCD34.4070104@bugzilla.org> <justdave@bugzilla.org> <15762.1106144033@thrush.ravenbrook.com>
Message-ID: <20050119144454.GC22718@sukria.net>

* Nick Barnes (Nick.Barnes at pobox.com) disait :
> > What I'm suggesting is (for example) in the header template, instead of:
> > 
> >      <link href="skins/standard/global.css" rel="stylesheet" 
> > type="text/css">
> >      <link href="skins/custom/global.css" rel="stylesheet" type="text/css">
> > 
> > We do:
> > 
> >      <link href="[% webpath %]skins/standard/global.css" 
> > rel="stylesheet" type="text/css">
> >      <link href="[% webpath %]skins/custom/global.css" rel="stylesheet" 
> > type="text/css">
> 
> Could the same thing be achieved by symlinks?

In Debian, that's definitively not possible: that would suppose to make
symlinks inside /var/lib/cgi-bin/bugzilla to point to 
/usr/share/bugzilla/web/{css,js, ...}

That's not allowed by the Policy to put non-cgi files in a cgi location,
which is understandable I suppose :)

I really find the [% webpath %] solution interesting, moreover, I
started to implement that on my local box and that works great.

I'll follow up in that way.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From justdave at bugzilla.org  Wed Jan 19 19:43:37 2005
From: justdave at bugzilla.org (David Miller)
Date: Wed, 19 Jan 2005 14:43:37 -0500
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050119144454.GC22718@sukria.net>
References: <41EDCD34.4070104@bugzilla.org> <justdave@bugzilla.org> <15762.1106144033@thrush.ravenbrook.com> <20050119144454.GC22718@sukria.net>
Message-ID: <41EEB869.6020500@bugzilla.org>

Alexis Sukrieh wrote:

> That's not allowed by the Policy to put non-cgi files in a cgi location,
> which is understandable I suppose :)

Out of curiosity (I know I'm going way offtopic here) why are php files 
allowed outside of cgi-bin?  :)  They can do just as much damage as 
other cgi scripts.  If it's the fact that they're actually interpreted 
by Apache instead of shelling out to them, would running Bugzilla under 
mod_perl let us put the files outside of cgi-bin?  mod_perl is just like 
mod_php in that regard.  (Bugzilla doesn't run under mod_perl yet, but 
it will one of these days)

I note that the mailman package has a /var/lib/mailman/cgi-bin, which is 
symlinked from /usr/lib/cgi-bin/mailman.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From kevin.benton at amd.com  Wed Jan 19 21:39:37 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Wed, 19 Jan 2005 14:39:37 -0700
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41EEB869.6020500@bugzilla.org>
Message-ID: <20050119213937.43ADE1FA0@ldcmail.amd.com>

It's all in the Apache configuration where to allow .php files execute
permission versus where not to.  In the "php.conf" as distributed with
Redhat, there is no directory restriction around the <Files *.php>.  So,
webmasters who haven't checked their Apache config thoroughly will be
surprised to find that PHP can run from anywhere on their web server.

If, on the other hand, they did...

<Directory such/and/such>
  <Files *.php>
    ...
  </Files>
</Directory>

... they would find that PHP files outside those directories would not be
executed.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 
> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of David Miller
> Sent: Wednesday, January 19, 2005 12:44 PM
> To: developers at bugzilla.org
> Subject: Re: Packaging of Bugzilla 2.18 in Debian
> 
> Alexis Sukrieh wrote:
> 
> > That's not allowed by the Policy to put non-cgi files in a cgi location,
> > which is understandable I suppose :)
> 
> Out of curiosity (I know I'm going way offtopic here) why are php files
> allowed outside of cgi-bin?  :)  They can do just as much damage as
> other cgi scripts.  If it's the fact that they're actually interpreted
> by Apache instead of shelling out to them, would running Bugzilla under
> mod_perl let us put the files outside of cgi-bin?  mod_perl is just like
> mod_php in that regard.  (Bugzilla doesn't run under mod_perl yet, but
> it will one of these days)
> 
> I note that the mailman package has a /var/lib/mailman/cgi-bin, which is
> symlinked from /usr/lib/cgi-bin/mailman.
> 
> --
> Dave Miller                                   http://www.justdave.net/
> System Administrator, Mozilla Foundation       http://www.mozilla.org/
> Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From gerv at mozilla.org  Wed Jan 19 22:32:48 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 19 Jan 2005 22:32:48 +0000
Subject: Release timing
In-Reply-To: <14242.217.26.84.76.1106102768.squirrel@mail.steenhagen.us>
References: <79808.1105621455@thrush.ravenbrook.com>    <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>    <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <14242.217.26.84.76.1106102768.squirrel@mail.steenhagen.us>
Message-ID: <41EEE010.3040205@mozilla.org>

Jake wrote:
> I think this is where the branch maintainers thing that Dave was talking
> about may help things. 

I'm not so keen on the branch maintainers idea, because I feel we should 
be collectively responsible for whichever releases we are supporting...

> We set a minimum support timeframe (6 months
> bugfixes, 18 months security) and if a branch maintainer wants to carry
> bugfixes for a year, so be it. 

...and I'd be particularly concerned about it if the choice of which 
branches to support for how long was in the hands of a group of 
different people, instead of being centrally planned.

Gerv


From gerv at mozilla.org  Wed Jan 19 22:34:44 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 19 Jan 2005 22:34:44 +0000
Subject: Release timing
In-Reply-To: <41EDCE24.40609@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org>
Message-ID: <41EEE084.7080604@mozilla.org>

David Miller wrote:
> But Nick's idea didn't say that.
> 
> We advertise to everyone "we're releasing every 6 months".

So far, so good.

> We make those dates be May 15 and November 15 every year.

But we've just released on January 16th. So why are the dates not 
January 16th and July 16th?

> So the releases could, in theory, range anywhere from 4 to 8 months 
> apart from each other, but will very likely stay pretty close to 6 
> months anyway.

That's cool, but in getting into this system, we appear to be lined up 
for two releases closer together than six months.

What's so special about May and November which means we have to release 
then? Why not get straight into the 6-month system, and advertise 
January and July?

Gerv


From gerv at mozilla.org  Wed Jan 19 22:37:15 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Wed, 19 Jan 2005 22:37:15 +0000
Subject: Release timing
In-Reply-To: <41EDDABB.4000309@asyn.com>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EDDABB.4000309@asyn.com>
Message-ID: <41EEE11B.8080204@mozilla.org>

Stuart Donaldson wrote:
> Trying to reset on some arbitrary calendar basis, based on the last 
> freeze, would appear to open Bugzilla up to an abnormally long 
> stabilization effort, causing problems.

I would note, though, that the amount of stabilisation time required is 
not really a function of the scheduling :-)

> What about the idea of "Freezing" 4 months after a release, allowing for 
> an estimated 2 month stabilization time, give or take some arbitrarily 
> long time like Bugzilla just experienced.  

Replace the 4 with a 5, and the 2 with a 1 (as 1 month is how long Dave 
estimates stabilisation for 6-month cycles will take) and that's 
basically what I'm also suggesting :-)

Gerv


From travis at SEDSystems.ca  Wed Jan 19 22:56:52 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Wed, 19 Jan 2005 16:56:52 -0600 (CST)
Subject: Release timing
In-Reply-To: <41EEE084.7080604@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
 <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org>
 <41EEE084.7080604@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>



On Wed, 19 Jan 2005, Gervase Markham wrote:

> What's so special about May and November which means we have to release
> then?

May and November are both months where people are at work, where there are
not a lot of other things going on to interfere with contributing, where it
is possible to schedule a 'big push to the finish' and be reasonably
confident that most of your key people will be around.

> Why not get straight into the 6-month system, and advertise January and
> July?

January and July are, by contrast, *bad* months to try do a final push; in
fact, January would be my 12th choice of months in which to try and do a
release, simply because the majority of people in the English-speaking world
will just have had Christmas holidays... making January a rotten time to do
a 'big push' on anything.

July would be right near the bottom too, just for the reason of summer
vacations. I'd rank it only slightly above August. Combine them, and they
fall to 6th place in a semi-yearly release schedule, from my perspective.

In reverse order, my personal list would be:

6th - Jan/July - reasons stated above
5th - Jun/Dec - mostly same reasons, not QUITE so bad, but if you slip over
	your schedule, you've got no workforce.
4th - Feb/Aug - mostly because of August
3rd - Mar/Sep - Sep is the psychological beginning of the year for people
	who have kids; new school year and all that. Again, much of your
        workforce will be here and there over the summer.
2nd - Apr/Oct - we don't deal with university contributors much (I don't
	think), but this would be bad for them...
1st - May/Nov - Everythig has past, nothing is imminent. Good time for a
	big push for closure.

Hey, you asked... ;)

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith



From gerv at mozilla.org  Thu Jan 20 00:03:55 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Thu, 20 Jan 2005 00:03:55 +0000
Subject: Release timing
In-Reply-To: <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
Message-ID: <41EEF56B.1040003@mozilla.org>

Shane H. W. Travis wrote:
> May and November are both months where people are at work, where there are
> not a lot of other things going on to interfere with contributing, where it
> is possible to schedule a 'big push to the finish' and be reasonably
> confident that most of your key people will be around.

That may or may not be true, but it's certainly the first time an 
argument of this type has come by the list. I thought that May and 
November were picked because those were the dates we expected to hit 12 
months ago.

> January and July are, by contrast, *bad* months to try do a final push; in
> fact, January would be my 12th choice of months in which to try and do a
> release, simply because the majority of people in the English-speaking world
> will just have had Christmas holidays... making January a rotten time to do
> a 'big push' on anything.

Surely it depends if Bugzilla contributors contribute more during the 
holidays or when people are at work?

I know I contribute much more in the holiday times; January is a good 
time for a push, for me.

Regardless, I'm not sure that the variations of people's availability is 
a good basis for planning release pushes, because everyone has different 
schedules. Rather, we should plan them so releases are six months apart :-)

Gerv


From vladd at bugzilla.org  Thu Jan 20 00:06:58 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Thu, 20 Jan 2005 02:06:58 +0200
Subject: Release timing
In-Reply-To: <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
Message-ID: <41EEF622.9010406@bugzilla.org>

Shane H. W. Travis wrote:

>
>May and November are both months where people are at work
>
Exactly. What is a working day for Bugzilla anyway?

I found I'm most productive during Christmas/New Year periods, where I 
can put aside school and my current job and focus on my hobbies, Bugzilla.

We have contributors from both the "hobbists" and the "corporate" 
environment, so any argument for a month better than another would end 
up valid from one environment and invalid from the other one. Our 
community is pretty well mixed between those two, so I guess any month 
is in average suited the same for the release.

Vlad.



From justdave at bugzilla.org  Thu Jan 20 00:34:51 2005
From: justdave at bugzilla.org (David Miller)
Date: Wed, 19 Jan 2005 19:34:51 -0500
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050119213937.43ADE1FA0@ldcmail.amd.com>
References: <20050119213937.43ADE1FA0@ldcmail.amd.com>
Message-ID: <41EEFCAB.80902@bugzilla.org>

Kevin Benton wrote:
> It's all in the Apache configuration where to allow .php files execute
> permission versus where not to.  In the "php.conf" as distributed with
> Redhat, there is no directory restriction around the <Files *.php>.  So,
> webmasters who haven't checked their Apache config thoroughly will be
> surprised to find that PHP can run from anywhere on their web server.

Yep, I know.  The point is that Debian ships with it enabled everywhere, 
too.  Even though they have a policy that all cgi files have to be in 
/cgi-bin/

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From stu at asyn.com  Thu Jan 20 04:10:47 2005
From: stu at asyn.com (Stuart Donaldson)
Date: Wed, 19 Jan 2005 20:10:47 -0800
Subject: Release timing
In-Reply-To: <41EEE11B.8080204@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EDDABB.4000309@asyn.com> <41EEE11B.8080204@mozilla.org>
Message-ID: <41EF2F47.8030408@asyn.com>

Gervase Markham wrote:

> Stuart Donaldson wrote:
>
>> What about the idea of "Freezing" 4 months after a release, allowing 
>> for an estimated 2 month stabilization time, give or take some 
>> arbitrarily long time like Bugzilla just experienced.  
>
>
> Replace the 4 with a 5, and the 2 with a 1 (as 1 month is how long 
> Dave estimates stabilisation for 6-month cycles will take) and that's 
> basically what I'm also suggesting :-)
>
I didn't get that out of the previous messages.  We should be clear 
about saying "Bugzilla will release approximately every 6 months or so, 
with a feature freeze 5 months after release, and estimating 1 month for 
stabilization.

Saying we release every 6 months, and more importantly putting dates to 
it, implies that the clock does not get reset based on the release, but 
is of a fixed period.

-Stuart-


From sukria at sukria.net  Thu Jan 20 07:30:01 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Thu, 20 Jan 2005 08:30:01 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41EEFCAB.80902@bugzilla.org>
References: <20050119213937.43ADE1FA0@ldcmail.amd.com> <41EEFCAB.80902@bugzilla.org>
Message-ID: <20050120073000.GA30127@sukria.net>

* David Miller (justdave at bugzilla.org) disait :
> The point is that Debian ships with it enabled everywhere, 
> too.  Even though they have a policy that all cgi files have to be in 
> /cgi-bin/

Indeeed, you underlined a true issue. To me, ideally, the idea behind 
the Policy statement about CGI might be extended to PHP scrits.

Doing such a change in the Policy will certainly cause the anger of 
many maintainers although (and by the way, trigger a lot of Policy
violations)...

I'll send a mail to debian-policy at lists.debian.org in order to discuss
this issue.

Thanks for the note Dave :)

Regards,

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From chicks at chicks.net  Thu Jan 20 17:52:26 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Thu, 20 Jan 2005 12:52:26 -0500 (EST)
Subject: Release timing
In-Reply-To: <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
 <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org>
 <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca>
Message-ID: <Pine.LNX.4.61.0501201237340.7454@skippy.fini.net>

On Wed, 19 Jan 2005, Shane H. W. Travis wrote:
> 1st - May/Nov - Everythig has past, nothing is imminent. Good time for a
> 	big push for closure.

I must say this really makes a lot of sense.  Shane may have gone to a 
more thorough effort to prove the case than necessary, but in my opinion 
its a point well made.

While I sympathise with Vlad and Gerv for their holiday push I suspect 
that most of humanity gets more work done during work months and less work 
done during holiday months.  But these objections are not merely 
anecdotal, but also help underscore Shane's point.  I'm sure some 
significant percentage of folks will take advantage of the holidays to do 
development of various types that will move bugzilla along, but it seems 
to be that would be the time for blazing new trails instead of cleaning up 
old ones.  The central question is: do you think most people will be more 
available and more easy to reach over the holidays or over the 
nonholidays?  I hope its clear to everybody that doing doing the "big 
push" towards a release is a time when having all hands on deck and the 
least chance of barriers to communication is going to be when people are 
not on the Internet through their relatives decrepit dialup connection.**

I applaud Dave's effort to move the schedule to one that works the same 
year after year.  Whether he put Shane's depth of thought into deciding 
the dates, the dates seem well chosen to me.  This will help establish a 
rhythm for the development team and the user community that fits the best 
with the tides of humanity instead of trying to swim against them.  My 
inner Taoist is very pleased.  :)

-- 
</chris>

** I finally have all of my nearby relatives on broadband.  Now to get 
them all to have wireless so I don't have to plug into the Ethernet...

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From myk at mozilla.org  Fri Jan 21 19:09:05 2005
From: myk at mozilla.org (Myk Melez)
Date: Fri, 21 Jan 2005 11:09:05 -0800
Subject: Custom fields schema
In-Reply-To: <20041224035205.4174BBC60@mail.schwag.org>
References: <20041224035205.4174BBC60@mail.schwag.org>
Message-ID: <41F15351.4020401@mozilla.org>

    Sean McAfee wrote:

>Do you have a specific proposal that can be tested?  And, er, I don't want
>to sound rude, but would you mind testing it yourself?  I've already done
>quite a lot in that area.
>  
>

Ok, I modified construct-tables.pl to add fulltext indexes to the text 
columns in the tests, create "real-distributed" columns (real columns, 
but in a separate table rather than the bugs table, which is how a "real 
columns" custom fields implementation would handle sparse columns), and 
make distributed and real-distributed versions of the status whiteboard 
field.

I then wrote a script to automate testing of the queries in your earlier 
email.  It runs each query six times, discards the first result (which 
is often inaccurate because it includes costs unrelated to the query 
itself), averages the rest, and reports the results in a table similar 
to the one you included in your earlier email along with each test's 
details (the query, its query optimizer "explanation", and individual 
run times).

I didn't modify your test queries except to fix some typos that caused 
several of them not to run.  I added additional tests, including 
versions of yours that use fulltext indexes, a couple that join tables 
the way Bugzilla does in its queries (labeled "bzlike" in the tests), 
and one that runs an actual Bugzilla query (a search for "meta" in the 
status whiteboard of all bugs) along with distributed and 
real-distributed versions of it against a recent copy of the b.m.o database.

I ran the tests on two machines, one called holepunch with two 733Mhz 
x86 processors and one called megalon with two hyperthreaded Intel Xeon 
2.xGhz processors.  holepunch did nothing but run the tests, but megalon 
did other things at the same time, so its results may be subject to more 
variance.

I've attached the modified construct-tables.pl script, the 
test-performance.pl script that runs the tests, and both machines' 
results, which show the real and real-distributed queries outperforming 
the distributed queries by significant margins in every case, regardless 
of indexing, but up to 10x faster when using fulltext indexes.

I think these results are pretty accurate.  They validate database 
theory (as bbaetz said of the distributed model, "it can usually never 
be faster") and the consequencies of MySQL's "one index per table" 
restriction.  I'm sure there are still optimizations that could be done, 
and the queries themselves could be made much more indicative of real 
Bugzilla queries along the lines bbaetz suggested in his email.

It would also be useful to run these against a PostGreSQL database and 
on additional machines.  But I think the result would be the same: real 
columns (either within the bugs table or in their own table if sparse) 
would outperform distributed ones.

-myk


Notes:

    * Make sure you're running at least MySQL 4.0 if you try these tests
      yourself.  Version 3.23 creates fulltext indexes too slowly on
      datasets of the size generated by construct-tables.pl.
    * Found records will vary between non-indexed and indexed queries
      because the fulltext searches look for words starting with "meta"
      instead of the "meta" substring.  This limitation of fulltext
      searching is well worth the advantages in query speed and
      relevance ranking--most people most of the time will want to
      fulltext search text.
    * I made a single change to the construct-tables.pl script since
      running it on the machines, removing generation of fulltext
      indexes for the real distributed tables other than cf_aa (since
      that one is actually used in a test, while the others aren't). 
      This shouldn't have any effect on test results.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/59d411c6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: construct-tables.pl
Type: application/x-perl
Size: 5412 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/59d411c6/attachment.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-performance.pl
Type: application/x-perl
Size: 17245 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/59d411c6/attachment-0001.pl>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/59d411c6/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/59d411c6/attachment-0002.html>

From myk at mozilla.org  Fri Jan 21 19:56:50 2005
From: myk at mozilla.org (Myk Melez)
Date: Fri, 21 Jan 2005 11:56:50 -0800
Subject: Custom fields schema
In-Reply-To: <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
References: <20041224081704.cd36e999@mail.kerio.com> <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
Message-ID: <41F15E82.5060500@mozilla.org>

Shane H. W. Travis wrote:

>On Fri, 24 Dec 2004, Maxwell Kanat-Alexander wrote:
>
>  
>
>>  Indeed. I also recall justdave pointing out (somewhere in the
>>userprefs-table bug, that I don't recall the number of) that for the
>>"Bugzilla plugins" idea, we should stick to "columns-as-table-rows,"
>>because that makes a drop-in plugin for Bugzilla much easier to write.    
>>
>
>I was just about to say the exact same thing, Max.
>
>Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=98123#c23
>
>The comment was made in the User Preferences bug, but the implications are
>far-reaching. I cannot help but think that if it matters here, then it would
>matter even more for something as large and far-reaching as customized
>fields.
>  
>
But preferences and custom fields are very different beasts.  
Preferences are data, like the other real-world objects (users, bugs) we 
model, while custom fields are structure, like the data structures we 
use when modeling those objects.

It makes sense to model preferences using the most appropriate 
combination of table, column, and row structures (f.e. with set theory, 
or using an object-oriented model where table = class, column = 
property, and row = instance); but doing so for custom fields just adds 
an unnecessary layer of abstraction and complexity.

Custom fields are exactly what relational database columns were designed 
for; they fit perfectly into the column metaphor, just as the standard 
Bugzilla fields do.  They're modifiable via SQL statements just as 
easily as the data within them is.  And while Bugzilla doesn't modify 
its schema very much today, there's nothing inherently more dangerous 
about it doing so.  You can wipe out your data just as easily with 
"DELETE FROM <columnname>" as you can with "DROP COLUMN <columnname>".

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050121/f8f876fe/attachment.html>

From gerv at mozilla.org  Sat Jan 22 10:55:17 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 22 Jan 2005 10:55:17 +0000
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <20050118211222.GA16208@sukria.net>
References: <20050118110532.GA10952@sukria.net> <41ECF60E.3070807@peshkin.net> <20050118211222.GA16208@sukria.net>
Message-ID: <41F23115.70907@mozilla.org>

Alexis Sukrieh wrote:
> Well, don't know if you guys will find this patch ok, but anyway, it
> works ;)

Alex,

It would be better if you filed a Bugzilla bug for your work, and 
attached the patch there. Then it can be tracked and reviewed properly. :-)

Thanks,

Gerv



From gerv at mozilla.org  Sat Jan 22 11:13:40 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sat, 22 Jan 2005 11:13:40 +0000
Subject: Release timing
In-Reply-To: <41EEF622.9010406@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca> <41EEF622.9010406@bugzilla.org>
Message-ID: <41F23564.9040303@mozilla.org>

Vlad Dascalu wrote:
> We have contributors from both the "hobbists" and the "corporate" 
> environment, so any argument for a month better than another would end 
> up valid from one environment and invalid from the other one. Our 
> community is pretty well mixed between those two, so I guess any month 
> is in average suited the same for the release.

Indeed - with the only difference being, we have to make two releases 
more like four-five months apart rather than six in order to "sync up" 
with the months we happen to have chosen.

But perhaps things would be clearer if Dave said why it was he chose May 
and November?

Gerv


From sukria at sukria.net  Sat Jan 22 11:15:19 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Sat, 22 Jan 2005 12:15:19 +0100
Subject: Packaging of Bugzilla 2.18 in Debian
In-Reply-To: <41F23115.70907@mozilla.org>
References: <20050118110532.GA10952@sukria.net> <41ECF60E.3070807@peshkin.net> <20050118211222.GA16208@sukria.net> <41F23115.70907@mozilla.org>
Message-ID: <20050122111518.GB16726@sukria.net>

* Gervase Markham (gerv at mozilla.org) disait :
> Alexis Sukrieh wrote:
> >Well, don't know if you guys will find this patch ok, but anyway, it
> >works ;)

No problem, I'll do it.

BTW, the packaging for 2.18 is on good shape, I've already published a
preview release:
http://www.sukria.net/en/archives/2005/01/21/bugzilla-218-debian-package-preview/

Im' currently working on fixing a couple of bugs in the package, and
will soon release a new preview version.

I think that 2.18 might get uploaded in sid soon...

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From chicks at chicks.net  Sat Jan 22 15:59:12 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sat, 22 Jan 2005 10:59:12 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41F15E82.5060500@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> <41F15E82.5060500@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>

On Fri, 21 Jan 2005, Myk Melez wrote:
> It makes sense to model preferences using the most appropriate combination of 
> table, column, and row structures (f.e. with set theory, or using an 
> object-oriented model where table = class, column = property, and row = 
> instance); but doing so for custom fields just adds an unnecessary layer of 
> abstraction and complexity.

Bah.  Your conclusion of what's necessary here seems to be based on a very 
selective view of the universe.  Several "necessities" stick out when 
considering a custom fields implemention based on abstraction at the 
database level:

(1) People can add as many custom fields as they want without worrying 
about reaching the maximum record size of their database

(2) Code for dealing with custom fields is going to need to have a goodly 
portion of the abstraction tables for keeping track of stuff anyways.

(3) Since queries that involve custom fields will now have to be written 
on the fly they are less able to be optimized by using a database that can 
deal with prepare() usefully.

(4) Since queries involving custom fields are going to take a few database 
hits to figure out what the field names so the query could be written you 
end up with cases where 1 query turns into 4 queries.  If the database is 
across a WAN from the bugzilla instance the effect of multiple queries 
where there were one will be more noticable.

(5) Custom fields should be able to be implemented without the bugzilla 
user having database privs to alter tables.

Myk - it sounds like you're basing the decision on what way to go here 
totally based on performance and I think there's a lot more that should go 
into this decision.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From chicks at chicks.net  Sat Jan 22 16:17:02 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sat, 22 Jan 2005 11:17:02 -0500 (EST)
Subject: Release timing
In-Reply-To: <41ED9F25.9080106@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
 <41ED9F25.9080106@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>

On Tue, 18 Jan 2005, Gervase Markham wrote:
> "Remind me why delivering sooner than six months after the release we just 
> did is a good thing?"

It may not be the ideal thing, but it seems better than the alternatives. 
Getting on a release rhythm may entail some occassional irritation, but I 
do think its worth the trouble.

>> Dave has indicated that the freezes will be timed, not the releases so 
>> basing dates off of the release date does not fit with the logic that Dave 
>> feels was agreed upon.
>
> I'm suggesting that we revisit that logic. One can make an argument for 
> "releases every X months", for most sane values of X, but I can't see an 
> argument for "freezes every X months". How is the date of a freeze 
> important? Surely it's the release date you are trying to hit that's the 
> important thing.

Having the freeze dates be something that people know from remember when 
it happened last year seems more important than exactly when we release to 
the world.  As long as there's been a release in the last year the user is 
going to feel like we're making progress, but the developers care about 
the exact freeze data because presumably they have something that they 
want in before the freeze.

>> I've proposed a solution to this - have some releases be supported longer 
>> than others.  Some people need long-term stability (ala RHES).
>
> We could do that, but it might get a bit confusing. Having release X still 
> supported while X+1 is not might lead to some strange conversations.
> "I need help with release X+1".
> "Sorry, it's not supported."
> "Yeah, but release X from six months before is supported! How is it hard to 
> support release X+1?"
> "Er..."

Instead of "er" you could say "Release X and X+3, and X+4 are supported, 
please help us to minimize the hassle of voluntarily maintaining bugzilla 
by using one of those.  Oh, by the way, X+3 is our next long-term stable 
release, so you'll be able to get support for it for a couple years."

> In practice, we'd end up supporting any release more recent than the 
> oldest supported release.

If people ignored the idea and went on doing what they've been doing then 
certainly practice would not exhibit the idea.

> But I'd certainly support this model over a "everything supported for 18 
> months" model if we are releasing as often as seems to be the plan.

Thanks.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From chicks at chicks.net  Sat Jan 22 16:25:16 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sat, 22 Jan 2005 11:25:16 -0500 (EST)
Subject: [ANN] Free Trac/Subversion hosting at Python-Hosting.com (fwd)
Message-ID: <Pine.LNX.4.61.0501221124130.7454@skippy.fini.net>

This is interesting.  My thoughts on it yet aren't very lucid, so I'll 
just give this to you without my spin on it...

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

---------- Forwarded message ----------
Date: Wed, 19 Jan 2005 18:34:46 +0000
From: Python-Hosting.com Support <support at python-hosting.com>
To: announce at subversion.tigris.org
Subject: [ANN] Free Trac/Subversion hosting at Python-Hosting.com

Hello everyone,

To celebrate its second anniversary,
Python-Hosting.com is happy to announce
that it is now offering free Trac/Subversion hosting.
This offer is limited to open-source, python projects.

Trac and Subversion make a great combination for project
management. More information about Trac can be found
here: http://www.edgewall.com/trac

The free offer includes:
     - Your own Trac site with HTTP and HTTPS access
     - Your own Subversion repository with HTTP and HTTPS access
     - Access to trac-admin through a web interface
     - Access to Trac and Subversion user configuration through a web interface
     - Web usage statistics of your Trac site
     - Nightly backups of your data to external servers

If you want to know more about this offer and find out how to sign up,
check out the following page: http://www.python-hosting.com/freetrac

Remi.


PS: Python-Hosting.com also offers commercial packages for Trac/Subversion 
hosting, which aren't limited to open source python projects and which include 
additional services such as your own domain name, e-mail/DNS/database hosting, 
shell access, more diskspace or bandwidth, ...

---------------------------------------------------------------------
To unsubscribe, e-mail: announce-unsubscribe at subversion.tigris.org
For additional commands, e-mail: announce-help at subversion.tigris.org


From justdave at bugzilla.org  Sat Jan 22 20:36:06 2005
From: justdave at bugzilla.org (David Miller)
Date: Sat, 22 Jan 2005 15:36:06 -0500
Subject: Release timing
In-Reply-To: <41F23564.9040303@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca> <41EEF622.9010406@bugzilla.org> <41F23564.9040303@mozilla.org>
Message-ID: <41F2B936.7080800@bugzilla.org>

Gervase Markham wrote:

> But perhaps things would be clearer if Dave said why it was he chose May 
> and November?

Because those are each two months out from the freeze dates we had 
already chosen.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From Nick.Barnes at pobox.com  Sat Jan 22 21:34:57 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Sat, 22 Jan 2005 21:34:57 +0000
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501201237340.7454@skippy.fini.net> 
   from Christopher Hicks <chicks@chicks.net> 
   of "Thu, 20 Jan 2005 12:52:26 -0500"
Message-ID: <28489.1106429697@thrush.ravenbrook.com>

At 2005-01-20 17:52:26+0000, Christopher Hicks writes:

> While I sympathise with Vlad and Gerv for their holiday push I
> suspect that most of humanity gets more work done during work months
> and less work done during holiday months.

Added to which:

      What's a holiday month?

Nick B


From Nick.Barnes at pobox.com  Sat Jan 22 22:14:22 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Sat, 22 Jan 2005 22:14:22 +0000
Subject: Custom fields schema
In-Reply-To: <41F15351.4020401@mozilla.org> 
   from Myk Melez <myk@mozilla.org> 
   of "Fri, 21 Jan 2005 11:09:05 -0800"
Message-ID: <30003.1106432062@thrush.ravenbrook.com>

At 2005-01-21 19:09:05+0000, Myk Melez writes:
>     Sean McAfee wrote:
> 
> >Do you have a specific proposal that can be tested?  And, er, I don't want
> >to sound rude, but would you mind testing it yourself?  I've already done
> >quite a lot in that area.
> 
> Ok, I modified construct-tables.pl to add fulltext indexes to the text 
> columns in the tests, create "real-distributed" columns (real columns, 
> but in a separate table rather than the bugs table, which is how a "real 
> columns" custom fields implementation would handle sparse columns), and 
> make distributed and real-distributed versions of the status whiteboard 
> field.

And I think you are both wrong!  As I said before, now is surely not
the time to be making performance measurements of prototype solutions
of the custom fields defect, given that any of the proposed solutions
are plausibly capable of acceptable performance.

First implement a solution.

Then fix the glaring bugs in it.

Then get it into the trunk.

Then deploy it on test sites such as b.m.o. and let people bang on it
with real data.

Then fix the other bugs in it.

*Then* fix any performance problems with it, if necessary by replacing
the database schema part of the overall custom fields solution.

Please.

"Premature optimization is the root of all evil in programming." -
C.A.R. Hoare.

Nick B


From vladd at bugzilla.org  Sat Jan 22 23:00:58 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Sun, 23 Jan 2005 01:00:58 +0200
Subject: Release timing
In-Reply-To: <28489.1106429697@thrush.ravenbrook.com>
References: <28489.1106429697@thrush.ravenbrook.com>
Message-ID: <41F2DB2A.8080602@bugzilla.org>


>>While I sympathise with Vlad and Gerv for their holiday push I
>>suspect that most of humanity gets more work done during work months
>>and less work done during holiday months.
>>    
>>
I agree with you if you're talking about paid work. I disagree with you 
if you're talking about unpaid work.

Like I said, Bugzilla has a mix of those two types.

Vlad.


From chicks at chicks.net  Sat Jan 22 23:33:57 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sat, 22 Jan 2005 18:33:57 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <30003.1106432062@thrush.ravenbrook.com>
References: <30003.1106432062@thrush.ravenbrook.com>
Message-ID: <Pine.LNX.4.61.0501221832270.7454@skippy.fini.net>

On Sat, 22 Jan 2005, Nick Barnes wrote:
> And I think you are both wrong!  As I said before, now is surely not
> the time to be making performance measurements of prototype solutions
> of the custom fields defect, given that any of the proposed solutions
> are plausibly capable of acceptable performance.

I agree wholeheartedly.

> "Premature optimization is the root of all evil in programming." -
> C.A.R. Hoare.

I was trying to be nice and not beat them with that well-worn stick, but 
this seems exactly like the case where he'd apply it.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From gerv at mozilla.org  Sun Jan 23 00:24:05 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 23 Jan 2005 00:24:05 +0000
Subject: Release timing
In-Reply-To: <41F2B936.7080800@bugzilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca> <41EEF622.9010406@bugzilla.org> <41F23564.9040303@mozilla.org> <41F2B936.7080800@bugzilla.org>
Message-ID: <41F2EEA5.7050203@mozilla.org>

David Miller wrote:
> Gervase Markham wrote:
> 
>> But perhaps things would be clearer if Dave said why it was he chose 
>> May and November?
> 
> Because those are each two months out from the freeze dates we had 
> already chosen.

Then the obvious follow-up question is: why did you choose March and 
September as the freeze dates?

Gerv


From stu at asyn.com  Sun Jan 23 04:53:31 2005
From: stu at asyn.com (Stuart Donaldson)
Date: Sat, 22 Jan 2005 20:53:31 -0800
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
Message-ID: <41F32DCB.8060505@asyn.com>

Christopher Hicks wrote:

> On Tue, 18 Jan 2005, Gervase Markham wrote:
>
>>
>> I'm suggesting that we revisit that logic. One can make an argument 
>> for "releases every X months", for most sane values of X, but I can't 
>> see an argument for "freezes every X months". How is the date of a 
>> freeze important? Surely it's the release date you are trying to hit 
>> that's the important thing.
>
>
> Having the freeze dates be something that people know from remember 
> when it happened last year seems more important than exactly when we 
> release to the world.  As long as there's been a release in the last 
> year the user is going to feel like we're making progress, but the 
> developers care about the exact freeze data because presumably they 
> have something that they want in before the freeze.
>
At the risk of being redundant, I will try to restate my earlier comment.

I believe it would be best if Bugzilla would Freeze X months after 
release.  This gives X months of active development, and allows for 
releases approximately every X+1 month.

You don't find yourself running up against a fixed release date, causing 
artificial pressure.  (If this were a company with all paid developers, 
rather than the large number of volunteers, the fixed release dates 
could work.  But figure out why you're doing it.)




From mkanat at kerio.com  Sun Jan 23 06:43:23 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Sat, 22 Jan 2005 22:43:23 -0800
Subject: Custom fields schema
In-Reply-To: <41F15E82.5060500@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
	 <41F15E82.5060500@mozilla.org>
Message-ID: <1106462603.11653.3.camel@max.localdomain>

On Fri, 2005-01-21 at 11:56 -0800, Myk Melez wrote:
> But preferences and custom fields are very different beasts. 

	True. 

	The reason for implementing preferences as rows is so that people can
write custom plugins for Bugzilla that can add new preferences.

	The same logic would apply to custom fields.

	-Max




From gerv at mozilla.org  Sun Jan 23 12:18:36 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 23 Jan 2005 12:18:36 +0000
Subject: Custom fields schema
In-Reply-To: <30003.1106432062@thrush.ravenbrook.com>
References: <30003.1106432062@thrush.ravenbrook.com>
Message-ID: <41F3961C.9010205@mozilla.org>

Nick Barnes wrote:
> First implement a solution.
> 
> Then fix the glaring bugs in it.
> 
> Then get it into the trunk.
> 
> Then deploy it on test sites such as b.m.o. and let people bang on it
> with real data.
> 
> Then fix the other bugs in it.
> 
> *Then* fix any performance problems with it, if necessary by replacing
> the database schema part of the overall custom fields solution.

But what happens at this stage, in the real world, is that no-one has 
time to rip out the schema and start again, and lots of people have made 
local modifications which would break anyway, and so we all grumble 
about how we should have got it right the first time, and live with the 
bad implementation.

While deciding on the correct approach should not delay the 
implementation of custom fields indefinitely, I think that doing some 
up-front design is a perfectly reasonable step on the way to implementation.

In the end, the choice of implementation method rests with Dave, as 
project leader. Dave - do you have enough data to make a choice yet?

Gerv


From gerv at mozilla.org  Sun Jan 23 12:48:34 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 23 Jan 2005 12:48:34 +0000
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
Message-ID: <41F39D22.3080200@mozilla.org>

Christopher Hicks wrote:
> It may not be the ideal thing, but it seems better than the 
> alternatives. Getting on a release rhythm may entail some occassional 
> irritation, but I do think its worth the trouble.

This comes back to the question we are discussing in the other thread - 
why have we picked a rhythm which requires this particular irritation, 
when it's not necessary to do so?

>>> Dave has indicated that the freezes will be timed, not the releases 
>>> so basing dates off of the release date does not fit with the logic 
>>> that Dave feels was agreed upon.
>>
>> I'm suggesting that we revisit that logic. One can make an argument 
>> for "releases every X months", for most sane values of X, but I can't 
>> see an argument for "freezes every X months". How is the date of a 
>> freeze important? Surely it's the release date you are trying to hit 
>> that's the important thing.
> 
> Having the freeze dates be something that people know from remember when 
> it happened last year seems more important than exactly when we release 
> to the world.

That's certainly unusual logic - in that I don't know of any other 
project which puts value on having _freezes_ at the same time each year.

> As long as there's been a release in the last year the 
> user is going to feel like we're making progress, but the developers 
> care about the exact freeze data because presumably they have something 
> that they want in before the freeze.

I completely agree that developers care about what the freeze date is, 
but I don't agree that they care that it's the same calendar date as the 
previous year.

> Instead of "er" you could say "Release X and X+3, and X+4 are supported, 
> please help us to minimize the hassle of voluntarily maintaining 
> bugzilla by using one of those.  Oh, by the way, X+3 is our next 
> long-term stable release, so you'll be able to get support for it for a 
> couple years."

As long as the long-term releases are centrally decided rather than at 
the whim of a "branch owner", that would be OK.

Perhaps we could number the releases in such a way to make it clear 
which were long term. E.g. 3.0 is long term, 3.2, 3.4 are not, 4.0 is 
long term, ...

Gerv


From chicks at chicks.net  Sun Jan 23 14:00:56 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sun, 23 Jan 2005 09:00:56 -0500 (EST)
Subject: Release timing
In-Reply-To: <41F39D22.3080200@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
 <41ED9F25.9080106@mozilla.org> <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
 <41F39D22.3080200@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net>

On Sun, 23 Jan 2005, Gervase Markham wrote:
> Christopher Hicks wrote:
>> It may not be the ideal thing, but it seems better than the alternatives. 
>> Getting on a release rhythm may entail some occassional irritation, but I 
>> do think its worth the trouble.
>
> This comes back to the question we are discussing in the other thread - why 
> have we picked a rhythm which requires this particular irritation, when it's 
> not necessary to do so?

Given how long 2.18 took to get out going to fixed freeze dates seems like 
a good idea to me.

>> Having the freeze dates be something that people know from remember when it 
>> happened last year seems more important than exactly when we release to the 
>> world.
>
> That's certainly unusual logic - in that I don't know of any other project 
> which puts value on having _freezes_ at the same time each year.

You're right, lets follow the crowd and do what everybody else is doing. 
I'll start boning up on PHP now.

>> As long as there's been a release in the last year the user is going to 
>> feel like we're making progress, but the developers care about the exact 
>> freeze data because presumably they have something that they want in before 
>> the freeze.
>
> I completely agree that developers care about what the freeze date is, 
> but I don't agree that they care that it's the same calendar date as the 
> previous year.

The developers need not care if its the same calendar date, but they will 
find it easier to hold in their head if it is.  You seem to agree that the 
developers care more about the freeze date than the users care about the 
release date.  So, then why not make the freeze dates easy to remember?

>> Instead of "er" you could say "Release X and X+3, and X+4 are supported, 
>> please help us to minimize the hassle of voluntarily maintaining bugzilla 
>> by using one of those.  Oh, by the way, X+3 is our next long-term stable 
>> release, so you'll be able to get support for it for a couple years."
>
> As long as the long-term releases are centrally decided rather than at the 
> whim of a "branch owner", that would be OK.

A maintenance branch owner would be told whether they had a short-lived 
branch or a long-lived branch on their hands when they took it.

> Perhaps we could number the releases in such a way to make it clear which 
> were long term. E.g. 3.0 is long term, 3.2, 3.4 are not, 4.0 is long term, 
> ...

That would lead to every othe release being a long term release and I 
don't think that would be good given that part of the goal was to limit 
the number of currently long term releases.  On the other hand it would be 
cool if the "summer" bugzilla releases were the long lived ones and the 
"winter" releases were the short lived ones.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From luis.villa at gmail.com  Sun Jan 23 14:08:51 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Sun, 23 Jan 2005 09:08:51 -0500
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com>
	 <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>
	 <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
	 <41ED9F25.9080106@mozilla.org>
	 <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
	 <41F39D22.3080200@mozilla.org>
	 <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net>
Message-ID: <2cb10c4405012306085b20a0ed@mail.gmail.com>

On Sun, 23 Jan 2005 09:00:56 -0500 (EST), Christopher Hicks 
> >> Having the freeze dates be something that people know from remember when it
> >> happened last year seems more important than exactly when we release to the
> >> world.
> >
> > That's certainly unusual logic - in that I don't know of any other project
> > which puts value on having _freezes_ at the same time each year.

Just for the record, at GNOME we've found good freeze dates are the
most important part of actually getting the release out on time. You
can say 'we'll release every six months', but if you don't freeze
appropriately, you'll never release on time.

[And yes, we've shifted our freeze dates to work around holidays; as a
heavily volunteer project we like our feature freeze to fall right
after holidays so people playing around for fun can get some hacking
time in over school breaks, work breaks, etc. I'm not sure if that is
appropriate for bugzilla or not, just an observation.]

Luis


From chicks at chicks.net  Sun Jan 23 14:09:09 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sun, 23 Jan 2005 09:09:09 -0500 (EST)
Subject: Release timing
In-Reply-To: <41F32DCB.8060505@asyn.com>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
 <41ED9F25.9080106@mozilla.org> <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
 <41F32DCB.8060505@asyn.com>
Message-ID: <Pine.LNX.4.61.0501230908390.7454@skippy.fini.net>

On Sat, 22 Jan 2005, Stuart Donaldson wrote:

> You don't find yourself running up against a fixed release date, causing 
> artificial pressure.  (If this were a company with all paid developers, 
> rather than the large number of volunteers, the fixed release dates 
> could work.  But figure out why you're doing it.)

Given the history of the project as I've seen it I think having some 
artificial pressure might be beneficial.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From chicks at chicks.net  Sun Jan 23 14:13:13 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sun, 23 Jan 2005 09:13:13 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41F3961C.9010205@mozilla.org>
References: <30003.1106432062@thrush.ravenbrook.com> <41F3961C.9010205@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501230909580.7454@skippy.fini.net>

On Sun, 23 Jan 2005, Gervase Markham wrote:
> But what happens at this stage, in the real world, is that no-one has time to 
> rip out the schema and start again, and lots of people have made local 
> modifications which would break anyway, and so we all grumble about how we 
> should have got it right the first time, and live with the bad 
> implementation.

Look at all of the database tweaks in checksetup.pl and tell me we're 
prone to just live with it and not tweak it into shape over time.

> While deciding on the correct approach should not delay the 
> implementation of custom fields indefinitely, I think that doing some 
> up-front design is a perfectly reasonable step on the way to 
> implementation.

The design has been out there for ages and now people are just ripping 
apart one section - the database design's affect on performance - which 
was actually done correctly already.  If there's some other "up-front 
design" that's needed, what is it?

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From luis.villa at gmail.com  Sun Jan 23 14:21:22 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Sun, 23 Jan 2005 09:21:22 -0500
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501230908390.7454@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com>
	 <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>
	 <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
	 <41ED9F25.9080106@mozilla.org>
	 <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
	 <41F32DCB.8060505@asyn.com>
	 <Pine.LNX.4.61.0501230908390.7454@skippy.fini.net>
Message-ID: <2cb10c4405012306216fcb6b00@mail.gmail.com>

On Sun, 23 Jan 2005 09:09:09 -0500 (EST), Christopher Hicks
<chicks at chicks.net> wrote:
> On Sat, 22 Jan 2005, Stuart Donaldson wrote:
> 
> > You don't find yourself running up against a fixed release date, causing
> > artificial pressure.  (If this were a company with all paid developers,
> > rather than the large number of volunteers, the fixed release dates
> > could work.  But figure out why you're doing it.)
> 
> Given the history of the project as I've seen it I think having some
> artificial pressure might be beneficial.

We've also found (in GNOME) that while the artificial pressure is not
always ideal for volunteers, it does have the plus of focusing people
on our version of reviews regularly, and it means new contributors get
their patches out to the 'real world' very quickly. If I'd contributed
something at the beginning of the 2.18 cycle, and then seen it take 2+
years for that contribution to get out to the world, that would be
discouraging. And in a corporate world, it is quite irritating- if I
convince my boss to let me contribute to bugzilla because it'll help
reduce maintenance costs, and then it is years before my contribution
actually makes it into a release and helps the company, then I'm going
to have problems justifying that in the future. Regular, fast releases
on a pre-determined schedule mean contributors see results quickly,
which is a big plus.

Luis

Luis


From gerv at mozilla.org  Sun Jan 23 17:04:13 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 23 Jan 2005 17:04:13 +0000
Subject: Release timing
In-Reply-To: <2cb10c4405012306085b20a0ed@mail.gmail.com>
References: <79808.1105621455@thrush.ravenbrook.com>	 <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>	 <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>	 <41ED9F25.9080106@mozilla.org>	 <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>	 <41F39D22.3080200@mozilla.org>	 <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net> <2cb10c4405012306085b20a0ed@mail.gmail.com>
Message-ID: <41F3D90D.5010903@mozilla.org>

Luis Villa wrote:
> Just for the record, at GNOME we've found good freeze dates are the
> most important part of actually getting the release out on time. You
> can say 'we'll release every six months', but if you don't freeze
> appropriately, you'll never release on time.

Absolutely. But, as you say, there's not much value put (in the GNOME 
project) on having freezes at the same time every calendar year. You do 
whatever's good for the people you have at the time.

People seem to be persistently misunderstanding me ;-) I'm not arguing 
for no freeze dates, or vague freeze dates. I'm not arguing that we 
shouldn't have a schedule, or we should release "when we feel like it". 
I'm not saying we shouldn't have a roadmap, or the next release 
shouldn't have a target release date.

I'm just saying there's no value in saying e.g. "our freeze is going to 
be in October every year". If you, for whatever reason, took a long time 
to make the previous release and it's now late August, freezing in 
October "because that's what we said we would do 9 months ago" seems silly.

We should aim to make releases every X months (where people seem to 
think X is 6). But if a release takes 8 months because people are busy, 
or it takes a long time to stabilise, or for whatever reason, the next 
release should be six months beyond that one, not four.

Gerv


From bugreport at peshkin.net  Sun Jan 23 18:00:29 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Sun, 23 Jan 2005 10:00:29 -0800
Subject: Release timing
In-Reply-To: <41F3D90D.5010903@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com>	 <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>	 <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>	 <41ED9F25.9080106@mozilla.org>	 <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>	 <41F39D22.3080200@mozilla.org>	 <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net> <2cb10c4405012306085b20a0ed@mail.gmail.com> <41F3D90D.5010903@mozilla.org>
Message-ID: <41F3E63D.1020401@peshkin.net>

Gervase Markham wrote:

>
> People seem to be persistently misunderstanding me ;-)

Must be that funny language varient you use :-)

>
> We should aim to make releases every X months (where people seem to 
> think X is 6). But if a release takes 8 months because people are 
> busy, or it takes a long time to stabilise, or for whatever reason, 
> the next release should be six months beyond that one, not four.

Right.  That is really the key.  If we take forever to stabilize a 
release, we should not be starting the next branch immediately on its 
heels.  Either we should lengthen the time between freezes so that we 
know we will have enough time or we should make it capable of varying so 
that we never start a new branch until we have stabilized the previous 
one.  If we believe that the 2.18 situation is a one-time situation, 
then we should make it capable of varying and expect to do so only rarely.



From altlst at sonic.net  Mon Jan 24 01:43:47 2005
From: altlst at sonic.net (Albert Ting)
Date: Sun, 23 Jan 2005 17:43:47 -0800
Subject: Release timing
In-Reply-To: <2cb10c4405012306216fcb6b00@mail.gmail.com>
References: <79808.1105621455@thrush.ravenbrook.com>
	<41ECC7DB.4060307@bugzilla.org>
	<41ECF506.7030505@mozilla.org>
	<Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
	<41ED9F25.9080106@mozilla.org>
	<Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
	<41F32DCB.8060505@asyn.com>
	<Pine.LNX.4.61.0501230908390.7454@skippy.fini.net>
	<2cb10c4405012306216fcb6b00@mail.gmail.com>
Message-ID: <16884.21203.938293.731920@gargle.gargle.HOWL>


Luis Villa <luis.villa at gmail.com> writes:
> if I convince my boss to let me contribute to bugzilla because it'll help
> reduce maintenance costs, and then it is years before my contribution
> actually makes it into a release and helps the company, then I'm going to
> have problems justifying that in the future. Regular, fast releases on a
> pre-determined schedule mean contributors see results quickly, which is a
> big plus.

I'd like to also add fast reviews/critiques goes a long way.  

My company and I had a vested interest in getting some of my larger patches
merged into the bugzilla releases.  Lower maintenance, etc.  

If it wasn't for Joel putting the effort to quickly review/critique my
patches and convince the other reviewers to participate, I'd probably would
have stayed with my custom 2.18, maybe even look at commercial versions.  I
had to put more time to update the patches for the newer stream, 2.19+,
especially the edit*.cgi coding changes.

As a side note, how do people maintain their bugzilla contributions?  It's
not easy given there is such a long lead time in getting contributions
approved.  This is especially true if you're also using other people's
patches.  At the moment, I automatically build my custom bugzilla directory
based on a cvs snapshot and all custom patches.  But it's not perfect.


From chicks at chicks.net  Mon Jan 24 15:27:25 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Mon, 24 Jan 2005 10:27:25 -0500 (EST)
Subject: Release timing
In-Reply-To: <41F3D90D.5010903@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com>  <41ECC7DB.4060307@bugzilla.org>
 <41ECF506.7030505@mozilla.org>  <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>
  <41ED9F25.9080106@mozilla.org>  <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>
  <41F39D22.3080200@mozilla.org>  <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net>
 <2cb10c4405012306085b20a0ed@mail.gmail.com> <41F3D90D.5010903@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501241002280.7454@skippy.fini.net>

On Sun, 23 Jan 2005, Gervase Markham wrote:
> People seem to be persistently misunderstanding me ;-)

Disagreement does not necessarily imply misunderstanding.

> I'm not arguing for no freeze dates, or vague freeze dates. I'm not 
> arguing that we shouldn't have a schedule, or we should release "when we 
> feel like it". I'm not saying we shouldn't have a roadmap, or the next 
> release shouldn't have a target release date.

Good.

> I'm just saying there's no value in saying e.g. "our freeze is going to 
> be in October every year". If you, for whatever reason, took a long time 
> to make the previous release and it's now late August, freezing in 
> October "because that's what we said we would do 9 months ago" seems 
> silly.

But its not silly and lucid arguments have been provided by myself and 
others as to why this is this case.  Maybe you're the one persistently 
misunderstanding?

> We should aim to make releases every X months (where people seem to 
> think X is 6). But if a release takes 8 months because people are busy, 
> or it takes a long time to stabilise, or for whatever reason, the next 
> release should be six months beyond that one, not four.

If it takes a long time to stabilize in one round developers will try 
harder the next time to stabilize things faster.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From kevin.benton at amd.com  Mon Jan 24 16:19:54 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Mon, 24 Jan 2005 09:19:54 -0700
Subject: WOOHOO!  MySQL 4.x is going to be shipped with FC4!
Message-ID: <20050124161954.18AB61FBD@ldcmail.amd.com>

Just a quick FYI all :-)

 

---

Kevin Benton

Perl/Bugzilla Developer

Advanced Micro Devices

 

The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050124/b3d44943/attachment.html>

From justdave at bugzilla.org  Mon Jan 24 16:20:22 2005
From: justdave at bugzilla.org (David Miller)
Date: Mon, 24 Jan 2005 11:20:22 -0500
Subject: Release timing
In-Reply-To: <41F2EEA5.7050203@mozilla.org>
References: <79808.1105621455@thrush.ravenbrook.com> <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org> <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net> <41ED9F25.9080106@mozilla.org> <41EDCE24.40609@bugzilla.org> <41EEE084.7080604@mozilla.org> <Pine.GHP.4.58.0501191629230.24446@milhouse.SEDSystems.ca> <41EEF622.9010406@bugzilla.org> <41F23564.9040303@mozilla.org> <41F2B936.7080800@bugzilla.org> <41F2EEA5.7050203@mozilla.org>
Message-ID: <41F52046.40609@bugzilla.org>

Gervase Markham wrote:
> David Miller wrote:
>> Gervase Markham wrote:
>>
>>> But perhaps things would be clearer if Dave said why it was he chose 
>>> May and November?
>>
>> Because those are each two months out from the freeze dates we had 
>> already chosen.
> 
> Then the obvious follow-up question is: why did you choose March and 
> September as the freeze dates?

September was chosen because it was 6 months out from March.  March was 
chosen because it was a reasonable amount of time (or so we thought) to 
attempt to get stabilized from when we made the decision to switch to 
time-based releases.  If you're asking why we didn't change that date 
when we decided to push 2.20 back, then I'll note that the amount of 
time between now and the newly proposed 2.20 freeze date is also the 
same as the amount of time between the initial decision being made and 
the originally proposed 2.18 freeze date, difference being, we actually 
stand a chance of making it this time.  (That and we've already 
advertised March and September for freeze dates for quite a while now, 
and other than the "we need to make it more than 4 months between 2.18 
and 2.20" argument, I haven't seen any good reason why we *should* move 
it later.  The fact that we've already been advertising that date is to 
me a compelling reason to stick with it, despite the short inter-release 
delay, especially when we're confident we can make it this time.

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From gerv at mozilla.org  Mon Jan 24 22:53:31 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 24 Jan 2005 22:53:31 +0000
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.61.0501230909580.7454@skippy.fini.net>
References: <30003.1106432062@thrush.ravenbrook.com> <41F3961C.9010205@mozilla.org> <Pine.LNX.4.61.0501230909580.7454@skippy.fini.net>
Message-ID: <41F57C6B.40907@mozilla.org>

Christopher Hicks wrote:
> Look at all of the database tweaks in checksetup.pl and tell me we're 
> prone to just live with it and not tweak it into shape over time.

But the schema for custom fields is going to be a whole different order 
of complexity. Switching between the two main proposals here isn't a 
case of "drop this column, tweak the type of this table", it's a 
wholesale internal rearrangement.

> The design has been out there for ages and now people are just ripping 
> apart one section - the database design's affect on performance - which 
> was actually done correctly already.  If there's some other "up-front 
> design" that's needed, what is it?

Maybe I haven't been paying attention; I've seen several designs flow 
past, but I didn't realise one of them had been accepted as "the design".

Gerv


From myk at mozilla.org  Tue Jan 25 00:23:59 2005
From: myk at mozilla.org (Myk Melez)
Date: Mon, 24 Jan 2005 16:23:59 -0800
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
References: <20041224081704.cd36e999@mail.kerio.com> <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> <41F15E82.5060500@mozilla.org> <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
Message-ID: <41F5919F.4030906@mozilla.org>

Christopher Hicks wrote:

> Bah.  Your conclusion of what's necessary here seems to be based on a 
> very selective view of the universe.  Several "necessities" stick out 
> when considering a custom fields implemention based on abstraction at 
> the database level:
>
> (1) People can add as many custom fields as they want without worrying 
> about reaching the maximum record size of their database

Under my fields-as-columns (FAC) proposal, fields can live in their own 
tables, and there is no limit to the number of tables per database in 
MySQL, so this isn't an issue between my proposal and Sean's 
fields-as-data (FAD) proposal.

> (2) Code for dealing with custom fields is going to need to have a 
> goodly portion of the abstraction tables for keeping track of stuff 
> anyways.

I'm not sure what you mean by abstraction tables, but both proposals 
will require some meta-data about fields to be stored in fielddefs, just 
as we already do for standard fields, and will store lists of possible 
values for some fields in separate tables, just as we already do for 
standard fields like component and should be doing for fields like op_sys.

That doesn't mean we should store all meta-data as data.  We should use 
the right tool for the job, as we have already done with standard 
fields, for which we rightly use columns.

> (3) Since queries that involve custom fields will now have to be 
> written on the fly they are less able to be optimized by using a 
> database that can deal with prepare() usefully.

How does FAC require queries to be written "on the fly" in a less 
optimizable way, reducing performance on prepare()-happy databases?  Can 
you demonstrate this?

> (4) Since queries involving custom fields are going to take a few 
> database hits to figure out what the field names so the query could be 
> written you end up with cases where 1 query turns into 4 queries.  If 
> the database is across a WAN from the bugzilla instance the effect of 
> multiple queries where there were one will be more noticable.

Sure, more queries is slower.  But FAC would use less queries overall, 
and simpler ones at that.

Consider a simple query on a single custom field "foo" where the user 
wants bugs where foo=bar.  With FAC, we search for bugs where the "foo" 
column contains "bar".  With FAD, we look up the field ID for "foo" and 
then search for bugs where the "field_id" column contains that ID and 
the "value" column contains "bar" (or do it in one query with a join).

Even in the worst case, when you couldn't infer the column name from the 
form field name, FAC lookups would only be equal to, not worse than, FAD 
lookups.  And if these lookups mattered (which Sean claims they don't), 
the list of custom fields and associated identifiers would get cached 
under either proposal the same way we cache components and versions.

> (5) Custom fields should be able to be implemented without the 
> bugzilla user having database privs to alter tables.

FAD is even more insecure in this regard, since a compromised Bugzilla 
user account that wasn't allowed to alter tables would still be able to 
alter custom fields under that proposal (unless we implemented 
table/column-specific privileges for that account, which would be more 
work and complexity--and thus risk).

Nevertheless, note that the Bugzilla user account already has such 
privileges today (checksetup.pl uses them to set up and update the 
database schema), and even if we took them away, the Bugzilla 
administrators, to whom we will entrust the creation of custom fields, 
will certainly retain those privileges via a separate account.

> Myk - it sounds like you're basing the decision on what way to go here 
> totally based on performance and I think there's a lot more that 
> should go into this decision.

To the contrary, my proposal is based on much more than performance.  My 
previous email was about performance only because that was Sean's 
primary argument against it (he thought my proposal would be slower and 
offered data to support his conclusion--I ran his tests myself and found 
the opposite was true).

I think we should use real columns for custom fields because:

   1. that's what they're there for;

      Custom fields are no different from standard fields in how they're
      used (queried, displayed, updated, etc.), and columns were
      designed for this express purpose when database systems were
      developed.  Given that they've been used to represent "fields" of
      all kinds for decades, and that we've used them in Bugzilla to
      represent the standard fields for over five years, they're a
      mature and proven technology for doing what we want and likely to
      be better than any new mechanism we come up with which represents
      fields as data.

   2. then they work the same as standard fields;

      Custom fields and standard fields are both used (queried,
      displayed, updated) in much the same way, and using the same
      technology to store them means we can use the same code in many
      cases (and the same kind of code in others) to access and
      manipulate them, making the source simpler, more robust, and
      easier to develop.

   3. it makes them significantly faster;

      Per my tests and standard database design theory, real columns are
      much faster than data columns.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050124/c8f80577/attachment.html>

From gerv at mozilla.org  Mon Jan 24 22:46:37 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Mon, 24 Jan 2005 22:46:37 +0000
Subject: Release timing
In-Reply-To: <Pine.LNX.4.61.0501241002280.7454@skippy.fini.net>
References: <79808.1105621455@thrush.ravenbrook.com>  <41ECC7DB.4060307@bugzilla.org> <41ECF506.7030505@mozilla.org>  <Pine.LNX.4.61.0501181506100.27237@skippy.fini.net>  <41ED9F25.9080106@mozilla.org>  <Pine.LNX.4.61.0501221108230.7454@skippy.fini.net>  <41F39D22.3080200@mozilla.org>  <Pine.LNX.4.61.0501230851350.7454@skippy.fini.net> <2cb10c4405012306085b20a0ed@mail.gmail.com> <41F3D90D.5010903@mozilla.org> <Pine.LNX.4.61.0501241002280.7454@skippy.fini.net>
Message-ID: <41F57ACD.60309@mozilla.org>

Christopher Hicks wrote:
> On Sun, 23 Jan 2005, Gervase Markham wrote:
> 
>> People seem to be persistently misunderstanding me ;-)
> 
> Disagreement does not necessarily imply misunderstanding.

Indeed not. But people do seem to be replying to my messages countering 
"arguments" I never actually made...

>> We should aim to make releases every X months (where people seem to 
>> think X is 6). But if a release takes 8 months because people are 
>> busy, or it takes a long time to stabilise, or for whatever reason, 
>> the next release should be six months beyond that one, not four.
> 
> If it takes a long time to stabilize in one round developers will try 
> harder the next time to stabilize things faster.

Hmm. That approach worked really well for 2.18, didn't it?

- "It's taking us ages to stabilise!"
- "Well, try harder then!"

Still, it seems I can't talk you guys out of this, so I'll just complete 
my Cassandra act by warning that it'll all end in tears, and leave it at 
that.

Gerv


From bugzilla at glob.com.au  Tue Jan 25 04:41:31 2005
From: bugzilla at glob.com.au (byron)
Date: Tue, 25 Jan 2005 12:41:31 +0800 (WST)
Subject: update to the default bugzilla css
Message-ID: <20050125044131.43CD84BCC8E@stutter.bur.st>

ok, these are probably "fighting words" however..

i'm sure we'll all agree that the default bugzilla look requires updating. 


with that in mind i've made a small number of css-only changes that draw the
look from the bugzilla web site, currently implmented as a custom skin against
head.

you can see it at
  http://landfill.bugzilla.org/newui/

as a comparison, the current css is at
  http://landfill.bugzilla.org/bugzilla-tip/


i think it looks pretty, and i'm wondering if it's worth pushing for it to be
taken up as the default style until the ui overhaul is closer to ready.


in short: what do you think?



-b

begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From luis.villa at gmail.com  Tue Jan 25 04:51:59 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Mon, 24 Jan 2005 23:51:59 -0500
Subject: update to the default bugzilla css
In-Reply-To: <20050125044131.43CD84BCC8E@stutter.bur.st>
References: <20050125044131.43CD84BCC8E@stutter.bur.st>
Message-ID: <2cb10c4405012420514231d503@mail.gmail.com>

I like it. Looks like a nice, small step to get the look and feel out
of the stone ages for 2.20 (which I assume will not have the ui revamp
landed.)

Luis


On Tue, 25 Jan 2005 12:41:31 +0800 (WST), byron <bugzilla at glob.com.au> wrote:
> ok, these are probably "fighting words" however..
> 
> i'm sure we'll all agree that the default bugzilla look requires updating.
> 
> with that in mind i've made a small number of css-only changes that draw the
> look from the bugzilla web site, currently implmented as a custom skin against
> head.
> 
> you can see it at
>   http://landfill.bugzilla.org/newui/
> 
> as a comparison, the current css is at
>   http://landfill.bugzilla.org/bugzilla-tip/
> 
> i think it looks pretty, and i'm wondering if it's worth pushing for it to be
> taken up as the default style until the ui overhaul is closer to ready.
> 
> in short: what do you think?
> 
> -b
> 
> begin-base64 644 signature.gif
> R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
> XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
> h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
> N1PRMXimiLUGt3ElVimlgbllWAAAOw==
> ====
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=luis.villa at gmail.com>
>


From jth at mikrobitti.fi  Tue Jan 25 05:25:40 2005
From: jth at mikrobitti.fi (Jouni Heikniemi)
Date: Tue, 25 Jan 2005 07:25:40 +0200 (EET)
Subject: update to the default bugzilla css
In-Reply-To: <20050125044131.43CD84BCC8E@stutter.bur.st>
References: <20050125044131.43CD84BCC8E@stutter.bur.st>
Message-ID: <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi>


On Tue, 25 Jan 2005, byron wrote:

> in short: what do you think?

I agree with Luis: An excellent baby step.


Jouni



From vladd at bugzilla.org  Tue Jan 25 05:28:39 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 25 Jan 2005 07:28:39 +0200
Subject: Custom fields schema
In-Reply-To: <41F5919F.4030906@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> <41F15E82.5060500@mozilla.org> <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net> <41F5919F.4030906@mozilla.org>
Message-ID: <41F5D907.4050406@bugzilla.org>

I agree with Myk. The FAC proposal makes more sense for me, from all 
points of view.

Vlad.

Myk Melez wrote:

> Christopher Hicks wrote:
>
>> Bah.  Your conclusion of what's necessary here seems to be based on a 
>> very selective view of the universe.  Several "necessities" stick out 
>> when considering a custom fields implemention based on abstraction at 
>> the database level:
>>
>> (1) People can add as many custom fields as they want without 
>> worrying about reaching the maximum record size of their database
>
> Under my fields-as-columns (FAC) proposal, fields can live in their 
> own tables, and there is no limit to the number of tables per database 
> in MySQL, so this isn't an issue between my proposal and Sean's 
> fields-as-data (FAD) proposal.
>
>> (2) Code for dealing with custom fields is going to need to have a 
>> goodly portion of the abstraction tables for keeping track of stuff 
>> anyways.
>
> I'm not sure what you mean by abstraction tables, but both proposals 
> will require some meta-data about fields to be stored in fielddefs, 
> just as we already do for standard fields, and will store lists of 
> possible values for some fields in separate tables, just as we already 
> do for standard fields like component and should be doing for fields 
> like op_sys.
>
> That doesn't mean we should store all meta-data as data.  We should 
> use the right tool for the job, as we have already done with standard 
> fields, for which we rightly use columns.
>
>> (3) Since queries that involve custom fields will now have to be 
>> written on the fly they are less able to be optimized by using a 
>> database that can deal with prepare() usefully.
>
> How does FAC require queries to be written "on the fly" in a less 
> optimizable way, reducing performance on prepare()-happy databases?  
> Can you demonstrate this?
>
>> (4) Since queries involving custom fields are going to take a few 
>> database hits to figure out what the field names so the query could 
>> be written you end up with cases where 1 query turns into 4 queries.  
>> If the database is across a WAN from the bugzilla instance the effect 
>> of multiple queries where there were one will be more noticable.
>
> Sure, more queries is slower.  But FAC would use less queries overall, 
> and simpler ones at that.
>
> Consider a simple query on a single custom field "foo" where the user 
> wants bugs where foo=bar.  With FAC, we search for bugs where the 
> "foo" column contains "bar".  With FAD, we look up the field ID for 
> "foo" and then search for bugs where the "field_id" column contains 
> that ID and the "value" column contains "bar" (or do it in one query 
> with a join).
>
> Even in the worst case, when you couldn't infer the column name from 
> the form field name, FAC lookups would only be equal to, not worse 
> than, FAD lookups.  And if these lookups mattered (which Sean claims 
> they don't), the list of custom fields and associated identifiers 
> would get cached under either proposal the same way we cache 
> components and versions.
>
>> (5) Custom fields should be able to be implemented without the 
>> bugzilla user having database privs to alter tables.
>
> FAD is even more insecure in this regard, since a compromised Bugzilla 
> user account that wasn't allowed to alter tables would still be able 
> to alter custom fields under that proposal (unless we implemented 
> table/column-specific privileges for that account, which would be more 
> work and complexity--and thus risk).
>
> Nevertheless, note that the Bugzilla user account already has such 
> privileges today (checksetup.pl uses them to set up and update the 
> database schema), and even if we took them away, the Bugzilla 
> administrators, to whom we will entrust the creation of custom fields, 
> will certainly retain those privileges via a separate account.
>
>> Myk - it sounds like you're basing the decision on what way to go 
>> here totally based on performance and I think there's a lot more that 
>> should go into this decision.
>
> To the contrary, my proposal is based on much more than performance.  
> My previous email was about performance only because that was Sean's 
> primary argument against it (he thought my proposal would be slower 
> and offered data to support his conclusion--I ran his tests myself and 
> found the opposite was true).
>
> I think we should use real columns for custom fields because:
>
>    1. that's what they're there for;
>
>       Custom fields are no different from standard fields in how
>       they're used (queried, displayed, updated, etc.), and columns
>       were designed for this express purpose when database systems
>       were developed.  Given that they've been used to represent
>       "fields" of all kinds for decades, and that we've used them in
>       Bugzilla to represent the standard fields for over five years,
>       they're a mature and proven technology for doing what we want
>       and likely to be better than any new mechanism we come up with
>       which represents fields as data.
>
>    2. then they work the same as standard fields;
>
>       Custom fields and standard fields are both used (queried,
>       displayed, updated) in much the same way, and using the same
>       technology to store them means we can use the same code in many
>       cases (and the same kind of code in others) to access and
>       manipulate them, making the source simpler, more robust, and
>       easier to develop.
>
>    3. it makes them significantly faster;
>
>       Per my tests and standard database design theory, real columns
>       are much faster than data columns.
>
> -myk
>



From vladd at bugzilla.org  Tue Jan 25 05:31:27 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 25 Jan 2005 07:31:27 +0200
Subject: update to the default bugzilla css
In-Reply-To: <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi>
References: <20050125044131.43CD84BCC8E@stutter.bur.st> <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi>
Message-ID: <41F5D9AF.6040904@bugzilla.org>

The default font size looks smaller compared to the actual font size. I 
actually have to get closer to the monitor to be able to feel 
comfortable with it (probably due to my 1280x1024 resolution, but still...)

Also, I'm a bit icky regarding the use of the bugzilla.org header at 
every b.m.o. installation as a default. I thought about our "mascot" to 
be more specific to bugzilla.org rather than every b.m.o. installation.

Vlad.

Jouni Heikniemi wrote:

>On Tue, 25 Jan 2005, byron wrote:
>
>  
>
>>in short: what do you think?
>>    
>>
>
>I agree with Luis: An excellent baby step.
>
>
>Jouni
>
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>
>  
>



From justdave at bugzilla.org  Tue Jan 25 06:00:20 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 25 Jan 2005 01:00:20 -0500
Subject: update to the default bugzilla css
In-Reply-To: <41F5D9AF.6040904@bugzilla.org>
References: <20050125044131.43CD84BCC8E@stutter.bur.st> <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi> <41F5D9AF.6040904@bugzilla.org>
Message-ID: <41F5E074.6030104@bugzilla.org>

Vlad Dascalu wrote:
> The default font size looks smaller compared to the actual font size. I 
> actually have to get closer to the monitor to be able to feel 
> comfortable with it (probably due to my 1280x1024 resolution, but still...)

Interesting.  The fonts look larger to me with the new css.  This is an 
artifact of the sans-serif fonts I'm sure...  the OS X version of 
Firefox defaults to 16pt for sans-serif.

> Also, I'm a bit icky regarding the use of the bugzilla.org header at 
> every b.m.o. installation as a default. I thought about our "mascot" to 
> be more specific to bugzilla.org rather than every b.m.o. installation.

As much as I hate to throw a wet-blanket on things, he's right, and for 
legal reasons, not just "trying to keep our identity".

http://www.mozilla.org/foundation/licensing/website-markup.html

That said, I'd love to swipe that css file for bugzilla.mozilla.org :) 
(which would be a very appropriate place for it)

If it's at all possible to tweak that enough to get past the website 
markup licensing restrictions and still have it looking pretty, it'd 
still be a good thing to do. :)

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From travis at SEDSystems.ca  Tue Jan 25 05:52:30 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Mon, 24 Jan 2005 23:52:30 -0600 (CST)
Subject: update to the default bugzilla css
In-Reply-To: <41F5E074.6030104@bugzilla.org>
References: <20050125044131.43CD84BCC8E@stutter.bur.st>
 <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi> <41F5D9AF.6040904@bugzilla.org>
 <41F5E074.6030104@bugzilla.org>
Message-ID: <Pine.GHP.4.58.0501242348420.14471@milhouse.SEDSystems.ca>



On Tue, 25 Jan 2005, David Miller wrote:

> That said, I'd love to swipe that css file for bugzilla.mozilla.org :)
> (which would be a very appropriate place for it)

I like the look too -- quite a bit, actually.

Having said that, MHO is that it wouldn't necessarily be a good thing for
bmo to look different (especially *that* different) than a default Bugzilla
install, simply because bmo is what most people expect Bugzilla to look
like.

Dollars to doughnuts people would be making up their own css files so that
their site could look like bmo's ... which would then become a significant
Trademark hassle.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From bugzilla at glob.com.au  Tue Jan 25 06:19:00 2005
From: bugzilla at glob.com.au (byron)
Date: Tue, 25 Jan 2005 14:19:00 +0800 (WST)
Subject: update to the default bugzilla css
Message-ID: <20050125061900.56B224BD5A6@stutter.bur.st>

> > The default font size looks smaller compared to the actual font size.
> 
> Interesting.  The fonts look larger to me with the new css.  This is an 
> artifact of the sans-serif fonts I'm sure...  the OS X version of 
> Firefox defaults to 16pt for sans-serif.

it used to be hard coded at 12px.

i've just changed the css for font-size to 90% instead.

> > Also, I'm a bit icky regarding the use of the bugzilla.org header at 
> > every b.m.o. installation as a default.
> 
> As much as I hate to throw a wet-blanket on things, he's right, and for 
> legal reasons, not just "trying to keep our identity".
> 
> http://www.mozilla.org/foundation/licensing/website-markup.html

but it's not for a website, it's for a mozilla product.  i'd expect some sort
of mozilla related branding in mozilla's products.

> If it's at all possible to tweak that enough to get past the website 
> markup licensing restrictions and still have it looking pretty, it'd 
> still be a good thing to do. :)

yeah, if required that should be possible.

i'm not actually using any bugzilla.org markup, just a few images and colours.

> That said, I'd love to swipe that css file for bugzilla.mozilla.org :) 
> (which would be a very appropriate place for it)

that would rock :)



begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From gerv at mozilla.org  Tue Jan 25 08:47:26 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 25 Jan 2005 08:47:26 +0000
Subject: update to the default bugzilla css
In-Reply-To: <41F5E074.6030104@bugzilla.org>
References: <20050125044131.43CD84BCC8E@stutter.bur.st> <Pine.LNX.4.58.0501250725190.7791@mikrobitti.fi> <41F5D9AF.6040904@bugzilla.org> <41F5E074.6030104@bugzilla.org>
Message-ID: <41F6079E.90709@mozilla.org>

David Miller wrote:
> As much as I hate to throw a wet-blanket on things, he's right, and for 
> legal reasons, not just "trying to keep our identity".
> 
> http://www.mozilla.org/foundation/licensing/website-markup.html
> 
> That said, I'd love to swipe that css file for bugzilla.mozilla.org :) 
> (which would be a very appropriate place for it)
> 
> If it's at all possible to tweak that enough to get past the website 
> markup licensing restrictions and still have it looking pretty, it'd 
> still be a good thing to do. :)

I put that document on the web, and I'm quite happy to make an exception 
for Bugzilla :-) There's no problem with it looking like mozilla.org.

I do agree with the point about the bug, though. b.m.o. should have the 
bug icon, but we should ship with something a bit more generic. He's 
cute - let's keep him for ourselves ;-)

Gerv


From gerv at mozilla.org  Tue Jan 25 08:52:44 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Tue, 25 Jan 2005 08:52:44 +0000
Subject: Custom fields schema
In-Reply-To: <41F5919F.4030906@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> <41F15E82.5060500@mozilla.org> <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net> <41F5919F.4030906@mozilla.org>
Message-ID: <41F608DC.9010705@mozilla.org>

Myk Melez wrote:
>    2. then they work the same as standard fields;
> 
>       Custom fields and standard fields are both used (queried,
>       displayed, updated) in much the same way, and using the same
>       technology to store them means we can use the same code in many
>       cases (and the same kind of code in others) to access and
>       manipulate them, making the source simpler, more robust, and
>       easier to develop.

Let's not underestimate the advantage of this point. Currently, 
Bugzilla's default field set includes some fields which most people 
don't use (e.g. URL). It would be great if the custom fields schema were 
such that we could easily transition fields from "hard-coded default" to 
"shipped-enabled custom", so people could remove them easily.

Gerv


From mkanat at kerio.com  Tue Jan 25 11:33:29 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Tue, 25 Jan 2005 03:33:29 -0800
Subject: Custom fields schema
In-Reply-To: <41F5D907.4050406@bugzilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
	 <41F15E82.5060500@mozilla.org>
	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>
Message-ID: <1106652810.10792.1.camel@max.localdomain>

On Tue, 2005-01-25 at 07:28 +0200, Vlad Dascalu wrote:
> I agree with Myk. The FAC proposal makes more sense for me, from all 
> points of view.

	I also used to think so.

	But if we want people to be able to write "plugins" for Bugzilla,
Fields-As-Rows makes much more sense.

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
Kerio Technologies, Inc.
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-2500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From mkanat at kerio.com  Tue Jan 25 11:38:08 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Tue, 25 Jan 2005 03:38:08 -0800
Subject: update to the default bugzilla css
In-Reply-To: <20050125044131.43CD84BCC8E@stutter.bur.st>
References: <20050125044131.43CD84BCC8E@stutter.bur.st>
Message-ID: <1106653088.10792.4.camel@max.localdomain>

On Tue, 2005-01-25 at 12:41 +0800, byron wrote:
> you can see it at
>   http://landfill.bugzilla.org/newui/

	That is excellent. And it makes me happy. :-) I fully support getting
it into 2.20. If you submit a patch on a bug, I'll be happy to review it
along with one or two others (probably whoever did the skins system...
was that kiko?)

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
Kerio Technologies, Inc.
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-2500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From kevin.benton at amd.com  Tue Jan 25 16:03:03 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Tue, 25 Jan 2005 09:03:03 -0700
Subject: update to the default bugzilla css
In-Reply-To: <20050125044131.43CD84BCC8E@stutter.bur.st>
Message-ID: <20050125160303.566411FE2@ldcmail.amd.com>

Since we're discussing the possibility of changing the UI, the text "Find a
Specific Bug" is misleading because that search can and does yield multiple
bugs.  I would rather see it changed to Simple Search.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of byron
> Sent: Monday, January 24, 2005 9:42 PM
> To: developers at bugzilla.org
> Subject: update to the default bugzilla css
> 
> ok, these are probably "fighting words" however..
> 
> i'm sure we'll all agree that the default bugzilla look requires updating.
> 
> 
> with that in mind i've made a small number of css-only changes that draw
> the
> look from the bugzilla web site, currently implmented as a custom skin
> against
> head.
> 
> you can see it at
>   http://landfill.bugzilla.org/newui/
> 
> as a comparison, the current css is at
>   http://landfill.bugzilla.org/bugzilla-tip/
> 
> 
> i think it looks pretty, and i'm wondering if it's worth pushing for it to
> be
> taken up as the default style until the ui overhaul is closer to ready.
> 
> 
> in short: what do you think?
> 
> 
> 
> -b
> 
> begin-base64 644 signature.gif
> R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
> XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
> h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
> N1PRMXimiLUGt3ElVimlgbllWAAAOw==
> ====
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From AGalewsky at evokesoft.com  Tue Jan 25 16:12:53 2005
From: AGalewsky at evokesoft.com (Andrew Galewsky)
Date: Tue, 25 Jan 2005 10:12:53 -0600
Subject: A best practices question...
Message-ID: <914AE8D88708134A9D6A3C0A4F0F06D4181377@hercules.evokesoft.com>

My guys have been asking how can they easily track the build number that
a bug was found in and the build number that the bug was fixed in and of
course view and report on same.

Thanks in advance!

________________________________________ 
  
Andrew Galewsky                          phone 512.637.8638 
Evoke Software, Inc.                       fax 512.372.9371 
VP of Product Development               mobile 512.422.8290 
12357 - III Riata Trace Parkway   http://www.evokesoft.com 
Building C, Suite #200 
Austin, TX 78727                    
              
 

Hard pressed on my right. My center is yielding. Impossible to maneuver.

Situation excellent. I am attacking. 

--Ferdinand Foch-- at the Battle of the Marne

 



From kevin.benton at amd.com  Tue Jan 25 16:20:52 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Tue, 25 Jan 2005 09:20:52 -0700
Subject: update to the default bugzilla css
In-Reply-To: <41F5E074.6030104@bugzilla.org>
Message-ID: <20050125162052.7E6D01FD6@ldcmail.amd.com>

> > Also, I'm a bit icky regarding the use of the bugzilla.org header at
> > every b.m.o. installation as a default. I thought about our "mascot" to
> > be more specific to bugzilla.org rather than every b.m.o. installation.
> 
> As much as I hate to throw a wet-blanket on things, he's right, and for
> legal reasons, not just "trying to keep our identity".

I would rather not see background images used for the logo, or if you must,
make sure you specify that the image does not repeat.  I would also prefer
to see the header code as a parameter, or at least the ability to specify
the logo image in the parameter section.  This would make customization
between installations much easier.

BTW - the way we use the header here is to put the company's logo on the
left side of the header, and an installation-specific image on the right as
a table.  

And Byron - I too agree that it's a very nice "baby step."

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.





From bugzilla at glob.com.au  Tue Jan 25 16:34:00 2005
From: bugzilla at glob.com.au (byron)
Date: Wed, 26 Jan 2005 00:34:00 +0800 (WST)
Subject: update to the default bugzilla css
Message-ID: <20050125163400.D19034BCE00@stutter.bur.st>

> I put that document on the web, and I'm quite happy to make an exception 
> for Bugzilla :-) There's no problem with it looking like mozilla.org.

excellent, thanks gerv :)


i've updated http://landfill.bugzilla.org/newui/

i've replace the ant with one from
http://groups.google.com.au/groups?selm=3C2F2534.9020403%40mozilla.org



begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From justdave at bugzilla.org  Tue Jan 25 16:54:32 2005
From: justdave at bugzilla.org (David Miller)
Date: Tue, 25 Jan 2005 11:54:32 -0500
Subject: update to the default bugzilla css
In-Reply-To: <20050125163400.D19034BCE00@stutter.bur.st>
References: <20050125163400.D19034BCE00@stutter.bur.st>
Message-ID: <41F679C8.8000808@bugzilla.org>

byron wrote:

> i've updated http://landfill.bugzilla.org/newui/

That's gorgeous, I love it!

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From vladd at bugzilla.org  Tue Jan 25 18:21:36 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Tue, 25 Jan 2005 20:21:36 +0200
Subject: A best practices question...
In-Reply-To: <914AE8D88708134A9D6A3C0A4F0F06D4181377@hercules.evokesoft.com>
References: <914AE8D88708134A9D6A3C0A4F0F06D4181377@hercules.evokesoft.com>
Message-ID: <41F68E30.9030404@bugzilla.org>

That would have been better asked on mozwebtools (this is devel-only).

You can use "target milestone" for version fixed and the "version' field 
for when the bug was found. That's how we do it on bugzilla.mozilla.org.

Thanks,
Vlad.

Andrew Galewsky wrote:

>My guys have been asking how can they easily track the build number that
>a bug was found in and the build number that the bug was fixed in and of
>course view and report on same.
>
>Thanks in advance!
>
>________________________________________ 
>  
>Andrew Galewsky                          phone 512.637.8638 
>Evoke Software, Inc.                       fax 512.372.9371 
>VP of Product Development               mobile 512.422.8290 
>12357 - III Riata Trace Parkway   http://www.evokesoft.com 
>Building C, Suite #200 
>Austin, TX 78727                    
>              
> 
>
>Hard pressed on my right. My center is yielding. Impossible to maneuver.
>
>Situation excellent. I am attacking. 
>
>--Ferdinand Foch-- at the Battle of the Marne
>
> 
>
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=vladd at bugzilla.org>
>
>
>  
>



From myk at mozilla.org  Tue Jan 25 21:39:46 2005
From: myk at mozilla.org (Myk Melez)
Date: Tue, 25 Jan 2005 13:39:46 -0800
Subject: update to the default bugzilla css
In-Reply-To: <20050125044131.43CD84BCC8E@stutter.bur.st>
References: <20050125044131.43CD84BCC8E@stutter.bur.st>
Message-ID: <41F6BCA2.9020806@mozilla.org>

byron wrote:

>i've made a small number of css-only changes that draw the
>look from the bugzilla web site, currently implmented as a custom skin against
>head... i think it looks pretty, and i'm wondering if it's worth pushing for it to be
>taken up as the default style until the ui overhaul is closer to ready.
>
>
>in short: what do you think?
>  
>
Overall it looks nice.  I like the smaller header, the removal of "This 
is" from the header, the header's rounded corners, the use of a sans 
serif font for UI elements (headers, labels, buttons), the removal of 
the underline decoration from linked UI elements (buttons, linked 
labels), and the updated color scheme.

I don't like the switch to a sans serif font for all text, the explicit 
reduction of font size, and the explicit specification of font face, 
however.  We should continue to use a serif font for regular text (I 
know this is controversial, but my review of the literature shows that 
sans serif is still more readable on the web at normal font sizes) and 
use the OS/browser default font size and face (since it is more likely 
to be and remain optimized for each user's machine).

I'm ambivalent about the body background, which is virtually invisible, 
and the use of a background image for the header, whose advantages over 
styled text and structure seem too slight to be worth it.

Otherwise I'm happy to see these changes get integrated into Bugzilla.  
Please file bugs in the UI component and request my review.  Note that 
in general smaller, focused patches are easier to review and quicker to 
integrate than larger patches that do many things at once, so consider 
breaking your changes up into separate patches for each change or 
related set of changes.

-myk



From myk at mozilla.org  Tue Jan 25 22:12:43 2005
From: myk at mozilla.org (Myk Melez)
Date: Tue, 25 Jan 2005 14:12:43 -0800
Subject: Custom fields schema
In-Reply-To: <1106652810.10792.1.camel@max.localdomain>
References: <20041224081704.cd36e999@mail.kerio.com>	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>	 <41F15E82.5060500@mozilla.org>	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> <1106652810.10792.1.camel@max.localdomain>
Message-ID: <41F6C45B.2080901@mozilla.org>

Maxwell Kanat-Alexander wrote:

>On Tue, 2005-01-25 at 07:28 +0200, Vlad Dascalu wrote:
>  
>
>>I agree with Myk. The FAC proposal makes more sense for me, from all 
>>points of view.
>>    
>>
>
>	I also used to think so.
>
>	But if we want people to be able to write "plugins" for Bugzilla,
>Fields-As-Rows makes much more sense.
>  
>
Plugins can be roughly divided into three categories:

    * add no new fields (NNF), just manipulate existing ones (f.e. a
      plugin that added a "checked in" comment and resolved bugs "FIXED"
      when a patch on them was checked into a source control system);
    * add new generic fields (NGF) that don't need to be manipulated
      specially and can be implemented using custom fields;
    * add new special fields (NSF) that need to be manipulated specially
      and cannot be implemented using custom fields (f.e. Test Runner
      <http://sourceforge.net/projects/testrunner/>);

Of these, only NGF plugins can use custom fields, and if a plugin just 
creates a custom field and then lets the generic custom field code 
handle interaction with it, then why take the trouble to make it a 
plugin?  It'd be much easier for installations that want the 
functionality to just define the custom field themselves using whatever 
interface we develop for managing custom fields.

I think very few, if any, plugins will create custom fields.  But even 
if some did (f.e. a plugin that created a bunch of related custom fields 
which would otherwise be burdensome to create by hand via the interface, 
or a plugin which reused most generic custom fields code but with a few 
special tweaks), why does FAD make more sense for them?  Real columns 
are as easy to create programmatically, keep plugin data more separate 
from standard and installation-defined custom field data, and can be 
made more secure if necessary (by giving plugins a MySQL account that 
only permitted write access to its own tables).

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050125/79b6c75a/attachment.html>

From mkanat at kerio.com  Wed Jan 26 02:05:26 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Tue, 25 Jan 2005 18:05:26 -0800
Subject: Custom fields schema
In-Reply-To: <41F6C45B.2080901@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
	 <41F15E82.5060500@mozilla.org>
	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>
	 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
Message-ID: <1106705126.3713.33.camel@localhost.localdomain>

On Tue, 2005-01-25 at 14:12 -0800, Myk Melez wrote:
> Plugins can be roughly divided into three categories:
> [snip]

	OK. Fair enough.

	My experience is that implementations which try to predict the future,
and limit themselves in design to only what they predict, are doomed to
failure. That's why I'm in favor of FAR, because it's more extensible. I
can't know what types of plugins people will create, so I'd rather give
them as many options as possible.

	As a single example, what if I created a single plugin that was
"Project Management for Bugzilla?"

	Fields-As-Data makes it easier to write generic SQL, also, to grab data
out of custom fields, without knowing the type of data in those fields
in advance, or how we'd have to JOIN in order to get the data, or even
having to modify the SELECT statement in a fashion that can't use
placeholders.

	To be honest, I haven't tried to implement it either way, personally. I
know that Sean has. I think he used Fields-As-Data, and I think his
implementation is working nicely at Transmeta.

	Of course, Fields-As-Columns is the way that Bugzilla works now. Except
for things like longdescs, which is a sort of Fields-As-Data thing.

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From mkgnu at gmx.net  Wed Jan 26 02:53:24 2005
From: mkgnu at gmx.net (Kristis Makris)
Date: Tue, 25 Jan 2005 19:53:24 -0700
Subject: [ham] Re: A best practices question...
In-Reply-To: <41F68E30.9030404@bugzilla.org>
References: <914AE8D88708134A9D6A3C0A4F0F06D4181377@hercules.evokesoft.com>
 <41F68E30.9030404@bugzilla.org>
Message-ID: <1106708004.2682.39.camel@syd.mkgnu.net>

On Tue, 2005-01-25 at 20:21 +0200, Vlad Dascalu wrote:
> That would have been better asked on mozwebtools (this is devel-only).
> 
> You can use "target milestone" for version fixed and the "version' field 
> for when the bug was found. That's how we do it on bugzilla.mozilla.org.

This would be the manual approach.

It is possible however to have a tool automatically detect and report
the build a bug was fixed in if the repository is integrated with
bug-tracking (the build dates --- read: tags --- are needed for this).
We're adding this feature in the Scmbug VDD
generator(http://bugzilla.mkgnu.net/show_bug.cgi?id=80) supporting
Bugzilla.




From bugzilla at glob.com.au  Wed Jan 26 13:51:47 2005
From: bugzilla at glob.com.au (byron)
Date: Wed, 26 Jan 2005 21:51:47 +0800 (WST)
Subject: update to the default bugzilla css
Message-ID: <20050126135147.B200F4BCE32@sweep.bur.st>

> I'm ambivalent about the body background, which is virtually invisible, 
> and the use of a background image for the header, whose advantages over 
> styled text and structure seem too slight to be worth it.

it's a skin -- i wanted to do the changes without any template modifications.

> Otherwise I'm happy to see these changes get integrated into Bugzilla.  
> Please file bugs in the UI component and request my review.  Note that 
> in general smaller, focused patches are easier to review and quicker to 
> integrate than larger patches that do many things at once, so consider 
> breaking your changes up into separate patches for each change or 
> related set of changes.

the patch is small, only affects global.css and index.css plus the new files.

bug 279896



begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From etzwane at schwag.org  Wed Jan 26 18:37:22 2005
From: etzwane at schwag.org (Sean McAfee)
Date: Wed, 26 Jan 2005 13:37:22 -0500
Subject: Custom fields schema
Message-ID: <20050126183723.05ECDBC77@mail.schwag.org>

Responding to several messages at once:

Myk:

>*sigh*, ok, I'll do some testing next week when I get back from 
>vacation, although I really think the burden of proof should be on you, 
>given that you're the one suggesting we overturn thirty years of RDBMS 
>and relational database theory, design, and practical usage,

OK, I take exception to this.  Am I really such a maverick?  Most of the
people who have stated an opinion on the subject have expressed approval
of my design.  Can we all be as naive as you say?

>not to 
>mention six years of Bugzilla development techniques.

Custom fields are a completely new kind of beast.  There is no precedent for
them in Bugzilla's development history.  (Not in the core distribution,
anyway; some partial solutions are attached to bug 91037.  I don't think
that's what you're talking about, though.)  There's no a priori reason to
apply past Bugzilla development techniques to them.

Later:

>Custom fields are exactly what relational database columns were designed 
>for; they fit perfectly into the column metaphor, just as the standard 
>Bugzilla fields do.

What is this "column metaphor"?  Your design treats custom fields very
differently than standard fields, applying more of a "table metaphor".

>They're modifiable via SQL statements just as 
>easily as the data within them is.  And while Bugzilla doesn't modify 
>its schema very much today, there's nothing inherently more dangerous 
>about it doing so.

But much less elegant.  To paraphrase Einstein, I think the schema ought to
be as simple as possible, but no simpler.  Transmeta's Bugzilla installation
has 187 custom fields.  A schema with in excess of 250 tables is not simple.
Imagine trying to manage a schema of that size with a visual tool!

Later, responding to Christopher Hicks:

>That doesn't mean we should store all meta-data as data.  We should use 
>the right tool for the job, as we have already done with standard 
>fields, for which we rightly use columns.

Yes, that is right, because all bugs share the same standard fields.  That
condition is violated by custom fields.  And, again, your proposal
implements custom fields very differently from the way standard fields are
implemented, anyway.

>> (4) Since queries involving custom fields are going to take a few 
>> database hits to figure out what the field names so the query could be 
>> written you end up with cases where 1 query turns into 4 queries.  If 
>> the database is across a WAN from the bugzilla instance the effect of 
>> multiple queries where there were one will be more noticable.

>Sure, more queries is slower.  But FAC would use less queries overall, 
>and simpler ones at that.

Simpler, I grant you.  Fewer, I don't think so:

>Consider a simple query on a single custom field "foo" where the user 
>wants bugs where foo=bar.  With FAC, we search for bugs where the "foo" 
>column contains "bar".  With FAD, we look up the field ID for "foo" and 
>then search for bugs where the "field_id" column contains that ID and 
>the "value" column contains "bar" (or do it in one query with a join).

Querying against N custom fields results in joins against N tables in your
scheme.  In mine, it results in joins against T(N), the number of distinct
datatypes among those N fields.  The total number of joins among those
T(N) tables is N including repeated joins, but I suspect that it is still
cheaper to access fewer tables.

Consider also simply retrieving custom field data.  For a bug with twenty
custom short string fields, your design would require SELECTs against
twenty different tables; mine requires only one.

>> Myk - it sounds like you're basing the decision on what way to go here 
>> totally based on performance and I think there's a lot more that 
>> should go into this decision.

>To the contrary, my proposal is based on much more than performance.  My 
>previous email was about performance only because that was Sean's 
>primary argument against it (he thought my proposal would be slower and 
>offered data to support his conclusion--I ran his tests myself and found 
>the opposite was true).

I haven't analyzed your tests in detail yet--it's been a hassle getting
MySQL 4 to peacefully coexist with my previous MySQL 3 system.  (By the way,
if my design ignores thirty years of database theory, as you assert, why
does yours require a recent version of MySQL to best it?)

Can you describe exactly what was wrong with my test that it went from being
3-4 times better to being nearly an order of magnitude worse?  I frankly
find that hard to believe.

>I think we should use real columns for custom fields because:
>
>   1. that's what they're there for;
>
>      Custom fields are no different from standard fields in how they're
>      used (queried, displayed, updated, etc.), and columns were
>      designed for this express purpose when database systems were
>      developed.  Given that they've been used to represent "fields" of
>      all kinds for decades, and that we've used them in Bugzilla to
>      represent the standard fields for over five years, they're a
>      mature and proven technology for doing what we want and likely to
>      be better than any new mechanism we come up with which represents
>      fields as data.

I posted to comp.databases yesterday seeking advice regarding the merits of
our two designs.  The subject of the thread is "Best database schema for
object fields".  To date, the only poster to offer substantial criticism has
stated "They both stink", but he did provide the useful information that the
model I implemented has a name, EAV, or "Entity-Attribute-Value".  Armed
with that knowledge, I was able to Google several articles on the subject.
A few were highly critical of EAV, but most were more balanced, listing
advantages and disadvantages, and describing in what situations it's
appropriate.  In all cases, though, the data model EAV was compared against
was the classic all-columns-in-one-table approach; I could find no example
of your one-table-per-field design.  (The crotchety poster in comp.databases
described both of our designs as variants of EAV, but I can't really see how
that's true.)  So, it's hard to accept your assertion that
one-field-per-table is "what columns are for".  Can you refer me to any
systems that use your design?

>   2. then they work the same as standard fields;
>
>      Custom fields and standard fields are both used (queried,
>      displayed, updated) in much the same way, and using the same
>      technology to store them means we can use the same code in many
>      cases (and the same kind of code in others) to access and
>      manipulate them, making the source simpler, more robust, and
>      easier to develop.

If I'm not mistaken, the long-term plan is to migrate standard fields to
custom fields, so short-term discrepancies are not really relevant.
Besides--yet again!--your design treats custom fields very differently than
standard fields.

>   3. it makes them significantly faster;
>
>      Per my tests and standard database design theory, real columns are
>      much faster than data columns.

Again, I find this hard to believe.  I suspect either some flaw in your test
program, or some unfair advantage in the limited nature of the tests.


--Sean


From kevin.benton at amd.com  Wed Jan 26 19:05:11 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Wed, 26 Jan 2005 12:05:11 -0700
Subject: Custom fields schema
In-Reply-To: <20050126183723.05ECDBC77@mail.schwag.org>
Message-ID: <20050126190512.9BB1B1FBD@ldcmail.amd.com>

I have pretty much kept my mouth shut regarding this debate lately until
now.  I think it's getting a little out of hand.  I think what really needs
to happen is for us to look at what we want out of the design, and more
importantly, to ask ourselves how will our proposal be used realistically?

Right now, I can tell you that I am really beating up MySQL 3.23.x doing
standard queries against the tables given with my statuscount.cgi.  I was
able to flood MySQL to the point where it took over a minute to get results
back from a query that basically asked - show me a list of bugs that have
been opened but never had a status change in it.  Until I added some new
indexes, that report was taking far too long to make it usable.

Now, we're talking about having the ability to add custom fields.  This is a
good thing, but let's be sure we do it wisely.  No matter which method we
choose, it needs to be easy to use, understand, and perform without a
serious hit to the DB.  To do that - we must consider some kinds of custom
fields that might be created and how that creation would happen.  If it's
something that can be handled without adding new code, then we should expect
ours to handle optimization reasonably.  If not, we should guide admins. on
how to properly optimize after adding new fields.

Conceptually, for me, it's a lot easier to understand fields as columns than
fields as rows.  Why?  A table contains a record.  That record contains
fields.  That's traditional design.  Creating a table for each field simply
doesn't make sense to me because the fields are no longer directly related
to one another.  Understanding how field A relates to field B relates to
field C can then become a real nightmare.

If we have Bugzilla administer the fields itself, there are optimization
considerations.  Because it's nearly impossible for us to figure out ahead
of time what fields will be added and how they will relate to each other, we
must also consider how to implement some kind of optimization aid on top of
it as well.  So, if new field 1 relates to existing field A, and existing
field B, the admin should be able to tell Bugzilla that they're related and
have it add the indexes.

Please note that I am not saying that this is how it should be done.  As an
administrator, developer, and report writer, I want to make sure that
anything we do does not kill performance while obtaining some form of
elegance or simplicity in coding.  We have to find the best middle ground
where performance is excellent, but code maintenance is reasonably easy as
well.

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Sean McAfee
> Sent: Wednesday, January 26, 2005 11:37 AM
> To: developers at bugzilla.org
> Subject: Re: Custom fields schema
> 
> Responding to several messages at once:
> 
> >not to
> >mention six years of Bugzilla development techniques.
> 
> Custom fields are a completely new kind of beast.  There is no precedent
> for
> them in Bugzilla's development history.  (Not in the core distribution,
> anyway; some partial solutions are attached to bug 91037.  I don't think
> that's what you're talking about, though.)  There's no a priori reason to
> apply past Bugzilla development techniques to them.
> 
> Later:
> 
> >Custom fields are exactly what relational database columns were designed
> >for; they fit perfectly into the column metaphor, just as the standard
> >Bugzilla fields do.
> 
> What is this "column metaphor"?  Your design treats custom fields very
> differently than standard fields, applying more of a "table metaphor".
> 
> >They're modifiable via SQL statements just as
> >easily as the data within them is.  And while Bugzilla doesn't modify
> >its schema very much today, there's nothing inherently more dangerous
> >about it doing so.
> 
> But much less elegant.  To paraphrase Einstein, I think the schema ought
> to
> be as simple as possible, but no simpler.  Transmeta's Bugzilla
> installation
> has 187 custom fields.  A schema with in excess of 250 tables is not
> simple.
> Imagine trying to manage a schema of that size with a visual tool!
> 
> Later, responding to Christopher Hicks:
> 
> >That doesn't mean we should store all meta-data as data.  We should use
> >the right tool for the job, as we have already done with standard
> >fields, for which we rightly use columns.
> 
> Yes, that is right, because all bugs share the same standard fields.  That
> condition is violated by custom fields.  And, again, your proposal
> implements custom fields very differently from the way standard fields are
> implemented, anyway.
> 
> >> (4) Since queries involving custom fields are going to take a few
> >> database hits to figure out what the field names so the query could be
> >> written you end up with cases where 1 query turns into 4 queries.  If
> >> the database is across a WAN from the bugzilla instance the effect of
> >> multiple queries where there were one will be more noticable.
> 
> >Sure, more queries is slower.  But FAC would use less queries overall,
> >and simpler ones at that.
> 
> Simpler, I grant you.  Fewer, I don't think so:
> 
> >Consider a simple query on a single custom field "foo" where the user
> >wants bugs where foo=bar.  With FAC, we search for bugs where the "foo"
> >column contains "bar".  With FAD, we look up the field ID for "foo" and
> >then search for bugs where the "field_id" column contains that ID and
> >the "value" column contains "bar" (or do it in one query with a join).
> 
> Querying against N custom fields results in joins against N tables in your
> scheme.  In mine, it results in joins against T(N), the number of distinct
> datatypes among those N fields.  The total number of joins among those
> T(N) tables is N including repeated joins, but I suspect that it is still
> cheaper to access fewer tables.
> 
> Consider also simply retrieving custom field data.  For a bug with twenty
> custom short string fields, your design would require SELECTs against
> twenty different tables; mine requires only one.
> 
> >> Myk - it sounds like you're basing the decision on what way to go here
> >> totally based on performance and I think there's a lot more that
> >> should go into this decision.
> 
> >To the contrary, my proposal is based on much more than performance.  My
> >previous email was about performance only because that was Sean's
> >primary argument against it (he thought my proposal would be slower and
> >offered data to support his conclusion--I ran his tests myself and found
> >the opposite was true).
> 
> I haven't analyzed your tests in detail yet--it's been a hassle getting
> MySQL 4 to peacefully coexist with my previous MySQL 3 system.  (By the
> way,
> if my design ignores thirty years of database theory, as you assert, why
> does yours require a recent version of MySQL to best it?)
> 
> Can you describe exactly what was wrong with my test that it went from
> being
> 3-4 times better to being nearly an order of magnitude worse?  I frankly
> find that hard to believe.
> 
> >I think we should use real columns for custom fields because:
> >
> >   1. that's what they're there for;
> >
> >      Custom fields are no different from standard fields in how they're
> >      used (queried, displayed, updated, etc.), and columns were
> >      designed for this express purpose when database systems were
> >      developed.  Given that they've been used to represent "fields" of
> >      all kinds for decades, and that we've used them in Bugzilla to
> >      represent the standard fields for over five years, they're a
> >      mature and proven technology for doing what we want and likely to
> >      be better than any new mechanism we come up with which represents
> >      fields as data.
> 
> I posted to comp.databases yesterday seeking advice regarding the merits
> of
> our two designs.  The subject of the thread is "Best database schema for
> object fields".  To date, the only poster to offer substantial criticism
> has
> stated "They both stink", but he did provide the useful information that
> the
> model I implemented has a name, EAV, or "Entity-Attribute-Value".  Armed
> with that knowledge, I was able to Google several articles on the subject.
> A few were highly critical of EAV, but most were more balanced, listing
> advantages and disadvantages, and describing in what situations it's
> appropriate.  In all cases, though, the data model EAV was compared
> against
> was the classic all-columns-in-one-table approach; I could find no example
> of your one-table-per-field design.  (The crotchety poster in
> comp.databases
> described both of our designs as variants of EAV, but I can't really see
> how
> that's true.)  So, it's hard to accept your assertion that
> one-field-per-table is "what columns are for".  Can you refer me to any
> systems that use your design?
> 
> >   2. then they work the same as standard fields;
> >
> >      Custom fields and standard fields are both used (queried,
> >      displayed, updated) in much the same way, and using the same
> >      technology to store them means we can use the same code in many
> >      cases (and the same kind of code in others) to access and
> >      manipulate them, making the source simpler, more robust, and
> >      easier to develop.
> 
> If I'm not mistaken, the long-term plan is to migrate standard fields to
> custom fields, so short-term discrepancies are not really relevant.
> Besides--yet again!--your design treats custom fields very differently
> than
> standard fields.
> 
> >   3. it makes them significantly faster;
> >
> >      Per my tests and standard database design theory, real columns are
> >      much faster than data columns.
> 
> Again, I find this hard to believe.  I suspect either some flaw in your
> test
> program, or some unfair advantage in the limited nature of the tests.
> 
> 
> --Sean
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From bugreport at peshkin.net  Wed Jan 26 19:21:54 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Wed, 26 Jan 2005 11:21:54 -0800
Subject: Custom fields schema
In-Reply-To: <20050126190512.9BB1B1FBD@ldcmail.amd.com>
References: <20050126190512.9BB1B1FBD@ldcmail.amd.com>
Message-ID: <41F7EDD2.4070704@peshkin.net>

Kevin Benton wrote:

><snip>
>
>Right now, I can tell you that I am really beating up MySQL 3.23.x doing
>standard queries against the tables given with my statuscount.cgi.  I was
>able to flood MySQL to the point where it took over a minute to get results
>back from a query that basically asked - show me a list of bugs that have
>been opened but never had a status change in it.  Until I added some new
>indexes, that report was taking far too long to make it usable.
>
>Now, we're talking about having the ability to add custom fields.  This is a
>good thing, but let's be sure we do it wisely.  No matter which method we
>choose, it needs to be easy to use, understand, and perform without a
>serious hit to the DB.  To do that - we must consider some kinds of custom
>fields that might be created and how that creation would happen.  If it's
>something that can be handled without adding new code, then we should expect
>ours to handle optimization reasonably.  If not, we should guide admins. on
>how to properly optimize after adding new fields.
>
>  
>

For the record, Bugzilla will continue to be compatible with MySQL 
3.23.x for a few more major releases but 3.23 is NOT the benchmark for 
performance.  Anyone using MySQL 3.23 will be presumed to be a small 
site that doesn't care about optimum performance.  Large 
high-performance sites will be expected to be on MySQL 4.something.recent

When judging the resulting performance of a new feature, let's focus on 
MySQL 4.  Just don't break 3.23 altogether.

That said, the intention is to have BMO use custom fields as well, so it 
cannot be a total dog.

-Joel



From rob2 at siklos.ca  Thu Jan 27 00:14:59 2005
From: rob2 at siklos.ca (robzilla)
Date: Wed, 26 Jan 2005 19:14:59 -0500
Subject: column selector / saving columns per query
Message-ID: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>

Hi All,

I'm working on revamping the "Choose Columns" functionality in my 
installation of Bugzilla.  I want to eventually submit a patch since it 
cleans things up real nice and provides functionality for saving displayed 
columns per query, but since it changes a couple things, I wanted some 
feedback.

What I've done is:
- get rid of the "Change Columns" link at the bottom of the buglist page
- in the query page, add a "column selector" section (collapsed by default, 
has an "expand" button).  The column selector is a typical layout: two 
listboxes (available/selected columns), and buttons for moving between the 
list boxes and changing the column order (screenshot at 
http://rob.siklos.ca/bz/10049.html)

When you submit the query, it adds the 'columnlist' parameter to the 
buglist.cgi query string.  This specifies which columns should be displayed 
and in which order.

The cool part is when you save the query, you also save the column display 
information (since it's part of the URI)

Implications:
Since I got rid of the "Change Columns" page, there's no more support for 
"default columns" (saved in a cookie).  I didn't really see this as a 
problem, since the default columns are now saved with the default query (if 
you create one).

But there's a couple holes:
1) you don't get to save a default query unless you have a login ID
2) it only works for the "Advanced" search, and not the "Find a specific 
bug." page

For #1, I was thinking that we could give users who aren't logged in the 
option to save a default query, but it would be saved in a browser cookie 
instead of in the database.

For #2, I'll have to think about it some more, since i've never used that 
page.  Suggestions welcome :)

Most of the backend functionality is already there, but there's no 
interface.

What do you guys think - is this trunk material, or better left as a 
personal customization?

Rob Siklos.

P.S. can't post any code yet until we get clearance from our legal 
department, but it should only be a couple weeks. 



From timeless at myrealbox.com  Thu Jan 27 02:26:07 2005
From: timeless at myrealbox.com (timeless)
Date: Wed, 26 Jan 2005 18:26:07 -0800
Subject: column selector / saving columns per query
In-Reply-To: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
Message-ID: <41F8513F.3000602@myrealbox.com>

robzilla wrote:
> What I've done is:
> - get rid of the "Change Columns" link at the bottom of the buglist page
> - in the query page, add a "column selector" section (collapsed by 
> default, has an "expand" button).  The column selector is a typical 
> layout: two listboxes (available/selected columns), and buttons for 
> moving between the list boxes and changing the column order (screenshot 
> at http://rob.siklos.ca/bz/10049.html)

looks kinda nice. i have two concerns, one is "Edit Off"/"Edit On", 
which doesn't mean anything to me. the other is even more trivial: stick 
a space before ( in: "Synopsis(first 60 characters)".

> 2) it only works for the "Advanced" search, and not the "Find a specific 
> bug." page
that's annoying

3. you need javascript. that's really annoying :). please see about 
leaving a way for people to select columns if they don't have javascript.

> What do you guys think - is this trunk material, or better left as a 
> personal customization?

trunk material


From mkanat at kerio.com  Thu Jan 27 04:02:17 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Wed, 26 Jan 2005 20:02:17 -0800
Subject: Custom fields schema
In-Reply-To: <20050126190512.9BB1B1FBD@ldcmail.amd.com>
References: <20050126190512.9BB1B1FBD@ldcmail.amd.com>
Message-ID: <1106798537.14998.3.camel@max.localdomain>

On Wed, 2005-01-26 at 12:05 -0700, Kevin Benton wrote:
> If we have Bugzilla administer the fields itself, there are optimization
> considerations.
> [snip]

	Actually, with "fields-as-columns," we have an unknown number of
indexes required to make the one-index-per-query MySQL perform properly.

	If we do "fields-as-rows," we create the indexes once with checksetup,
and never worry about them again.

	-Max

	P.S. It's polite to trim quotes down, so that you don't send hunks of
stuff that the list has already seen. :-)
-- 
Max Kanat-Alexander
Technical Support Manager, USA
Kerio Technologies, Inc.
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-2500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From mkanat at kerio.com  Thu Jan 27 04:04:17 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Wed, 26 Jan 2005 20:04:17 -0800
Subject: column selector / saving columns per query
In-Reply-To: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
Message-ID: <1106798657.14998.5.camel@max.localdomain>

On Wed, 2005-01-26 at 19:14 -0500, robzilla wrote:
> I'm working on revamping the "Choose Columns" functionality in my 
> installation of Bugzilla.  I want to eventually submit a patch since it 
> cleans things up real nice and provides functionality for saving displayed 
> columns per query, but since it changes a couple things, I wanted some 
> feedback.
> [snip]

	Yeah, very nice!

	I think the "options" should go below the "search" button, though.

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
Kerio Technologies, Inc.
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-2500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From myk at mozilla.org  Thu Jan 27 14:03:08 2005
From: myk at mozilla.org (Myk Melez)
Date: Thu, 27 Jan 2005 06:03:08 -0800
Subject: Custom fields schema
In-Reply-To: <1106705126.3713.33.camel@localhost.localdomain>
References: <20041224081704.cd36e999@mail.kerio.com>	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>	 <41F15E82.5060500@mozilla.org>	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>	 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain>
Message-ID: <41F8F49C.1010506@mozilla.org>

Max Kanat-Alexander wrote:

>On Tue, 2005-01-25 at 14:12 -0800, Myk Melez wrote:
>  
>
>>Plugins can be roughly divided into three categories:
>>[snip]
>>    
>>
>
>	OK. Fair enough.
>
>	My experience is that implementations which try to predict the future,
>and limit themselves in design to only what they predict, are doomed to
>failure. That's why I'm in favor of FAR, because it's more extensible. I
>can't know what types of plugins people will create, so I'd rather give
>them as many options as possible.
>  
>
In my experience it's just as dangerous to overgenericize because 
someone might need some capability you don't know about yet.  But FAC 
doesn't limit the use of custom fields by plugins, and it allows 
installations and plugins to create just as many and as varied custom 
fields as FAD.  How is FAD more extensible?

>	As a single example, what if I created a single plugin that was
>"Project Management for Bugzilla?"
>  
>
Ok, let's say you did.  How does that inform this debate?

>	Fields-As-Data makes it easier to write generic SQL
>
What's generic SQL, why is it important, and how is it easier to write 
in FAD?

>, also, to grab data
>out of custom fields, without knowing the type of data in those fields
>in advance
>
Not true.  FAD uses field types just as surely as FAC and standard 
fields.  Both proposals similarly enable installations to stuff data of 
all types into text fields if desired.  But manipulating typeless data 
is of limited utility, anyway, and suboptimal (which is why we're 
storing data in a database in the first place).

>, or how we'd have to JOIN in order to get the data,
>
Both proposals store meta-data that tells code how to access custom 
fields and when a JOIN will be necessary in a meta-data table (either by 
extending fielddefs or creating an equivalent).  With FAC, it may 
sometimes be possible to derive this information from a form field name, 
which is easier than looking it up in the meta-data table.  Otherwise, 
FAC will do the lookup, but FAD will too.  How is it easier with FAD, 
and why does that matter?

>or even
>having to modify the SELECT statement in a fashion that can't use
>placeholders.
>  
>
How does FAC make it harder to use placeholders?

>	To be honest, I haven't tried to implement it either way, personally. I
>know that Sean has. I think he used Fields-As-Data, and I think his
>implementation is working nicely at Transmeta.
>  
>
It's possible to implement custom fields via either approach, and it's 
likely that either approach will work on a given installation, but we're 
trying to figure out the best approach for all Bugzilla installations 
and developers, and while the success of an approach on one site can 
inform the debate, it can't decide it.

While weighing Sean's success with FAD at his installation, we should 
also weigh the success of FAC on hundreds of Bugzilla installations for 
a number of years, both for standard fields and for custom ones, not to 
mention the general success of FAC in database design.

>	Of course, Fields-As-Columns is the way that Bugzilla works now. Except
>for things like longdescs, which is a sort of Fields-As-Data thing.
>  
>
longdescs isn't FAD at all, it stores comment entities which have 
attributes represented by columns and whose rows each represent a unique 
instance of a comment.  It's a classic example of an object modeled by a 
table, just like the bugs, attachments, and users tables.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/247a9710/attachment.html>

From chicks at chicks.net  Thu Jan 27 14:41:16 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Thu, 27 Jan 2005 09:41:16 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41F8F49C.1010506@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501270932190.23307@skippy.fini.net>

On Thu, 27 Jan 2005, Myk Melez wrote:
> While weighing Sean's success with FAD at his installation, we should also 
> weigh the success of FAC on hundreds of Bugzilla installations for a number 
> of years, both for standard fields and for custom ones, not to mention the 
> general success of FAC in database design.

There's enough text being sent around about this without straw man 
arguments such as this.  If none of those folks are doing custom fields as 
extensively as Sean is then they're not relevant to this discussion. 
That leaves one working example that applies to the question of how to 
implement custom fields and that is Sean's.  Given the choice between 
betting on the horse going around the track and the horse in your 
imagination, my money is on Sean.  If I could only find a bookie.

Beyond that, I don't think nearly as much credit has been given to Sean 
for (A) making something that works and being willing to share it or (B) 
his persistence in battling with bugzilla developers who seem to ignore A.

In this whole FAC vs. FAR debate I think I've missed something.  In Sean's 
discussion of Myk's proposal he indicated that Myk was proposing that each 
new custom field would be in its own table.  Is that really so?  Am I the 
only person who finds that bizarre?  I can understand FAR being a tough 
pill for a relational die hard to swallow, but coming up with something 
even more outlandish as an alternative is bizarre.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From travis at SEDSystems.ca  Thu Jan 27 16:07:49 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Thu, 27 Jan 2005 10:07:49 -0600 (CST)
Subject: Custom fields schema
In-Reply-To: <41F8F49C.1010506@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
Message-ID: <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>



On Thu, 27 Jan 2005, Myk Melez wrote:

> While weighing Sean's success with FAD at his installation, we should
> also weigh the success of FAC on hundreds of Bugzilla installations for
> a number of years, both for standard fields and for custom ones, not to
> mention the general success of FAC in database design.

Something else to weigh: Are any of those 'hundreds of installations' (where
do you get this figure from anyway?) making any effort to improve Bugzilla
by re-committing their code? Do they have a developer who is willing to
commit to the multiple re-writes and constant criticism that's going to be
necessary to get a patch of this size and magnitude landed on the trunk?

AIUI, Sean has already had to develop this locally -- because his bosses
told him to. He is now trying to make the results of his efforts available
to Bugzilla, because it's something that people have been griping about
wanting done for the last five years... and he's basically being told to go
piss up a rope because his design isn't good enough. Way to foster major
contributions! Funny thing is that it's good enough to hold 187 custom
fields at his site... but that's not good enough for us (or, more
specifically, for Myk).

If one of FAC/FAD were a complete abomination, and implementing it that way
would be universally looked back on as a horrendous mistake... then
absolutely I agree that the code shouldn't be taken just for the sake of
having it...  but that doesn't seem to be the case here. There are benefits
and trade-offs to each method. Each one has its proponents and its
detractors, and this discussion is rapidly taking on some characteristics of
a Religious Flame War.

Working code (and dedicated developers) trumps beautiful theories nine times
out of ten, in my books.

Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From mkanat at kerio.com  Thu Jan 27 22:49:45 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Thu, 27 Jan 2005 14:49:45 -0800
Subject: Custom fields schema
In-Reply-To: <41F8F49C.1010506@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
	 <41F15E82.5060500@mozilla.org>
	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>
	 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
	 <1106705126.3713.33.camel@localhost.localdomain>
	 <41F8F49C.1010506@mozilla.org>
Message-ID: <1106866185.12303.14.camel@localhost.localdomain>

On Thu, 2005-01-27 at 06:03 -0800, Myk Melez wrote:
> In my experience it's just as dangerous to overgenericize because
> someone might need some capability you don't know about yet.

	Yeah, that's true.

> But FAC doesn't limit the use of custom fields by plugins, and it
> allows installations and plugins to create just as many and as varied
> custom fields as FAD.  How is FAD more extensible?

	Because it's easier for a developer who knows nothing about Bugzilla
internals (a plugin developer) to add and maintain rows than it is to
add and maintain columns.

> > 	As a single example, what if I created a single plugin that was
> > "Project Management for Bugzilla?"
> >   
> Ok, let's say you did.  How does that inform this debate?

	Because it spans across the three groups of fields that you mentioned.
And because it can require functionality that I can't possibly predict
at this point, without actually doing the design.

> [snip]
> > or even
> > having to modify the SELECT statement in a fashion that can't use
> > placeholders.
> >   
> How does FAC make it harder to use placeholders?

	FAC looks like this:

	SELECT $column1, $column2, $column3, etc.
	FROM $table1 $possibleJoin1 $table2 $possibleJoin2
	WHERE <criteria>

	FAD looks like this:

	SELECT field_name, field_id, field_data, bug_id
	FROM field_table <some_standard_joins>
	WHERE field_name = $fieldname

	Only $fieldname can be a placeholder. You can't use placeholders for
column or table names.

	Generally, this is also what I meant by generic SQL.

	I think it's easier to deal with the FAD query that I wrote above, for
fields that I don't know about in advance, than it is to deal with the
FAC query. 

	The FAC query is great for fields that I know about in advance, because
I know what the field names will be, when I'm working with it in perl,
and for various other reasons.

	I'll admit, FAD does create a bit of a flat namespace, and that can be
a problem. Without proper indexes, it can create a large table that's
hard to parse. However, thankfully, the table structure is definite and
the indexes are easy to write. With FAC, there are also a larger number
of indexes, and it would be somewhat difficult to change them if we had
to, on an upgrade or something like that (that is, assuming that certain
columns had their own tables).
 
> It's possible to implement custom fields via either approach, and it's
> likely that either approach will work on a given installation, but
> we're trying to figure out the best approach for all Bugzilla
> installations and developers, and while the success of an approach on
> one site can inform the debate, it can't decide it.

	OK, I definitely agree with that.

> While weighing Sean's success with FAD at his installation, we should
> also weigh the success of FAC on hundreds of Bugzilla installations
> for a number of years, both for standard fields and for custom ones,
> not to mention the general success of FAC in database design.

	True. Of course, in most of those implementations, each developer knows
exactly what specific fields they are adding, and exactly how they're
going to be used. So they're not so much "generic" custom fields as they
are "specific" custom fields.

> longdescs isn't FAD at all, it stores comment entities which have
> attributes represented by columns and whose rows each represent a
> unique instance of a comment.  It's a classic example of an object
> modeled by a table, just like the bugs, attachments, and users tables.

	OK, you're right about that. :-)

	FWIW, before a few weeks ago, I was also a very strong proponent of
FAC, because it's better database design, for the backend.

	I just think that FAC will allow us to accomplish our goals for
Bugzilla more easily.

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From mkanat at kerio.com  Thu Jan 27 22:57:20 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Thu, 27 Jan 2005 14:57:20 -0800
Subject: Enums
Message-ID: <1106866641.12303.17.camel@localhost.localdomain>

	Hey all. So, there's a patch (by me) on the "enums bug", bug 17453, one
of the oldest bugs that we have in Bugzilla. The patch is just awaiting
review. It's actually not too complex of a patch, and it's a pretty big
architectural benefit that we've been wanting for a long time.

	If anybody wants to review it, I'd be grateful. :-)

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

	-Max




From myk at mozilla.org  Thu Jan 27 13:54:20 2005
From: myk at mozilla.org (Myk Melez)
Date: Thu, 27 Jan 2005 05:54:20 -0800
Subject: Custom fields schema
In-Reply-To: <20050126183723.05ECDBC77@mail.schwag.org>
References: <20050126183723.05ECDBC77@mail.schwag.org>
Message-ID: <41F8F28C.9060303@mozilla.org>

Sean McAfee wrote:

>Myk:
>  
>
>>*sigh*, ok, I'll do some testing next week when I get back from 
>>vacation, although I really think the burden of proof should be on you, 
>>given that you're the one suggesting we overturn thirty years of RDBMS 
>>and relational database theory, design, and practical usage,
>>    
>>
>
>OK, I take exception to this.  Am I really such a maverick?  Most of the
>people who have stated an opinion on the subject have expressed approval
>of my design.  Can we all be as naive as you say?
>  
>
I didn't say you or your supporters were naive, nor do I think you are.  
I only said that your suggestion is contrary to proven general and 
Bugzilla-specific database design principles, and thus the burden is on 
you to prove its superiority.

And I disagree that most people have approved of your design.  I count 
only Joel Peshkin, Maxwell Kanat-Alexander, Shane H. W. Travis, 
Christopher Hicks as having expressed a clear opinion in support of your 
solution in this thread, while Gervase Markham and Vlad Dascalu both 
seem to oppose it, and John Fisher, Kevin Benton, Bradley Baetz, and 
Nick Barnes have not expressed a clear position either way.

But even if all of those people supported your position, the sample size 
is too small for it to prove that your solution is preferable in the 
face of credible contrary evidence from the field.  We're a small group, 
and we could all be incorrect.

>Custom fields are a completely new kind of beast.  There is no precedent for
>them in Bugzilla's development history.  (Not in the core distribution,
>anyway; some partial solutions are attached to bug 91037.  I don't think
>that's what you're talking about, though.)  There's no a priori reason to
>apply past Bugzilla development techniques to them.
>  
>
Custom fields aren't very different from standard fields, and a number 
of our standard fields will become custom fields or reuse custom fields 
code once it's done.  But even if they weren't similar, there is plenty 
of precedent for them, as installations have been adding custom fields 
for years, often with real columns.

>What is this "column metaphor"?  Your design treats custom fields very
>differently than standard fields, applying more of a "table metaphor".
>  
>
My design uses real columns to represent fields, accounting for sparsity 
variance by putting dense columns into the bugs table (like the standard 
"severity" field, which lives in the bugs.bug_severity column) and 
sparse columns into their own tables (like the standard "duplicate of 
bug #"  field, which  lives in the duplicates.dupe_of column).  In both 
cases, however, each custom field is represented by its own unique 
database column, so the term "column metaphor" is apropo.

>>They're modifiable via SQL statements just as 
>>easily as the data within them is.  And while Bugzilla doesn't modify 
>>its schema very much today, there's nothing inherently more dangerous 
>>about it doing so.
>>    
>>
>
>But much less elegant.  To paraphrase Einstein, I think the schema ought to
>be as simple as possible, but no simpler.  Transmeta's Bugzilla installation
>has 187 custom fields.  A schema with in excess of 250 tables is not simple.
>Imagine trying to manage a schema of that size with a visual tool!
>  
>
Elegance, in this case, truly seems to be in the eye of the beholder.  
To my mind, FAC is more elegant because it uses the database system as 
it was designed to be used, and that makes it simpler (although not too 
simple to be useful).  And while it might be difficult to manage a 
schema with 250 tables using certain visual tools (f.e. an ER 
diagrammer), it wouldn't be with others (f.e. a list representation of 
tables).  Plus, at least it's possible to visualize FAC with standard 
visual tools, while it's not possible for FAD.  And visual overload in 
ER diagrammers can be overcome by limiting the scope of tables visualized.

>Later, [Myk] responding to Christopher Hicks:
>
>  
>
>>That doesn't mean we should store all meta-data as data.  We should use 
>>the right tool for the job, as we have already done with standard 
>>fields, for which we rightly use columns.
>>    
>>
>
>Yes, that is right, because all bugs share the same standard fields.  That
>condition is violated by custom fields.
>
Actually some standard fields are used only by certain products on some 
installations, and some installations never use certain standard 
fields.  That hasn't prevented those fields from serving Bugzilla well, 
so it is no reason to throw that storage model out (although it's worth 
tweaking it to store sparse fields in separate tables and converting 
frequently unused fields to custom fields).

>And, again, your proposal
>implements custom fields very differently from the way standard fields are
>implemented, anyway.
>  
>
Actually my proposal implements custom fields as columns within the bugs 
table or within their own table, just as Bugzilla does today with 
standard fields.

>Querying against N custom fields results in joins against N tables in your
>scheme.  In mine, it results in joins against T(N), the number of distinct
>datatypes among those N fields.  The total number of joins among those
>T(N) tables is N including repeated joins, but I suspect that it is still
>cheaper to access fewer tables.
>  
>
My tests, which include the queries you designed to showcase the 
performance of your approach, indicate otherwise.

>Consider also simply retrieving custom field data.  For a bug with twenty
>custom short string fields, your design would require SELECTs against
>twenty different tables; mine requires only one.
>  
>
This isn't strictly accurate, since under my proposal only sparse fields 
will live in separate tables.  But even in a worst-case scenario, 
retrieving data for a single bug is insignificantly expensive under both 
designs.

>I haven't analyzed your tests in detail yet--it's been a hassle getting
>MySQL 4 to peacefully coexist with my previous MySQL 3 system.  (By the way,
>if my design ignores thirty years of database theory, as you assert, why
>does yours require a recent version of MySQL to best it?)
>  
>
First of all, I said your design contradicts thirty years of database 
design theory, not performance optimization principles.  As I said from 
the beginning, performance isn't my only consideration when choosing a 
design.  Nevertheless, I expect a design conformant with standard 
database design principles to perform better, too, and my tests show 
that it does, even on MySQL 3.x (see below).

Second of all, my design does not require a recent version of MySQL.  I 
suggested MySQL 4.x+ because 3.x contains an inefficient fulltext 
indexer, so the fulltext indexes take too long to create on tables of 
the size in the test.  But you can run my tests on MySQL 3.x without 
creating fulltext indexes, and the results are the same: FAC wins in 
most cases, and with bigger margins.

(I've attached new versions of construct-tables.pl and 
test-performance.pl which don't create/use fulltext indexes by default 
(specify "--fulltext" on the command line to turn them back on) and work 
with MySQL 3.x, along with some test results from the machine "myk".)

Third of all, MySQL 3.x search results are relatively unimportant, 
because MySQL AB no longer recommends 3.x except in special cases (they 
now recommend 4.1, two generations newer than 3.x), Bugzilla will 
require MySQL 4.x in the near future (probably before a custom fields 
implementation lands), and 4.x is already preferable for Bugzilla today 
due to stability and fulltext performance.

>Can you describe exactly what was wrong with my test that it went from being
>3-4 times better to being nearly an order of magnitude worse?  I frankly
>find that hard to believe.
>  
>
I cannot.  I took the exact queries you ran, fixed a number of syntax 
errors in them that prevented them from running at all on my machines, 
plugged them into an automated script that runs each query six times 
(discarding the first result and averaging the rest), and flagged them 
SQL_NO_CACHE to prevent the cache from skewing the results (but this 
would not have affected comparisons between your tests and mine, since 
MySQL version 3.x doesn't have a query cache).

I ran the script on two different machines (holepunch and megalon) and 
reported their results.  I subsequently ran the script on a third 
machine (myk) and got similar results.  I have since run the tests 
against MySQL version 3.x on myk (skipping the fulltext index tests) and 
got similar results (attached).

So I cannot explain the variance, but I'm confident in the reliability 
of my testing code and results, and they're more apparently automated 
and have been tested on more machines, so I think it's your results 
which are errant.  In any case, I'm happy to provide all comers with the 
scripts for duplicating my tests, and I look forward to any additional 
results (and tests, and refinements of tests) anyone else can provide.

>I posted to comp.databases yesterday seeking advice regarding the merits of
>our two designs.  The subject of the thread is "Best database schema for
>object fields".  To date, the only poster to offer substantial criticism has
>stated "They both stink", but he did provide the useful information that the
>model I implemented has a name, EAV, or "Entity-Attribute-Value".
>
http://groups-beta.google.com/group/comp.databases/browse_frm/thread/aa5eca674b5a2073/a38a196ace5ef6b5#a38a196ace5ef6b5

Actually Celko said that both models are EAV, but he bases that claim on 
an error in your explanation of FAC which I've corrected in a followup.  
In reality, FAC is a standard ER modeling approach.

>Armed
>with that knowledge, I was able to Google several articles on the subject.
>A few were highly critical of EAV, but most were more balanced, listing
>advantages and disadvantages, and describing in what situations it's
>appropriate.
>
I did a similar search and found that EAV modeling has applicability in 
some specialized scientific and medical problem domains which experience 
extremely numerous, highly variable, and very sparse fields.  It is, 
however, rarely used otherwise, while FAC, which models dense attributes 
as bug table columns and sparse attributes as columns in separate 
tables, employs the standard ER modeling approach which is widely used 
by the majority of relational databases, especially those like Bugzilla.

>In all cases, though, the data model EAV was compared against
>was the classic all-columns-in-one-table approach; I could find no example
>of your one-table-per-field design.  (The crotchety poster in comp.databases
>described both of our designs as variants of EAV, but I can't really see how
>that's true.)  So, it's hard to accept your assertion that
>one-field-per-table is "what columns are for".  Can you refer me to any
>systems that use your design?
>  
>
Bugzilla, Bonsai, and Despot, to name only some Mozilla apps.  But of 
course now I'm talking about the ER modeling approach outlined above, 
not some one-table-per-field approach which I have never advocated.

>If I'm not mistaken, the long-term plan is to migrate standard fields to
>custom fields, so short-term discrepancies are not really relevant.
>  
>
Actually the long-term plan is to migrate some but not all standard 
fields to custom fields (some fields cannot be custom because their 
processing is too specialized, while others are common to [virtually] 
all bug tracking and so should be standard), and which fields are 
standard/custom can and will change over time (in both directions), so 
discrepancies between the two will remain relevant in all terms.

>>     Per my tests and standard database design theory, real columns are
>>     much faster than data columns.
>>    
>>
>
>Again, I find this hard to believe.  I suspect either some flaw in your test
>program, or some unfair advantage in the limited nature of the tests.
>  
>
Perhaps.  I doubt the flaw is in my test program, since it uses the same 
function to run and time all queries, whether FAC or FAD.  But the tests 
it runs are indeed pretty limited (consisting only of your tests and a 
few of my own), so it's quite possible for them to be unfairly 
advantageous--in either direction.  I welcome any improvement in them, 
but I still think the onus should be on you to prove EAV superiority, 
not on me to disprove it, given its nonstandard approach, and especially 
given documentation on the web about its niche value for certain extreme 
applications.

-myk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/7085d09a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: construct-tables.pl
Type: application/x-perl
Size: 5595 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/7085d09a/attachment.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-performance.pl
Type: application/x-perl
Size: 17870 bytes
Desc: not available
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/7085d09a/attachment-0001.pl>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050127/7085d09a/attachment-0001.html>

From suson at TuckerEnergy.com  Thu Jan 27 17:21:59 2005
From: suson at TuckerEnergy.com (Steven Suson)
Date: Thu, 27 Jan 2005 11:21:59 -0600
Subject: Custom fields schema
In-Reply-To: <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
Message-ID: <41F92337.8070106@TuckerEnergy.com>

    I have to agree whole heartedly with this. It seems every time that 
a discussion of custom fields begins, that it deteriorates into a flame 
war... And each and every time, the proposed contributor is nit picked 
to death, until the custom fields discussion dies away. Come on guys! 
MANY bugzilla users have wanted custom fields for several years now 
(including my company and I); remember that best is the enemy of good 
enough.

    Granted I'm not a relational purist, but having a seperate table for 
each custom field seems quite excessive. Perhaps it gives us better 
normalization, but at what cost? I back Sean on this one!

Steven Suson

Shane H. W. Travis wrote:

>On Thu, 27 Jan 2005, Myk Melez wrote:
>
>  
>
>>While weighing Sean's success with FAD at his installation, we should
>>also weigh the success of FAC on hundreds of Bugzilla installations for
>>a number of years, both for standard fields and for custom ones, not to
>>mention the general success of FAC in database design.
>>    
>>
>
>Something else to weigh: Are any of those 'hundreds of installations' (where
>do you get this figure from anyway?) making any effort to improve Bugzilla
>by re-committing their code? Do they have a developer who is willing to
>commit to the multiple re-writes and constant criticism that's going to be
>necessary to get a patch of this size and magnitude landed on the trunk?
>
>AIUI, Sean has already had to develop this locally -- because his bosses
>told him to. He is now trying to make the results of his efforts available
>to Bugzilla, because it's something that people have been griping about
>wanting done for the last five years... and he's basically being told to go
>piss up a rope because his design isn't good enough. Way to foster major
>contributions! Funny thing is that it's good enough to hold 187 custom
>fields at his site... but that's not good enough for us (or, more
>specifically, for Myk).
>
>If one of FAC/FAD were a complete abomination, and implementing it that way
>would be universally looked back on as a horrendous mistake... then
>absolutely I agree that the code shouldn't be taken just for the sake of
>having it...  but that doesn't seem to be the case here. There are benefits
>and trade-offs to each method. Each one has its proponents and its
>detractors, and this discussion is rapidly taking on some characteristics of
>a Religious Flame War.
>
>Working code (and dedicated developers) trumps beautiful theories nine times
>out of ten, in my books.
>
>Shane H.W. Travis       | The greatest of all mistakes is to do nothing
>travis at sedsystems.ca    |  because you can only do a little.
>Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=suson at tuckerenergy.com>
>
>  
>


From vladd at bugzilla.org  Thu Jan 27 19:35:31 2005
From: vladd at bugzilla.org (Vlad Dascalu)
Date: Thu, 27 Jan 2005 21:35:31 +0200
Subject: Custom fields schema
In-Reply-To: <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
Message-ID: <41F94283.3070200@bugzilla.org>

Shane, wrong asnwer.

Shane H. W. Travis wrote:

>AIUI, Sean has already had to develop this locally -- because his bosses
>told him to. He is now trying to make the results of his efforts available
>to Bugzilla, because it's something that people have been griping about
>wanting done for the last five years... and he's basically being told to go
>piss up a rope because his design isn't good enough.
>
This should come as no surprise to you. As you probably know, there are 
a lot of software cycles out there. However, most of them include some 
basics:
-> see the requirements
-> build a design
-> analyse the design (get feedback, analyse complexity, benchmark it)
-> go back to step 2 if you can improve it
-> perform low level design
-> code it

(the LLD stage might be placed in another spot for some cycles).

It should come as no surprise to either Sean or you that when you skip 
those steps and jump directly to the "code it" stage, you risk having 
the whole code invalidated and the need to redo from scratch. It's like 
heading from Madrid to Paris by airplane when the core team was still 
debating whether if airplane is a good idea or not compared to other 
means of transportation. Suggesting that we should take the code as it 
just because it's there really is againest all the review and design 
practices that improved Bugzilla code over the years.

> Way to foster major
>contributions!
>
Way to foster quality! Nobody worked together with the core team in 
order to perform the analysis stage of the development. I think it's 
unfair to skip this stage and to try to make the core team accept a 
suboptimal code without having either review or basic design stages.

> Funny thing is that it's good enough to hold 187 custom
>fields at his site... but that's not good enough for us (or, more
>specifically, for Myk).
>  
>
It's not good enough for the entire core team, AFAIK, well, maybe except 
you. Trying to isolate Myk and to forge pal-alliances based on your 
ideas and friends helps no one. Certainly it doesn't help Bugzilla 
development. Please leave the list of supporters (and the numbers on 
those lists, which apparently ignore me and the rest of the core team) 
aside. This is not how Bugzilla works. We don't have public polls 
regarding what code to checkin or not. We have a review procedure in 
place, and it's paramount regarding the quality of the code that's going 
to be checked in.

>If one of FAC/FAD were a complete abomination, and implementing it that way
>would be universally looked back on as a horrendous mistake... then
>absolutely I agree that the code shouldn't be taken just for the sake of
>having it...  but that doesn't seem to be the case here.
>
It certainly seems that way to me. Mind you, that's what we've been 
debating until now.

> There are benefits
>and trade-offs to each method. Each one has its proponents and its
>detractors, and this discussion is rapidly taking on some characteristics of
>a Religious Flame War.
>  
>
I saw it as a perfect rationale discussion until you and others tried to 
go down the "religious flame war". Please don't side-rail a productive 
discussion. Myk's, Mkanat's, even Sean's arguments all seemed rationale 
and very insightful. I don't see why you feel the need to stop it.

>Working code (and dedicated developers) trumps beautiful theories nine times
>out of ten, in my books.
>  
>
That's why probably in your book you need to rewrite the code in nine 
out of ten cases.

Vlad.


From bugreport at peshkin.net  Thu Jan 27 18:29:46 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Thu, 27 Jan 2005 10:29:46 -0800
Subject: Custom fields schema
In-Reply-To: <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
Message-ID: <41F9331A.5090509@peshkin.net>

Shane H. W. Travis wrote:

>On Thu, 27 Jan 2005, Myk Melez wrote:
>
>  
>
>>While weighing Sean's success with FAD at his installation, we should
>>also weigh the success of FAC on hundreds of Bugzilla installations for
>>a number of years, both for standard fields and for custom ones, not to
>>mention the general success of FAC in database design.
>>    
>>
>
>Something else to weigh: Are any of those 'hundreds of installations' (where
>do you get this figure from anyway?) making any effort to improve Bugzilla
>by re-committing their code? Do they have a developer who is willing to
>commit to the multiple re-writes and constant criticism that's going to be
>necessary to get a patch of this size and magnitude landed on the trunk?
>
>  
>
I believe that 'hundreds of installations' have hacked additional fields 
into the system in a manner that serves the purpose but is not landable 
in any way.  The people who have done this include people (such as me) 
who have made huge contributions to the product including OTHER features 
of equal or greater magnitude.  Features of this magnitude usually 
require someone who has it as their number one priority.  Any user who 
wants this badly enough can either invest that level of effort or hire 
one of the consultants to implement the feature and land it.

-Joel





From mkanat at kerio.com  Thu Jan 27 23:32:12 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Thu, 27 Jan 2005 15:32:12 -0800
Subject: Custom fields schema
In-Reply-To: <1106866185.12303.14.camel@localhost.localdomain>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>
	 <41F15E82.5060500@mozilla.org>
	 <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
	 <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>
	 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
	 <1106705126.3713.33.camel@localhost.localdomain>
	 <41F8F49C.1010506@mozilla.org>
	 <1106866185.12303.14.camel@localhost.localdomain>
Message-ID: <1106868732.12303.23.camel@localhost.localdomain>

> 	I just think that FAC will allow us to accomplish our goals for
> Bugzilla more easily.

	Opps. I meant "FAD", there. :-) Darn acronyms. :-)

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From afranke at ags.uni-sb.de  Thu Jan 27 06:54:15 2005
From: afranke at ags.uni-sb.de (afranke at ags.uni-sb.de)
Date: Thu, 27 Jan 2005 07:54:15 +0100
Subject: column selector / saving columns per query
In-Reply-To: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
Message-ID: <1106808855.41f8901777137@email.ags.uni-sb.de>

Quoting robzilla <rob2 at siklos.ca>:

> When you submit the query, it adds the 'columnlist' parameter to the
> buglist.cgi query string.  This specifies which columns should be displayed
> and in which order.

So to adopt the cmdline query tool, I could replace 

  wget -q -O ${outputfile} 
       --header="Cookie: COLUMNLIST=${COLUMNLIST-${defaultcolumnlist}}" 
       "${query}"

with

  wget -q -O ${outputfile}
       "${query}&columnlist=${COLUMNLIST-${defaultcolumnlist}}"

then?  That sounds fine to me.

> Implications:
> Since I got rid of the "Change Columns" page, there's no more support for
> "default columns" (saved in a cookie).  I didn't really see this as a
> problem, since the default columns are now saved with the default query (if
> you create one).

> For #1, I was thinking that we could give users who aren't logged in the
> option to save a default query, but it would be saved in a browser cookie
> instead of in the database.

Why not keep the cookie as the default, and have the columnlist URL parameter
override it, if present?  This way, you are backwards compatible, and avoid the
problem with not-logged-in users (AFAICS).

Cheers,
Andreas


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From sukria at sukria.net  Fri Jan 28 07:49:53 2005
From: sukria at sukria.net (Alexis Sukrieh)
Date: Fri, 28 Jan 2005 08:49:53 +0100
Subject: Upgrading from 2.16.7 to 2.18
Message-ID: <20050128074951.GA14171@sukria.net>

Hello there :)

The Debian packaging for 2.18 is ok and might enter experimental soon,
most of packaging issues were solved but one: 

When Upgrading from <= 2.16.7 to 2.18, I'd like to keep the old 'params'
file in order to restore the user defined settings (those that are
available through editparams.cgi).

Sadly, using a 2.16 version of 'params' in Bugzilla 2.18 does not seam
to be possible: CGIs say that there is something wrong with the params
file and ask for a second run of checksetup.pl.

When I run a second time checksetup.pl, the params file is the 2.18
default one and that mean that everything that was saved before is reset
to default 2.18 values.

Is there something in the way for migrating 'params' file from Bugzilla
version prior to 2.18 to 2.18? If not, is there a simple way to do that? 

I may contribute to such a development if needed.

Regards.

Alexis.

-- 
                                  Alexis Sukrieh <sukria at sukria.net>
                                               http://www.sukria.net

? Quidquid latine dictum sit, altum sonatur. ? 
Whatever is said in Latin sounds profound.



From rob2 at siklos.ca  Fri Jan 28 13:36:09 2005
From: rob2 at siklos.ca (Rob Siklos)
Date: Fri, 28 Jan 2005 08:36:09 -0500
Subject: column selector / saving columns per query
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com> <1106808855.41f8901777137@email.ags.uni-sb.de>
Message-ID: <01db01c5053e$53c33360$070aa8c0@adexainc.com>

> So to adopt the cmdline query tool, I could replace
>
>  wget -q -O ${outputfile}
>       --header="Cookie: COLUMNLIST=${COLUMNLIST-${defaultcolumnlist}}"
>       "${query}"
>
> with
>
>  wget -q -O ${outputfile}
>       "${query}&columnlist=${COLUMNLIST-${defaultcolumnlist}}"
>
> then?  That sounds fine to me.

Yes, but --- you can do this now!  For instance, try:

https://bugzilla.mozilla.org/buglist.cgi?product=Bugzilla&bug_status=ASSIGNED&bug_severity=critical&columnlist=assigned_to,short_desc

> Why not keep the cookie as the default, and have the columnlist URL 
> parameter
> override it, if present?  This way, you are backwards compatible, and 
> avoid the
> problem with not-logged-in users (AFAICS).
>

Yes - I think this is the way to go.

Rob. 



From gerv at mozilla.org  Fri Jan 28 15:44:42 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Fri, 28 Jan 2005 15:44:42 +0000
Subject: column selector / saving columns per query
In-Reply-To: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com>
Message-ID: <41FA5DEA.5050107@mozilla.org>

robzilla wrote:
> What do you guys think - is this trunk material, or better left as a 
> personal customization?

Potentially trunk material, although you'd need to solve the issues you 
list, and make sure that we behave no worse than before if JS is not 
turned on.

Gerv


From kevin.benton at amd.com  Fri Jan 28 18:08:21 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Fri, 28 Jan 2005 11:08:21 -0700
Subject: Custom fields schema
In-Reply-To: <41F8F28C.9060303@mozilla.org>
Message-ID: <20050128180822.175471FB1@ldcmail.amd.com>

Myk ? I?m concerned about some of the numbers I?m seeing from the result
times you posted.  I saw a number of queries at 50+ and assuming that?s in
seconds, to me, that just doesn?t cut it.  Please correct me if I'm wrong.

I need queries to run in under 1 second the first time they're run
consistently.  For example, in Real, on 1 str, you show the first query time
was 2.4 seconds, and the distributed query ran 56.2 seconds!  1 str bzlike
even in Real ran 17.8 seconds and from looking at the ref, it looks like
there was no index available.

>From what I can see, the fields as columns performance was *much* better
than the fields as data performance (myk-result-3.html).  This suggests to
me that this particular implementation is not going to work here.  I'm not
saying that a FAR method can not be developed that will perform within
expectations, but from the data presented, this particular method doesn't
look like it will suit my needs.

I am writing statuscount.cgi - a completely new reporting package for
Bugzilla to show my management the information they need out of Bugzilla to
help them effectively direct development.  I expect this report will be run
about one to five times a week.  This report currently executes eight
distinct queries of which six are complex.  So, if the queries are running
an average of 50+ seconds each first-time, it's going to take on the order
of five to six minutes for the manager to get the information they're
looking for.  That will prevent my managers from using my reports.  On the
other hand, if my report takes less than ten seconds, I will be doing okay.
When I'm reasonably close to being done with this reporting software, I will
release it to the Bugzilla community.  I've already got at least two non-AMD
testers evaluating it for me now.

Granted, I'm assuming that we're migrating to handling all the fields in a
unified way regardless of whether or not they're legacy or new.  Again, as I
said, please correct me if I'm wrong.  I just don't see this particular
implementation as viable.  Again, I really don't care which way we go - FAR
or FAC as long as it is easy to understand, performs within expectations,
and is scalable.  It seems to me that FAC is easier to grasp in my mind, but
if you or anyone else can make a solid case for FAR, great!

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
?
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.?
This communication may contain sensitive and/or confidential and/or
proprietary information.? Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.? This
communication is for the intended recipient(s) only.? If you have received
this communication in error, please notify the sender, then?destroy any
remaining copies of this communication.
?






From luis.villa at gmail.com  Fri Jan 28 18:21:24 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Fri, 28 Jan 2005 13:21:24 -0500
Subject: Custom fields schema
In-Reply-To: <20050128180822.175471FB1@ldcmail.amd.com>
References: <41F8F28C.9060303@mozilla.org>
	 <20050128180822.175471FB1@ldcmail.amd.com>
Message-ID: <2cb10c44050128102122f59975@mail.gmail.com>

On Fri, 28 Jan 2005 11:08:21 -0700, Kevin Benton <kevin.benton at amd.com> wrote:
> I am writing statuscount.cgi - a completely new reporting package for
> Bugzilla to show my management the information they need out of Bugzilla to
> help them effectively direct development.  I expect this report will be run
> about one to five times a week.  This report currently executes eight
> distinct queries of which six are complex.  So, if the queries are running
> an average of 50+ seconds each first-time, it's going to take on the order
> of five to six minutes for the manager to get the information they're
> looking for.  That will prevent my managers from using my reports.  On the
> other hand, if my report takes less than ten seconds, I will be doing okay.
> When I'm reasonably close to being done with this reporting software, I will
> release it to the Bugzilla community.  I've already got at least two non-AMD
> testers evaluating it for me now.

(1) We've found that for excessively complex queries, generating them
in cron and dumping them as HTML is useful. That is just the
unfortunate reality at times.

(2) GNOME would love to help you evaluate it as well :)

Luis


From dberlin at dberlin.org  Fri Jan 28 18:26:25 2005
From: dberlin at dberlin.org (Daniel Berlin)
Date: Fri, 28 Jan 2005 13:26:25 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <2cb10c44050128102122f59975@mail.gmail.com>
References: <41F8F28C.9060303@mozilla.org>  <20050128180822.175471FB1@ldcmail.amd.com>
 <2cb10c44050128102122f59975@mail.gmail.com>
Message-ID: <Pine.LNX.4.60.0501281324590.10874@dberlin.org>

>
> (1) We've found that for excessively complex queries, generating them
> in cron and dumping them as HTML is useful. That is just the
> unfortunate reality at times.
>
However, if you remember correctly, one of gnome's expensive reports, the 
weekly status summary, was slow because of deficiencies in mysql's 
query optimizer.
I changed the query ever so slightly to convince mysql to do it the right 
way, and it became roughly 10 times faster.

--Dan


From etzwane at schwag.org  Fri Jan 28 19:56:37 2005
From: etzwane at schwag.org (Sean McAfee)
Date: Fri, 28 Jan 2005 14:56:37 -0500
Subject: Custom fields schema
In-Reply-To: <41F8F28C.9060303@mozilla.org>
Message-ID: <20050128195638.3E3A5BC78@mail.schwag.org>

Myk Melez <myk at mozilla.org> wrote:
>And I disagree that most people have approved of your design.  I count 
>only Joel Peshkin, Maxwell Kanat-Alexander, Shane H. W. Travis, 
>Christopher Hicks as having expressed a clear opinion in support of your 
>solution in this thread, while Gervase Markham and Vlad Dascalu both 
>seem to oppose it, and John Fisher, Kevin Benton, Bradley Baetz, and 
>Nick Barnes have not expressed a clear position either way.

As I said, "most of the people who have stated an opinion".

>Custom fields aren't very different from standard fields, and a number 
>of our standard fields will become custom fields or reuse custom fields 
>code once it's done.  But even if they weren't similar, there is plenty 
>of precedent for them, as installations have been adding custom fields 
>for years, often with real columns.

Sure, but that's just because it's the quickest way to hack on additional
fields.  No one who only wanted a few more fields would seriously consider
going to the lengths I have to design and implement a new field
architecture.  This precedent is in no way an argument for FAC over FAD.

>My design uses real columns to represent fields, accounting for sparsity 
>variance by putting dense columns into the bugs table (like the standard 
>"severity" field, which lives in the bugs.bug_severity column) and 
>sparse columns into their own tables (like the standard "duplicate of 
>bug #"  field, which  lives in the duplicates.dupe_of column).

First of all, for installations at all similar to Transmeta's, sparse fields
are the norm, dense fields the exception:

mysql> create temporary table bugcount
    -> select product_id, count(*) as num_bugs
    -> from bugs
    -> group by product_id;
Query OK, 9 rows affected (0.01 sec)
Records: 9  Duplicates: 0  Warnings: 0

mysql> create temporary table fieldcount
    -> select product_id, count(*) as num_fields
    -> from cf_membership
    -> group by product_id;
Query OK, 9 rows affected (0.00 sec)
Records: 9  Duplicates: 0  Warnings: 0

mysql> select a.product_id, a.num_bugs, b.num_fields
    -> from bugcount as a, fieldcount as b
    -> where a.product_id = b.product_id;
+------------+----------+------------+
| product_id | num_bugs | num_fields |
+------------+----------+------------+
|          2 |     1892 |         60 |
|          4 |      129 |          2 |
|          5 |        3 |          3 |
|         12 |      198 |         42 |
|         13 |      578 |         28 |
|         14 |      220 |         14 |
|         15 |       52 |         28 |
|         16 |       34 |          6 |
|         17 |        6 |          2 |
+------------+----------+------------+
9 rows in set (0.00 sec)

There is minimal sharing of fields between products:

mysql> select field_id, count(*) as num_products
    -> from cf_membership
    -> group by field_id
    -> having count(*) >= 2;
+----------+--------------+
| field_id | num_products |
+----------+--------------+
|       64 |            2 |
|      310 |            2 |
+----------+--------------+
2 rows in set (0.00 sec)

A few more fields could conceivably have been shared, but it was more
convenient to import all products independently from our old Teamshare
database.  We use *none* of the standard fields version, rep_platform,
priority, resolution, severity, file_loc, or op_sys.

So, our most heavily-populated product has only 61% of the bugs and 32% of
the fields.  How should an administrator categorize this field or that as
"sparse" or "dense"?  What if he didn't know in advance the relative
populations of the products?

Furthermore, the classification of a field as sparse or dense can change
over time.  Consider the case of an installation that starts off with three
products, all of which share all custom fields.  Per your design, the
administrator makes them "dense" fields, stored as columns in BUGS.  Over
time seven more products are added, none of which require any of the
original fields.  If all of the products have comparable numbers of bugs and
fields, the original fields' density shrinks from 100% to 30%.  What then?

My design handles all such scenarios equally well, and requires neither
prescience nor hundreds of judgment calls on the part of the administrator.

>>And, again, your proposal
>>implements custom fields very differently from the way standard fields are
>>implemented, anyway.

>Actually my proposal implements custom fields as columns within the bugs 
>table or within their own table, just as Bugzilla does today with 
>standard fields.

What current standard fields live in their own tables?  I just wrote a quick
script to list all two-column tables for which the name of one column is
"bug_id", and found only BUG_GROUP_MAP, CC, and KEYWORDS.  All of these are
multi-valued "fields" that couldn't be easily made to live within BUGS
anyway.

>>Can you refer me to any
>>systems that use your design?

>Bugzilla, Bonsai, and Despot, to name only some Mozilla apps.  But of 
>course now I'm talking about the ER modeling approach outlined above, 
>not some one-table-per-field approach which I have never advocated.

You have, as a possibility:

]Of course, we don't have to put all of these columns into the bugs
]table.  We can do that, but we can also put each one into its own table
](so that bugs->custom field is a 1->0|1 relationship, and the database
]uses no more storage for the custom field than necessary), all of them
]into one other table, or some combination of these three, depending on
]what makes the most sense.

Also, your test program employed this type of schema, so I hope you can
understand my mistake.


--Sean


From rob2 at siklos.ca  Fri Jan 28 20:28:07 2005
From: rob2 at siklos.ca (Rob Siklos)
Date: Fri, 28 Jan 2005 15:28:07 -0500
Subject: column selector / saving columns per query
References: <009d01c50405$3d1aa0b0$070aa8c0@adexainc.com> <41FA5DEA.5050107@mozilla.org>
Message-ID: <029701c50577$e14f39c0$070aa8c0@adexainc.com>

Ok, so to recap, the issues with this patch (and my proposed solutions) are:

> 1) you don't get to save a default query unless you have a login ID

If you're logged in, default query is stored in the dbl;  otherwise, it's 
stored in a browser cookie.  Default columns are always part of the default 
query.

> 2) it only works for the "Advanced" search, and not the "Find a specific 
> bug." page

No problem - done.

> 3) make sure that we behave no worse than before if JS is not turned on

This one was a bit tricky.  Basically, it comes down to the fact that we 
need two completely separate interfaces - the one in the pictures, and 
another one that doesn't require JS.  If nobody is opposed to this type of 
double-coding, I don't mind doing it.

In the non-JS case, I wanted to just provide a link on the search page 
called "Show Display Options".  When you click on this link, it reloads the 
page with a bunch of checkboxes (like the current colchange.cgi).  However, 
without JS, I can't reload the page, since the submitting the form takes the 
user to buglist.cgi.  I can think of two solutions, none of which are very 
sexy:
a) to reload the page, submit to buglist.cgi with an extra parameter; 
buglist.cgi will notice this parameter and redirect back to query.cgi with 
the original POST params
b) when you display the display options without JS, reload the page without 
preserving the form data (annoying).

Any other comments/suggestions/ideas?

Thanks,

Rob. 



From mkanat at kerio.com  Fri Jan 28 20:50:06 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Fri, 28 Jan 2005 12:50:06 -0800
Subject: Custom fields schema
In-Reply-To: <20050128180822.175471FB1@ldcmail.amd.com>
References: <20050128180822.175471FB1@ldcmail.amd.com>
Message-ID: <1106945406.6018.5.camel@max.localdomain>

On Fri, 2005-01-28 at 11:08 -0700, Kevin Benton wrote:
> From what I can see, the fields as columns performance was *much* better
> than the fields as data performance (myk-result-3.html).  This suggests to
> me that this particular implementation is not going to work here.  I'm not
> saying that a FAR method can not be developed that will perform within
> expectations, but from the data presented, this particular method doesn't
> look like it will suit my needs.

	No query should ever take 50 seconds in reality unless the indexes are
off, or unless it actually has to return an immense amount of data that
must be read from the disk.

	I'm pretty sure that we will have to require a Bugzilla with
transactions instead of table locking, though, to get ideal performance
from custom fields in either method (though it could be particularly
applicable to FAD).

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
Kerio Technologies, Inc.
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-2500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From mkanat at kerio.com  Fri Jan 28 20:52:09 2005
From: mkanat at kerio.com (Maxwell Kanat-Alexander)
Date: Fri, 28 Jan 2005 12:52:09 -0800
Subject: Custom fields schema
In-Reply-To: <20050128195638.3E3A5BC78@mail.schwag.org>
References: <20050128195638.3E3A5BC78@mail.schwag.org>
Message-ID: <1106945529.6018.8.camel@max.localdomain>

	Sean, by the way -- I'm not sure you noticed my comments on the custom
fields bug from looking over your implementation, or if you got my
direct email, but I am fully willing to review your patches, provided
that we break it down into MANY, MANY bugs that incrementally get us
from where we are *now* in Bugzilla to where Custom Fields wants to be.

	In short, the custom fields bug should be a meta-bug.

	-Max




From kevin.benton at amd.com  Fri Jan 28 21:28:21 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Fri, 28 Jan 2005 14:28:21 -0700
Subject: Custom fields schema
In-Reply-To: <2cb10c44050128102122f59975@mail.gmail.com>
Message-ID: <20050128212821.BAFE41FB1@ldcmail.amd.com>

> (1) We've found that for excessively complex queries, generating them
> in cron and dumping them as HTML is useful. That is just the
> unfortunate reality at times.

For the queries I'm doing, it isn't acceptable to Cron the queries.  And if
I'm taking 60 seconds to run a query at ~3K records, how will that scale
when it's 100K+ records?  1M+ records?

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Luis Villa
> Sent: Friday, January 28, 2005 11:21 AM
> To: developers at bugzilla.org
> Subject: Re: Custom fields schema
> 
> On Fri, 28 Jan 2005 11:08:21 -0700, Kevin Benton <kevin.benton at amd.com>
> wrote:
> > I am writing statuscount.cgi - a completely new reporting package for
> > Bugzilla to show my management the information they need out of Bugzilla
> to
> > help them effectively direct development.  I expect this report will be
> run
> > about one to five times a week.  This report currently executes eight
> > distinct queries of which six are complex.  So, if the queries are
> running
> > an average of 50+ seconds each first-time, it's going to take on the
> order
> > of five to six minutes for the manager to get the information they're
> > looking for.  That will prevent my managers from using my reports.  On
> the
> > other hand, if my report takes less than ten seconds, I will be doing
> okay.
> > When I'm reasonably close to being done with this reporting software, I
> will
> > release it to the Bugzilla community.  I've already got at least two
> non-AMD
> > testers evaluating it for me now.
> 
> (1) We've found that for excessively complex queries, generating them
> in cron and dumping them as HTML is useful. That is just the
> unfortunate reality at times.
> 
> (2) GNOME would love to help you evaluate it as well :)
> 
> Luis
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From mkanat at kerio.com  Fri Jan 28 23:56:22 2005
From: mkanat at kerio.com (Max Kanat-Alexander)
Date: Fri, 28 Jan 2005 15:56:22 -0800
Subject: statuscount.cgi performance (WAS Re: Custom fields schema)
In-Reply-To: <20050128212821.BAFE41FB1@ldcmail.amd.com>
References: <20050128212821.BAFE41FB1@ldcmail.amd.com>
Message-ID: <1106956582.14810.1.camel@localhost.localdomain>

On Fri, 2005-01-28 at 14:28 -0700, Kevin Benton wrote:
> And if I'm taking 60 seconds to run a query at ~3K records, how will
> that scale when it's 100K+ records?  1M+ records?

	Well, thankfully, with indexes, it will scale very well. The only
problem with statuscount.cgi performance was indexes, and once we
resolved that, it ran pretty fast, as I recall. :-)

	-Max
-- 
Max Kanat-Alexander
Technical Support Manager, USA
2350 Mission College Blvd., Suite 400
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
http://www.kerio.com/support.html




From Tomas.Kopal at altap.cz  Sat Jan 29 06:45:21 2005
From: Tomas.Kopal at altap.cz (Tomas Kopal)
Date: Sat, 29 Jan 2005 17:15:21 +1030
Subject: Timestamp columns in Bugzilla
Message-ID: <41FB3101.9050909@altap.cz>

Hi all,
as Bug 257315 made it into the trunk, we have converted the last column 
with the timestamp type to normal datetime.
What that means for you is that if you'll be doing any changes in any of 
bugzilla DB tables, the database will never do any automatic 
timestamping for you. When needed, you have to do it explicitly. On the 
other hand, you don't need anything like "delta_ts=delta_ts" in your 
query if you don't want any change anymore.

Please, keep that on mind when hacking bugzilla :-).

Thanks

Tomas


From andreas.hoefler at bearingpoint.com  Fri Jan 28 07:33:24 2005
From: andreas.hoefler at bearingpoint.com (=?ISO-8859-1?Q?Andreas_H=F6fler?=)
Date: Fri, 28 Jan 2005 08:33:24 +0100
Subject: Custom fields schema
In-Reply-To: <1106866185.12303.14.camel@localhost.localdomain>
References: <20041224081704.cd36e999@mail.kerio.com> 
	<Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
	<41F15E82.5060500@mozilla.org> 
	<Pine.LNX.4.61.0501221050130.7454@skippy.fini.net> 
	<41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
	<1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> 
	<1106705126.3713.33.camel@localhost.localdomain> 
	<41F8F49C.1010506@mozilla.org> 
	<1106866185.12303.14.camel@localhost.localdomain>
Message-ID: <41F9EAC4.1070306@bearingpoint.com>

An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20050128/ee34b14c/attachment.html>
-------------- next part --------------
***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************

From dberlin at dberlin.org  Fri Jan 28 03:45:15 2005
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 27 Jan 2005 22:45:15 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41F92337.8070106@TuckerEnergy.com>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
 <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
 <41F92337.8070106@TuckerEnergy.com>
Message-ID: <Pine.LNX.4.60.0501272240500.2766@dberlin.org>



On Thu, 27 Jan 2005, Steven Suson wrote:

>   I have to agree whole heartedly with this. It seems every time that a 
> discussion of custom fields begins, that it deteriorates into a flame war... 
> And each and every time, the proposed contributor is nit picked to death, 
> until the custom fields discussion dies away. Come on guys! MANY bugzilla 
> users have wanted custom fields for several years now (including my company 
> and I); remember that best is the enemy of good enough.
>

I can't stress enough how true this is.

Myk, i hate to say it, because you are a valued bugzilla contributor, but 
unless you garner more support for your position (which nobody seems to 
have thrown their weight behind, no offense), i believe it is time to say 
"objection noted, let's move on".
This is not a design that is so flawed it is unusable, because there is an 
existence proof that it is usable.

If you truly believe your design is better, i believe it is time for 
you to implement a custom fields patch yourself, so we have two working 
patches to compare, instead of comparing "database theory" and "working 
code".


>
> Steven Suson
>
> Shane H. W. Travis wrote:
>
>> On Thu, 27 Jan 2005, Myk Melez wrote:
>> 
>> 
>>> While weighing Sean's success with FAD at his installation, we should
>>> also weigh the success of FAC on hundreds of Bugzilla installations for
>>> a number of years, both for standard fields and for custom ones, not to
>>> mention the general success of FAC in database design.
>>> 
>> 
>> Something else to weigh: Are any of those 'hundreds of installations' 
>> (where
>> do you get this figure from anyway?) making any effort to improve Bugzilla
>> by re-committing their code? Do they have a developer who is willing to
>> commit to the multiple re-writes and constant criticism that's going to be
>> necessary to get a patch of this size and magnitude landed on the trunk?
>> 
>> AIUI, Sean has already had to develop this locally -- because his bosses
>> told him to. He is now trying to make the results of his efforts available
>> to Bugzilla, because it's something that people have been griping about
>> wanting done for the last five years... and he's basically being told to 
>> go
>> piss up a rope because his design isn't good enough. Way to foster major
>> contributions! Funny thing is that it's good enough to hold 187 custom
>> fields at his site... but that's not good enough for us (or, more
>> specifically, for Myk).
>> 
>> If one of FAC/FAD were a complete abomination, and implementing it that 
>> way
>> would be universally looked back on as a horrendous mistake... then
>> absolutely I agree that the code shouldn't be taken just for the sake of
>> having it...  but that doesn't seem to be the case here. There are 
>> benefits
>> and trade-offs to each method. Each one has its proponents and its
>> detractors, and this discussion is rapidly taking on some characteristics 
>> of
>> a Religious Flame War.
>> 
>> Working code (and dedicated developers) trumps beautiful theories nine 
>> times
>> out of ten, in my books.
>> 
>> Shane H.W. Travis       | The greatest of all mistakes is to do nothing
>> travis at sedsystems.ca    |  because you can only do a little.
>> Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith
>> -
>> To view or change your list settings, click here:
>> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=suson at tuckerenergy.com>
>> 
>> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dberlin at dberlin.org>
>


From dberlin at dberlin.org  Fri Jan 28 04:05:31 2005
From: dberlin at dberlin.org (Daniel Berlin)
Date: Thu, 27 Jan 2005 23:05:31 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41F94283.3070200@bugzilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
 <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
 <41F94283.3070200@bugzilla.org>
Message-ID: <Pine.LNX.4.60.0501272245330.2766@dberlin.org>

>> Way to foster major
>> contributions!
>> 
> Way to foster quality! Nobody worked together with the core team in order to 
> perform the analysis stage of the development.I think it's unfair to skip 
> this stage and to try to make the core team accept a suboptimal code without 
> having either review or basic design stages.


I'm a usually silent observer here, but i've watched what is happening now 
happen time and time again, and it's always the same arguments on both 
sides.
I'll also note that one of the reasons i don't work with the core team 
before i implement gcc features is because i have the distinct impression 
(from watching the bugzilla bug reports and mailing lists for years 
now) that some members of the core team believe it is their way, or the 
highway, and i don't have time to theoretically masturbate over bug system 
design.  Unless some  other design for one of my gcc bugzilla patches is 
going to be wildly easier to maintain, it's just not worth the time.  This 
is not the same as saying i believe i should be able to contribute a bunch 
of complete hacks.  However, too often people here seem to delve into 
design issues that are way too picky for a system of the complexity of 
bugzilla.

Effectively claiming that we can't get to some good place starting 
with sean's design and code, and incrementally improving it (IE 
making the rest of it acceptable, committing it, and improving it as we go 
along) is just not a good argument to me.
I've seen it done in every open source project i've ever worked 
on[1].
You know what?
Unless the design just plain can't work, you can do this, and you know 
what, it makes the users and developers a *lot* happier, because they have 
*something*, instead of *nothing*.

Sean's design meets the requirements of being a sane custom fields 
implementation.  He is willing to conform his *code* in order to meet the 
other design requirements of a custom fields implementation for bugzilla.

His existing design may not be the most performant, or whatever, but it 
works, and it is a starting point.

These are just fields and tables in a database.
We can always migrate.

Or do you want to wait a few years for the next guy to try to make a 
custom fields patch, and then we can beat him down too for it not being 
theoretically perfect, when we could have spent the time turning something 
we've got *now*, into what we wanted, by then.


--Dan
[1] Hell,we just, over the course of 2 years, added a new SSA based middle 
end to GCC (which had no middle end, and for that matter, no well-defined 
interface between the frontends and the backend).
The starting design was incrementally improved into something wildly
different. Yes it required some coding changes on the part of people
working on new optimizers. I was one of these people.
You know what?
It was better to have to change large amounts of my code because diego 
decided some abstraction wasn't giving us the information or performance 
we needed, than it would have been to sit there and do nothing while he 
sat around for 3 years trying to design the perfect interfaces and 
abstraction level.  It never would have been completed had we done it that 
way.


From luis.villa at gmail.com  Sat Jan 29 17:37:07 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Sat, 29 Jan 2005 12:37:07 -0500
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.60.0501272245330.2766@dberlin.org>
References: <20041224081704.cd36e999@mail.kerio.com>
	 <41F5919F.4030906@mozilla.org> <41F5D907.4050406@bugzilla.org>
	 <1106652810.10792.1.camel@max.localdomain>
	 <41F6C45B.2080901@mozilla.org>
	 <1106705126.3713.33.camel@localhost.localdomain>
	 <41F8F49C.1010506@mozilla.org>
	 <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
	 <41F94283.3070200@bugzilla.org>
	 <Pine.LNX.4.60.0501272245330.2766@dberlin.org>
Message-ID: <2cb10c440501290937483e4e72@mail.gmail.com>

Amen, on /all/ counts.
Luis


On Thu, 27 Jan 2005 23:05:31 -0500 (EST), Daniel Berlin
<dberlin at dberlin.org> wrote:
> >> Way to foster major
> >> contributions!
> >>
> > Way to foster quality! Nobody worked together with the core team in order to
> > perform the analysis stage of the development.I think it's unfair to skip
> > this stage and to try to make the core team accept a suboptimal code without
> > having either review or basic design stages.
> 
> 
> I'm a usually silent observer here, but i've watched what is happening now
> happen time and time again, and it's always the same arguments on both
> sides.
> I'll also note that one of the reasons i don't work with the core team
> before i implement gcc features is because i have the distinct impression
> (from watching the bugzilla bug reports and mailing lists for years
> now) that some members of the core team believe it is their way, or the
> highway, and i don't have time to theoretically masturbate over bug system
> design.  Unless some  other design for one of my gcc bugzilla patches is
> going to be wildly easier to maintain, it's just not worth the time.  This
> is not the same as saying i believe i should be able to contribute a bunch
> of complete hacks.  However, too often people here seem to delve into
> design issues that are way too picky for a system of the complexity of
> bugzilla.
> 
> Effectively claiming that we can't get to some good place starting
> with sean's design and code, and incrementally improving it (IE
> making the rest of it acceptable, committing it, and improving it as we go
> along) is just not a good argument to me.
> I've seen it done in every open source project i've ever worked
> on[1].
> You know what?
> Unless the design just plain can't work, you can do this, and you know
> what, it makes the users and developers a *lot* happier, because they have
> *something*, instead of *nothing*.
> 
> Sean's design meets the requirements of being a sane custom fields
> implementation.  He is willing to conform his *code* in order to meet the
> other design requirements of a custom fields implementation for bugzilla.
> 
> His existing design may not be the most performant, or whatever, but it
> works, and it is a starting point.
> 
> These are just fields and tables in a database.
> We can always migrate.
> 
> Or do you want to wait a few years for the next guy to try to make a
> custom fields patch, and then we can beat him down too for it not being
> theoretically perfect, when we could have spent the time turning something
> we've got *now*, into what we wanted, by then.
> 
> --Dan
> [1] Hell,we just, over the course of 2 years, added a new SSA based middle
> end to GCC (which had no middle end, and for that matter, no well-defined
> interface between the frontends and the backend).
> The starting design was incrementally improved into something wildly
> different. Yes it required some coding changes on the part of people
> working on new optimizers. I was one of these people.
> You know what?
> It was better to have to change large amounts of my code because diego
> decided some abstraction wasn't giving us the information or performance
> we needed, than it would have been to sit there and do nothing while he
> sat around for 3 years trying to design the perfect interfaces and
> abstraction level.  It never would have been completed had we done it that
> way.
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=luis.villa at gmail.com>
>


From bugreport at peshkin.net  Sat Jan 29 17:22:28 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Sat, 29 Jan 2005 09:22:28 -0800
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.60.0501272245330.2766@dberlin.org>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca> <41F94283.3070200@bugzilla.org> <Pine.LNX.4.60.0501272245330.2766@dberlin.org>
Message-ID: <41FBC654.1060706@peshkin.net>


OK,  time for me to join the chous....  we need this. 

As long as it causes no MAJOR regression on sites not making heavy use 
of custom fields and does not make a MAJOR mess of the code, we should 
get this in.  Myk, Justdave -- can you live with this?

I stated my wish list for this a long time ago.  I won't restate it here.



From chris.cranford at tkdsoftware.com  Sat Jan 29 21:28:23 2005
From: chris.cranford at tkdsoftware.com (chris.cranford at tkdsoftware.com)
Date: Sat, 29 Jan 2005 16:28:23 -0500
Subject: Bugzilla Templates
Message-ID: <1107034804@distinctinnovations.com>

Is there such a site or place where pre-customized templates for Bugzilla
already exist that administrators can download and use besides the standard
Bugzilla templates which come with the install?

Thanks 



From gerv at mozilla.org  Sun Jan 30 15:46:56 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 30 Jan 2005 15:46:56 +0000
Subject: Bugzilla Templates
In-Reply-To: <1107034804@distinctinnovations.com>
References: <1107034804@distinctinnovations.com>
Message-ID: <41FD0170.3030400@mozilla.org>

chris.cranford at tkdsoftware.com wrote:
> Is there such a site or place where pre-customized templates for Bugzilla
> already exist that administrators can download and use besides the standard
> Bugzilla templates which come with the install?

Apart from localisations, no. Are you trying to change Bugzilla's look? 
That's what the new skins system is for, although no-one has yet written 
any alternative skins.

Gerv


From bugzilla at glob.com.au  Sun Jan 30 16:05:46 2005
From: bugzilla at glob.com.au (byron)
Date: Mon, 31 Jan 2005 00:05:46 +0800 (WST)
Subject: Bugzilla Templates
Message-ID: <20050130160546.915EA4BC724@sweep.bur.st>

> Apart from localisations, no. Are you trying to change Bugzilla's look? 
> That's what the new skins system is for, although no-one has yet written 
> any alternative skins.

/me tries to get the ball rolling

http://bugzilla.glob.com.au/skins/

one skin, same one i submitted to bug 279896 with a handful of changes. 


-b

begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From chris.cranford at tkdsoftware.com  Sun Jan 30 16:33:56 2005
From: chris.cranford at tkdsoftware.com (chris.cranford at tkdsoftware.com)
Date: Sun, 30 Jan 2005 11:33:56 -0500
Subject: Bugzilla Templates
In-Reply-To: <1107101474@distinctinnovations.com>
Message-ID: <1107102836@distinctinnovations.com>

On 1/30/2005 11:05 AM, DEVELOPERS at BUGZILLA.ORG wrote to CHRIS CRANFORD:

Alright I extracted the tarball into skins/custom; however I dont see any 
difference when my pages load.  Is there a specific configuration param I
have to set in a perl script or something that tells Bugzilla to look in
the skins/custom directory?  I'm using 2.18rc3

Thanks
Chris

-> > Apart from localisations, no. Are you trying to change Bugzilla's look? 
-> > That's what the new skins system is for, although no-one has yet written 
-> > any alternative skins.
-> 
-> /me tries to get the ball rolling
-> 
-> http://bugzilla.glob.com.au/skins/
-> 
-> one skin, same one i submitted to bug 279896 with a handful of changes. 
-> 
-> 
-> -b
-> 
-> begin-base64 644 signature.gif
-> R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
-> XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
-> h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
-> N1PRMXimiLUGt3ElVimlgbllWAAAOw==
-> ====
-> 
-> -
-> To view or change your list settings, click here:
-> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=chris.cranford at tkdsoftware.com>

 



From chicks at chicks.net  Sun Jan 30 14:25:31 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Sun, 30 Jan 2005 09:25:31 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.60.0501272240500.2766@dberlin.org>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
 <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
 <41F92337.8070106@TuckerEnergy.com> <Pine.LNX.4.60.0501272240500.2766@dberlin.org>
Message-ID: <Pine.LNX.4.61.0501300913400.23307@skippy.fini.net>

On Thu, 27 Jan 2005, Daniel Berlin wrote:
> On Thu, 27 Jan 2005, Steven Suson wrote:
>>   I have to agree whole heartedly with this. It seems every time that a 
>> discussion of custom fields begins, that it deteriorates into a flame 
>> war... And each and every time, the proposed contributor is nit picked to 
>> death, until the custom fields discussion dies away. Come on guys! MANY 
>> bugzilla users have wanted custom fields for several years now (including 
>> my company and I); remember that best is the enemy of good enough.
>> 
>
> I can't stress enough how true this is.
>
> Myk, i hate to say it, because you are a valued bugzilla contributor, but 
> unless you garner more support for your position (which nobody seems to have 
> thrown their weight behind, no offense), i believe it is time to say 
> "objection noted, let's move on".
> This is not a design that is so flawed it is unusable, because there is an 
> existence proof that it is usable.
>
> If you truly believe your design is better, i believe it is time for you to 
> implement a custom fields patch yourself, so we have two working patches to 
> compare, instead of comparing "database theory" and "working code".

Abso-bleeping-lutely.  Props to Steven and Daniel for jumping into the 
melee that is custom fields.

There seems to be somewhat broad agreement on a few points:

(1) Anybody who tried to get a design approved by the bugzilla community 
before implementing custom fields would never start implementing.

(2) A workable implementation exists and people seem to be falling back in 
the quagmire of (1).

(3) Working code should trump theory, but its not.  As a long time 
pedantic a*hole myself I truly sympathise with the purists... but this 
situation lost its "virginity" so long ago that purity and idealism 
haven't fit for a long time.

One other red herring that I'm tired of seeing is that we're stuck with a 
bad implementation and that another lump of checksetup.pl tweaking can't 
move us to another way of doing things.  If FAC and FAD are implementing 
the same fields in different ways then there is a one-to-one mapping 
between how something would be represented in each and there's an 
algorithm for converting them.  It would seem easier for the FAC purists 
to patch something that works so that it works they way they want than to 
start over.  (But since the purists are busy arguing against somebody who 
made a major accomplishment no progress on either has been made.)

Yet another red herring is that big changes are bad.  Something like 
custom fields is something that by its very nature is a big change. 
Splitting it up into a dozen chunks doesn't change this fact and is just 
a pointless exercise in fitting a 10 pound bad of salt through a one pound 
slot.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From gerv at mozilla.org  Sun Jan 30 23:58:32 2005
From: gerv at mozilla.org (Gervase Markham)
Date: Sun, 30 Jan 2005 23:58:32 +0000
Subject: Custom fields schema
In-Reply-To: <Pine.LNX.4.61.0501300913400.23307@skippy.fini.net>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca> <41F92337.8070106@TuckerEnergy.com> <Pine.LNX.4.60.0501272240500.2766@dberlin.org> <Pine.LNX.4.61.0501300913400.23307@skippy.fini.net>
Message-ID: <41FD74A8.1050706@mozilla.org>

Christopher Hicks wrote:
> One other red herring that I'm tired of seeing is that we're stuck with 
> a bad implementation and that another lump of checksetup.pl tweaking 
> can't move us to another way of doing things.  

Without commenting on any of the other issues, I don't see this as a red 
herring. While in theory it's probably true that one could convert from 
FAC to FAD using checksetup.pl, in practice such a thing is more complex 
than any other dynamic schema change we've ever tried, and would be hard 
to write and liable to fail in unexpected ways due to the "meta" nature 
of custom fields and the fact that we can't predict what people will use 
them for. It would never happen.

I certainly agree that endless debate is bad - but the correct way to 
deal with endless debate is for the person charged with ending it to 
bring it to an end. Dave should step up and make a decision - FAC or 
FAD. The fact that one has an implementation available is certainly a 
factor in that decision, but should not by itself be conclusive.

Gerv


From justdave at bugzilla.org  Mon Jan 31 00:42:12 2005
From: justdave at bugzilla.org (David Miller)
Date: Sun, 30 Jan 2005 19:42:12 -0500
Subject: Custom Fields stuff
Message-ID: <41FD7EE4.5050508@bugzilla.org>

Just a quick note to let everyone know (in case you didn't already know 
through other channels) that I was offline most of last week, and the 
custom fields related threads seem to have exploded while I was gone. 
The size of that explosion can only mean there's debate going on (and 
I've heard that there is from other folks, too), and there's probably 
something I need to settle.  That said, I'm now faced with a huge amount 
of reading to get caught up.  If you all could give me a day or two yet 
to get caught up before you all explode on each other, I'd appreciate 
it.  Then I'll chime in and let you know where I stand on this.

I've got about 70 unread messages on this mailing list right now

-- 
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Foundation       http://www.mozilla.org/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/


From bugzilla at glob.com.au  Mon Jan 31 01:46:12 2005
From: bugzilla at glob.com.au (byron)
Date: Mon, 31 Jan 2005 09:46:12 +0800 (WST)
Subject: Bugzilla Templates
Message-ID: <20050131014612.835C94BC0F6@sweep.bur.st>

> Alright I extracted the tarball into skins/custom; however I dont see any 
> difference when my pages load.  Is there a specific configuration param I
> have to set in a perl script or something that tells Bugzilla to look in
> the skins/custom directory?  I'm using 2.18rc3

sorry, you'll need bugzilla 2.19 to use the skin in its current form.



begin-base64 644 signature.gif
R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p
XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf
h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH
N1PRMXimiLUGt3ElVimlgbllWAAAOw==
====



From Nick.Barnes at pobox.com  Mon Jan 31 14:25:59 2005
From: Nick.Barnes at pobox.com (Nick Barnes)
Date: Mon, 31 Jan 2005 14:25:59 +0000
Subject: Custom fields schema
In-Reply-To: <41F8F28C.9060303@mozilla.org> 
   from Myk Melez <myk@mozilla.org> 
   of "Thu, 27 Jan 2005 05:54:20 -0800"
Message-ID: <67863.1107181559@thrush.ravenbrook.com>

At 2005-01-27 13:54:20+0000, Myk Melez writes:

> And I disagree that most people have approved of your design.  I count 
> only Joel Peshkin, Maxwell Kanat-Alexander, Shane H. W. Travis, 
> Christopher Hicks as having expressed a clear opinion in support of your 
> solution in this thread, while Gervase Markham and Vlad Dascalu both 
> seem to oppose it, and John Fisher, Kevin Benton, Bradley Baetz, and 
> Nick Barnes have not expressed a clear position either way.

FWIW, I like Sean's design.  I think it's acceptable from a database
design standpoint, but mainly it's infinitely better than any
alternative because it represents actual working code right now, and
is therefore a realistic candidate for actually getting into the trunk
before we all die of old age.

I've said before that getting working code into the trunk, given a
half-way reasonable [*] design and some thought about extensibility
[*2], should trump everything, including a degree of performance.

Nick B

[*] Yes, I know that this whole discussion revolves around a
disagreement over what constitutes "reasonable" here.

[*2] to address the huge wishlist of custom-field features,
e.g. multiple datatypes, per-product fields, access controls,
multi-selects, interactive form design, makes the tea.



From kevin.benton at amd.com  Mon Jan 31 15:54:35 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Mon, 31 Jan 2005 08:54:35 -0700
Subject: statuscount.cgi performance (WAS Re: Custom fields schema)
In-Reply-To: <1106956582.14810.1.camel@localhost.localdomain>
Message-ID: <20050131155435.912141FB1@ldcmail.amd.com>

Yes, however, MySQL (in 3.x) apparently won't use more than one index per
table.  Since there's an awful lot of data to go through to get to the point
where I can extract the necessary information, I just don't see how FAR will
work at this point without being able to sub-index.  Again, I'm glad to be
proven wrong.

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 
 
> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Max Kanat-Alexander
> Sent: Friday, January 28, 2005 4:56 PM
> To: developers at bugzilla.org
> Subject: statuscount.cgi performance (WAS Re: Custom fields schema)
> 
> On Fri, 2005-01-28 at 14:28 -0700, Kevin Benton wrote:
> > And if I'm taking 60 seconds to run a query at ~3K records, how will
> > that scale when it's 100K+ records?  1M+ records?
> 
> 	Well, thankfully, with indexes, it will scale very well. The only
> problem with statuscount.cgi performance was indexes, and once we
> resolved that, it ran pretty fast, as I recall. :-)
> 
> 	-Max
> --
> Max Kanat-Alexander
> Technical Support Manager, USA
> 2350 Mission College Blvd., Suite 400
> Santa Clara, CA 95054
> Phone: (408) 496-4500
> Fax: (408) 496-6902
> http://www.kerio.com/support.html
> 
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton at amd.com>





From bugreport at peshkin.net  Mon Jan 31 16:02:19 2005
From: bugreport at peshkin.net (Joel Peshkin)
Date: Mon, 31 Jan 2005 08:02:19 -0800
Subject: statuscount.cgi performance (WAS Re: Custom fields schema)
In-Reply-To: <20050131155435.912141FB1@ldcmail.amd.com>
References: <20050131155435.912141FB1@ldcmail.amd.com>
Message-ID: <41FE568B.4080501@peshkin.net>

Kevin Benton wrote:

>Yes, however, MySQL (in 3.x) apparently won't use more than one index per
>table.  Since there's an awful lot of data to go through to get to the point
>where I can extract the necessary information, I just don't see how FAR will
>work at this point without being able to sub-index.  Again, I'm glad to be
>proven wrong.
>
>  
>

We have a general consensus that sites with an interest in DB 
Performance should be on MySQL 4.something.  Does the same concern apply 
there?



From travis at SEDSystems.ca  Mon Jan 31 17:17:13 2005
From: travis at SEDSystems.ca (Shane H. W. Travis)
Date: Mon, 31 Jan 2005 11:17:13 -0600 (CST)
Subject: Bugzilla Blues
Message-ID: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>


Been enough sniping back and forth on this list lately that I figured we
could all do with a bit of a break. This whole thing came to me in about 15
minutes, so I'm obviously inspired. ;-)

I know just how it sounds in my head, but I don't know enough guitar to
write out the chords or anything. It's a pretty standard walking-bass blues
riff that I'm sure most of you have all heard before. So now, without
further waffling, I present to you...

...........................................................................

The Bugzilla Blues
==================
(verse 1)
Oh, my Voting button's broken
All my Bugmail is returned
My Comments go unheeded and my bugs go UNCONFIRMED
(Chorus)
Got them... Bugzilla blues...
I just wants to be free...
Why is this Open-Source project so closed to the likes of me

(verse2)
Well, Dave won't approve my patches...
Myk don't like my design
Nobody reviews me, all that I can do is Whine
(Chorus)
Got them... Bugzilla blues...
Code Just Wants To Be Free...
Why is this Open-Source project so closed to the likes of me?

(wailing harmonica solo)

(Bridge)
Maxwell says it's got to be in smaller pieces
Jouni says my indentation's shot
Gerv is busy fussin' 'bout the date of the releases
while all my patches sit upon the vine and rot

(verse 3)
Well I got so tired of trying
That I sat and wrote this song
And then Vlad came by and criticized, "You're singing it all wrong!"
(Chorus)
Got them... Bugzilla blues...
I just wants to be free...
Why is this Open-Source project so closed to the likes of me?

...........................................................................


Thank yew... thank yew ver' much.


We now return you to your regularly scheduled kvetching.


Shane H.W. Travis       | The greatest of all mistakes is to do nothing
travis at sedsystems.ca    |  because you can only do a little.
Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith


From luis.villa at gmail.com  Mon Jan 31 17:39:57 2005
From: luis.villa at gmail.com (Luis Villa)
Date: Mon, 31 Jan 2005 12:39:57 -0500
Subject: Bugzilla Blues
In-Reply-To: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>
References: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>
Message-ID: <2cb10c4405013109391a5f5037@mail.gmail.com>

Well, it made me laugh, at least. Thanks, Shane ;)

Luis


On Mon, 31 Jan 2005 11:17:13 -0600 (CST), Shane H. W. Travis
<travis at sedsystems.ca> wrote:
> 
> Been enough sniping back and forth on this list lately that I figured we
> could all do with a bit of a break. This whole thing came to me in about 15
> minutes, so I'm obviously inspired. ;-)
> 
> I know just how it sounds in my head, but I don't know enough guitar to
> write out the chords or anything. It's a pretty standard walking-bass blues
> riff that I'm sure most of you have all heard before. So now, without
> further waffling, I present to you...
> 
> ...........................................................................
> 
> The Bugzilla Blues
> ==================
> (verse 1)
> Oh, my Voting button's broken
> All my Bugmail is returned
> My Comments go unheeded and my bugs go UNCONFIRMED
> (Chorus)
> Got them... Bugzilla blues...
> I just wants to be free...
> Why is this Open-Source project so closed to the likes of me
> 
> (verse2)
> Well, Dave won't approve my patches...
> Myk don't like my design
> Nobody reviews me, all that I can do is Whine
> (Chorus)
> Got them... Bugzilla blues...
> Code Just Wants To Be Free...
> Why is this Open-Source project so closed to the likes of me?
> 
> (wailing harmonica solo)
> 
> (Bridge)
> Maxwell says it's got to be in smaller pieces
> Jouni says my indentation's shot
> Gerv is busy fussin' 'bout the date of the releases
> while all my patches sit upon the vine and rot
> 
> (verse 3)
> Well I got so tired of trying
> That I sat and wrote this song
> And then Vlad came by and criticized, "You're singing it all wrong!"
> (Chorus)
> Got them... Bugzilla blues...
> I just wants to be free...
> Why is this Open-Source project so closed to the likes of me?
> 
> ...........................................................................
> 
> Thank yew... thank yew ver' much.
> 
> We now return you to your regularly scheduled kvetching.
> 
> 
> Shane H.W. Travis       | The greatest of all mistakes is to do nothing
> travis at sedsystems.ca    |  because you can only do a little.
> Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=luis.villa at gmail.com>
>


From kevin.benton at amd.com  Mon Jan 31 17:45:39 2005
From: kevin.benton at amd.com (Kevin Benton)
Date: Mon, 31 Jan 2005 10:45:39 -0700
Subject: Bugzilla Blues
In-Reply-To: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>
Message-ID: <20050131174539.BFF501FB1@ldcmail.amd.com>


> Thank yew... thank yew ver' much.
> 

LOL!  That was funny!

> We now return you to your regularly scheduled kvetching.
> 

Kvetch this!  :)

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have received
this communication in error, please notify the sender, then destroy any
remaining copies of this communication.
 





From paulo.casanova at link.pt  Mon Jan 31 15:21:36 2005
From: paulo.casanova at link.pt (Paulo Casanova)
Date: Mon, 31 Jan 2005 15:21:36 +0000
Subject: Custom fields schema
In-Reply-To: <41F94283.3070200@bugzilla.org>
References: <20041224081704.cd36e999@mail.kerio.com>  <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca>  <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org>  <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org> <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org> <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca> <41F94283.3070200@bugzilla.org>
Message-ID: <41FE4D00.1080507@link.pt>


Hi all!

I was away on (lovely :)) holidays and when I came I was (positively) 
suprised to see so much discussion. We have been working (internally) on 
CF for quite some time but with a very different approach.

I fell some degree of unrealism on these discussions on CF 
implementations. Firstly, I see too much emphasis on FAC and FAD and 
RDBMS theory. I work with SGBDs for several years and can state with 
that, with MySQL, they're both irrelevant. Either will work. MySQL is 
(1) too limited and (2) too good within its limits.

[Some unimportant notes to support what I'm saying: if you'd be working 
with Oracle things would be much different because other factors such as 
histogram computation, query optimization, index analysis, locking 
policy and other "features" might make both designs work with very 
different levels of performance on different usage patterns. With MySQL, 
however, I think we're discussing peanuts.]

Unfortunately I see too much discussion on *how it does* instead of 
*what it does*.

My opinion, anyway, if it is at all relevant, is that other problems 
should be taken care of before discussing FAC or FAD.

Actually, because I have read hundreds or emails today on BZ and are, 
therefore, somewhat lost, I would like to pose a simple question: do we 
know already *what* are we going to do? I mean, what functionalities 
will CF provide?

1. Can we have typed CFs? Dates, numbers, floats, URLs or it is just text?
2. Are there validation rules for CFs? Plug-ins, regexs?
3. Can we have "derived" or "computed" CFs?
4. Are complex datatypes (such as timetracking) implementable as CFs?
5. Can we make our own plug-ins for data validation?
6. How will we decide which CFs are available for each bug? Are all CFs 
available for all bugs? Can CFs be enabled/ disabled or shown/ hidden 
based on other field values?

BTW, we do have some effort available to work on this but we need a plan 
:( I see too much flame and too little fuel :). I would much prefer 
using available effort to support BZ's standard implementation and, 
honestly, I don't give a damn on whether we FAC or FAD... and I think 
nobody will... ever.

Best,
Paulo




From chicks at chicks.net  Mon Jan 31 17:09:27 2005
From: chicks at chicks.net (Christopher Hicks)
Date: Mon, 31 Jan 2005 12:09:27 -0500 (EST)
Subject: Custom fields schema
In-Reply-To: <41FD74A8.1050706@mozilla.org>
References: <20041224081704.cd36e999@mail.kerio.com> 
 <Pine.GHP.4.58.0412241113540.16159@milhouse.SEDSystems.ca> 
 <41F15E82.5060500@mozilla.org>  <Pine.LNX.4.61.0501221050130.7454@skippy.fini.net>
  <41F5919F.4030906@mozilla.org>  <41F5D907.4050406@bugzilla.org> 
 <1106652810.10792.1.camel@max.localdomain>  <41F6C45B.2080901@mozilla.org>
 <1106705126.3713.33.camel@localhost.localdomain> <41F8F49C.1010506@mozilla.org>
 <Pine.GHP.4.58.0501270948290.26190@milhouse.SEDSystems.ca>
 <41F92337.8070106@TuckerEnergy.com> <Pine.LNX.4.60.0501272240500.2766@dberlin.org>
 <Pine.LNX.4.61.0501300913400.23307@skippy.fini.net> <41FD74A8.1050706@mozilla.org>
Message-ID: <Pine.LNX.4.61.0501311204520.32063@skippy.fini.net>

On Sun, 30 Jan 2005, Gervase Markham wrote:
> Christopher Hicks wrote:
>> One other red herring that I'm tired of seeing is that we're stuck with a 
>> bad implementation and that another lump of checksetup.pl tweaking can't 
>> move us to another way of doing things. 
>
> Without commenting on any of the other issues, I don't see this as a red 
> herring. While in theory it's probably true that one could convert from 
> FAC to FAD using checksetup.pl, in practice such a thing is more complex 
> than any other dynamic schema change we've ever tried, and would be hard 
> to write and liable to fail in unexpected ways due to the "meta" nature 
> of custom fields and the fact that we can't predict what people will use 
> them for. It would never happen.

Bah.  I don't think the meta nautre of custom fields changes the fact that 
FAC and FAR are two different ways to represent the same thing.  There's a 
one-to-one correspondance between them and calling it "hard" to convert 
doesn't make it so.  I'm not saying it would be a trivial task, but it 
strikes me as being pretty straight forward and something that anybody who 
has experience dealing with nontrivial databases could do without agony.

> I certainly agree that endless debate is bad - but the correct way to 
> deal with endless debate is for the person charged with ending it to 
> bring it to an end. Dave should step up and make a decision - FAC or 
> FAD. The fact that one has an implementation available is certainly a 
> factor in that decision, but should not by itself be conclusive.

It seems that Dave is working on that.  Yay!

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


From stu at asyn.com  Mon Jan 31 21:22:46 2005
From: stu at asyn.com (Stuart Donaldson)
Date: Mon, 31 Jan 2005 13:22:46 -0800
Subject: Bugzilla Blues
In-Reply-To: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>
References: <Pine.GHP.4.58.0501311105250.26190@milhouse.SEDSystems.ca>
Message-ID: <41FEA1A6.1040103@asyn.com>

Oh, that's too funny for a Monday.
Thanks, great way to start a week.

Shane H. W. Travis wrote:

>Been enough sniping back and forth on this list lately that I figured we
>could all do with a bit of a break. This whole thing came to me in about 15
>minutes, so I'm obviously inspired. ;-)
>
>I know just how it sounds in my head, but I don't know enough guitar to
>write out the chords or anything. It's a pretty standard walking-bass blues
>riff that I'm sure most of you have all heard before. So now, without
>further waffling, I present to you...
>
>...........................................................................
>
>The Bugzilla Blues
>==================
>(verse 1)
>Oh, my Voting button's broken
>All my Bugmail is returned
>My Comments go unheeded and my bugs go UNCONFIRMED
>(Chorus)
>Got them... Bugzilla blues...
>I just wants to be free...
>Why is this Open-Source project so closed to the likes of me
>
>(verse2)
>Well, Dave won't approve my patches...
>Myk don't like my design
>Nobody reviews me, all that I can do is Whine
>(Chorus)
>Got them... Bugzilla blues...
>Code Just Wants To Be Free...
>Why is this Open-Source project so closed to the likes of me?
>
>(wailing harmonica solo)
>
>(Bridge)
>Maxwell says it's got to be in smaller pieces
>Jouni says my indentation's shot
>Gerv is busy fussin' 'bout the date of the releases
>while all my patches sit upon the vine and rot
>
>(verse 3)
>Well I got so tired of trying
>That I sat and wrote this song
>And then Vlad came by and criticized, "You're singing it all wrong!"
>(Chorus)
>Got them... Bugzilla blues...
>I just wants to be free...
>Why is this Open-Source project so closed to the likes of me?
>
>...........................................................................
>
>
>Thank yew... thank yew ver' much.
>
>
>We now return you to your regularly scheduled kvetching.
>
>
>Shane H.W. Travis       | The greatest of all mistakes is to do nothing
>travis at sedsystems.ca    |  because you can only do a little.
>Saskatoon, Saskatchewan |   Do what you can.  -- Sydney Smith
>-
>To view or change your list settings, click here:
><http://bugzilla.org/cgi-bin/mj_wwwusr?user=stu at asyn.com>
>  
>