73181 - 2.12 Release Notes

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Matthew Tuck [:CodeMachine]]

Let's get a set of release notes ready for 2.12.  I'm not concerned whether
they're a part of the Bugzilla Guide or not providing we clearly point the admin
to them.

I'll attach a first hit shortly.  Can everyone please take a look and tell me
what should be done to them (especially what is missing).

I know I haven't got bug numbers for everything yet or explained what they mean,
so please ignore that.

Anyone got any suggestions for introductory text?

Comment 1

[Matthew Tuck [:CodeMachine]]

Attachment: Bugzilla 2.12 Release Notes, First Hit

Comment 2

[Matthew Tuck [:CodeMachine]]

Taking ...

Comment 3

[Gervase Markham [:gerv]]

"- Bug counts are very slow if you have to count a lot of bugs and you have the 
"Links" option on.  In this case the connection can time out before the page 
completes.  Extending the cgi timeout on your web server can help this situation 
(?)."

The Links option doesn't really make a difference, I don't think. It's the size 
of the query, and there's no real way around this.

Gerv

Comment 4

[Jacob Steenhagen]

If bug 29820 makes it into 2.12 there should be a comment about changing the
e-mail templates.... something along the lines of:

Post Upgrade things to check:
 - The subject line in the newchangedmail parameter (also changedmail if you
wish to support oldmailtech) should have the subject line changed to:
       Subject: [Bug %bugid%] %neworchanged%%summary%

This may also be a good time to mention that sanitycheck should be run as well
as that it is strongly recommended that both newemailtech and
newemailtechdefault be turned on.

It may also be good to mention that newemailtechdefault will only effect new
accounts, if it's desired to force newemailtech to be on (also recommended) the
following SQL statement should be run:
        UPDATE profiles SET newemailtech = '1';

Comment 5

[Matthew Tuck [:CodeMachine]]

Attachment: Second hit.

Comment 6

[Dave Miller [:justdave]]

> - Administrators can no longer create an email accounts that do
>   not match userregexp.
>   (bug ?)

'emailregexp', bug 32971.

Comment 7

[Jacob Steenhagen]

Addition for Changed of Note:

- When a bug is marked as a duplicate, the reporter of the new bug is
  automatically added to the CC list of the original bug.
  (bug 28676)

IMHO, that's noteworthy  :)

Comment 8

[Dave Miller [:justdave]]

> - Improved sanity checking.  This may mean more errors may
>   appear when you sanity check, but it doesn't necessarily
>   mean there are more errors in your database.

This should probably be explained a little more...  existing text is good, just 
add this on the end: "just that they weren't being checked for before."

Comment 9

[Matthew Tuck [:CodeMachine]]

DB_File is now a dependency apparently.  Any particular version?

Comment 10

[Dawn Endico]

gerv, is it true you have a patch to remove that dependency? lets have it.
this is causing trouble with our new machine setup

Comment 11

[Gervase Markham [:gerv]]

Yes. The patch is the last one attached to bug 72721. There is a full 
explanation there of exactly what it does. I'll try and catch you on IRC.

Gerv

Comment 12

[Dave Miller [:justdave]]

Bug 29820 has been checked in.  See Jake's comments above regarding that.  It 
needs release-noting.

Comment 13

[Matthew Tuck [:CodeMachine]]

Attachment: Possibly final hit.

Comment 14

[Matthew Tuck [:CodeMachine]]

This is possibly ready for 2.12.  Would be placed at the bugzilla root so people
would notice it?

The only thing that I know of that's outstanding is I need to know is whether we
need to release note anthing about DB_File et al.

Comment 15

[Gervase Markham [:gerv]]

My patch to eliminate DB_File was checked in and, as soon as the 
patch-to-the-patch to correct some behaviour which Dawn didn't like goes in, 
this whole episode will hopefully be behind us.

The evidence so far is that AnyDBM_File is in Perl 5.004 and so we don't need to 
release-note anything.

Queries for the current hit:
sanitycheck.cgi has a cgi extension. Does this mean you should run it by 
accessing it over the web? If so, you might want to say this explicitly because 
(due to the association with checksetup.pl) I assumed at first it was a 
command-line thing. You might then want to talk about "accessing" rather than 
"running".

Is it worth doing bug number links rather than just numbers?

You can probably remove the "bug counts are very slow" disclaimer now that the 
aforementioned patch has gone in. It hasn't been tried on b.m.o yet, but I'm 
reasonably confident that it should now be able to cope with data sets that 
size.

Gerv

Comment 16

[Jacob Steenhagen]

It is strongly recommended
that you turn the newemailtech and newemailtechdefault on
editparams.cgi so new accounts will use new email tech.

Should be ...newemailtechdefault on (in|using) editparams.cgi...

Also, the 2nd introduction paragraph is written in third person while the rest
is second person.  (Just some minor readability nit-picks).

Also, it might be nice to recommend that care be taken so localconfig and
data/params not be overwritten (and index.html if that's been modified) when
un-taring bugzilla.

Or perhaps the Upgrade section should be a step-by-step recommendation for
perfoming the upgrade (after all, I'm sure someone is bound to ask in .webtools)

Comment 17

[Matthew Tuck [:CodeMachine]]

OK, I've fixed most of the problems.

I'm going to leave the counts problem in there until I've seen evidence
otherwise, it won't hurt to leave it in if it's no longer a problem.

I won't add the untarring stuff, as the notes should really be a
version-specific file, and indeed I've probably got a few things in there
already that are best off in an install guide.

Comment 18

[Matthew Tuck [:CodeMachine]]

Attachment: Really last hit. For sure this time. Or your money back.

Comment 19

[Gervase Markham [:gerv]]

Can someone please open a bug to change the mostfreqhtml param to explain that it only updates every 24 hours, and that it counts all indirect dupes as well? We'll get loads of bug reports otherwise. Fell free also to fix this bug :-)

Gerv (using Windows CE 1.0 and so having trouble interacting with Bugzilla.)

Comment 20

[Matthew Tuck [:CodeMachine]]

Attachment: Documented the issue with deferred mode with the Postfix MTA.

Comment 21

[Matthew Tuck [:CodeMachine]]

Gerv,

Why will bug counts get faster?  My understanding is that dupe counts are what
you have been working on.

And also, is there anything to release note for the mostfreqhtml param? 
Otherwise why comment on it here?

Comment 22

[Gervase Markham [:gerv]]

> Why will bug counts get faster?  My understanding is that dupe counts are what
> you have been working on.

Yes, sorry about that. Temporary confusion on my part. The release note should 
remain.

> And also, is there anything to release note for the mostfreqhtml param? 
> Otherwise why comment on it here?

Because, as I said, I was using Pocket IE 1.0 on a Windows CE 1.0 machine, and 
trying to work the Bugzilla Search form would have been a nightmare. However, 
now I'm back, and I will fix it now rather than having you open a new bug. No 
release note is necessary.

Gerv

Comment 23

[Matthew Tuck [:CodeMachine]]

> Yes, sorry about that. Temporary confusion on my part. The release
> note should remain.

I'll clarify on the notes.  You're not the only person confused over what it
meant, even though the developers are more likely to get confused.

> Because, as I said, I was using Pocket IE 1.0 on a Windows CE 1.0
> machine, and trying to work the Bugzilla Search form would have been a
> nightmare. However, now I'm back, and I will fix it now rather than
> having you open a new bug. No release note is necessary.

OK, well there's a release tracking bug, and I'd like to have one permanently,
so if it happens again you could use that as it was a bit confusing on here.

Comment 24

[Matthew Tuck [:CodeMachine]]

Attachment: Clarified the bug counts and deferred mode sections.

Comment 25

[Matthew Tuck [:CodeMachine]]

Gerv, apparently duplicates.cgi doesn't work for several days.  I figure this
should be release noted.  Is this two days, or three or more, or what?

Comment 26

[Gervase Markham [:gerv]]

It should only need one set of stats to work. The "changed since" bit will 
silently and invisibly fail if there are no stats from whenever you ask it 
(default 1 week.) So, in this way, it's like the graphs, which also require at 
least one run of collectstats.pl (or is it two?). Is the graphs thing documented 
anywhere?

Gerv

Comment 27

[Matthew Tuck [:CodeMachine]]

There's nothing about requiring a certain number of runs in the release notes at
the moment.

All I know is that I was running and rerunning collectstats.pl and nothing was
coming up on duplicates.cgi, it kept saying there were no stats collected. 
People told me it required several days of data to work.  Mattfill is not
running your latest patch if that's relevant.

Comment 28

[Gervase Markham [:gerv]]

Hmm. Exactly what error did you get? Code is:
http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/duplicates.cgi

It _should_ work with only one set. 

Depending on the OS of your Mattfill, it might well be broken, actually. Try 
applying my patch and see if it helps. You see, the current CVS code assumes an 
extension of ".db" for the database files and this is not true on all OSes.

Remember to rerun checksetup.pl and collectstats.pl after applying the patch.

Gerv

Comment 29

[Matthew Tuck [:CodeMachine]]

> Hmm. Exactly what error did you get?

It said there were no stats for today or yesterday.

> Depending on the OS of your Mattfill, it might well be broken, actually.

Yes, the databases were .dir and .pag for me.  I could swear I then did all this
as you said and it didn't work, but I just did it again and it worked ...  this
was on a Debian Woody box.

Please elaborate on the "graphs thing".

Comment 30

[Gervase Markham [:gerv]]

If you are dir and pag, it won't work. The code in CVS assumes ".db". 

The graphs have always required at least one (and perhaps two, I can't 
remember) daily runs of collectstats.pl before they can do anything - you can't 
have much of a chart with only one data point. This is not new, and shouldn't 
need release noting.

Gerv

Comment 31

[Matthew Tuck [:CodeMachine]]

If it's one, that's OK.  But I'm not content with a "maybe".  I'll see if I can
find out.

Comment 32

[Matthew Tuck [:CodeMachine]]

OK, the graph appears after one day but no line appears until the second day. 
Tara thinks this doesn't need to be noted and I'm flexible on the issue, so
we'll just leave it alone.

Comment 33

[Tara Hernandez]

The new blurb at the top...

>         =====================
>         BUGZILLA 2.12 RELEASE
>         =====================
3a7,14
>       * Release Notes for Bugzilla 2.12 are available at docs/rel_notes.txt.
> 
>       * The new preferred documentation for Bugzilla is available in docs/,
with
> a variety of document types available.  Please refer to these documents when 
> installing, configuring, and maintaining your Bugzilla installation.  The
majority
> of the contents of this file is now considered to be largely deprecated and
will
> go away in the 2.14 security release.

Comment 34

[Matthew Tuck [:CodeMachine]]

Attachment: I suck.

Comment 35

[Zach Lipton [:zach]]

Can we not mention 'security release'? Lets just say 'in the next release'. I 
don't think we want people to think that the product is insecure (which in 
some ways it is). People will think that means 'using this will make my 
website open to being defaced' instead of 'it is possible to get information 
about closed bugs'.

Comment 36

[Matthew Tuck [:CodeMachine]]

I deliberately tried to downplay this, and we have to mention something.

Comment 37

[Gervase Markham [:gerv]]

How about:

"If you have to make special code changes to Bugzilla each
version, you should be aware that Bugzilla 2.14 is intended
to be released soon, to improve security."

->

"If you have to make special code changes to Bugzilla each
version, you should be aware that Bugzilla 2.14 is intended
to be released soon. This release will concentrate on improving Bugzilla's
security - for example, it will hopefully make it impossible for unauthorised
users to view bugs in groups to which they do not belong."

Gerv

Comment 38

[Matthew Tuck [:CodeMachine]]

If you're trying to inspire confidence I doubt that would do so.  Oh well, it
wasn't my idea to leave those bugs in 2.12.

Comment 39

[Dave Miller [:justdave]]

yeah, but if we tried to fix them now, 2.12 would never ship.  Gotta draw the 
line somewhere...  :(

Comment 40

[Matthew Tuck [:CodeMachine]]

Security holes aren't being spontaneously generated you know.  There ain't an
infinite supply.

Comment 41

[Dave Miller [:justdave]]

ok, your data/quips -> data/comments patch is in.

Comment 42

[timeless]

I don't care if there isn't an infinite number of holes, I would suggest that 
we avoid the word impossible.

Comment 43

[Gervase Markham [:gerv]]

That is why the word "hopefully" is there. However, alternative wordings 
welcomed.

Gerv

Comment 44

[Matthew Tuck [:CodeMachine]]

Let's try to work out the wording soonish, maybe on IRC.  I'm not really 
comfortable with what I wrote, nor any of the alternative suggestions.

Comment 45

[Tara Hernandez]

arguments have been had.  no forward referencing.

Comment 46

[Matthew Tuck [:CodeMachine]]

Bug #77547 is the 2.14 release notes bug.

Comment 47

[Dave Miller [:justdave]]

Moving closed bugs to Bugzilla product