* Re: Bug tracking / Release Quality Assurance
@ 2002-10-10 8:01 Nathanael Nerode
0 siblings, 0 replies; 15+ messages in thread
From: Nathanael Nerode @ 2002-10-10 8:01 UTC (permalink / raw)
To: gcc
Mark Mitchell quoth:
>If you are laboring along on a branch, please take the time to work on
>fixing a few bugs. If we all fix three or four, we'll be done in
>no time. Your branch isn't going to be released until we are done with
>this release, so your work is going to see the light of day much sooner
>if you pitch in now.
Looking at the high priority bugs, I figure:
26 c++ bugs (including *all* the rejects-legal bugs)
A number of the bugs in other categories are actually C++ specific as
well. A number of the bugs in other categories have already been fixed.
A number of the bugs in other categories seem to be obsolete
or unreproducible.
Most of the remaining non-C++ bugs are target-specific (with a number
that are host-specific). Then there are the open-ended bugs (such as
'undocumented options' and 'make sure all ada patches to branch get into
mainline').
Unfortunately, this looks like the kind of situation where most of the
bugs are actually quite hard to take on without intricate knowledge of
specific files. More people working on these bugs will probably not get
them fixed any faster, unless they happen to be the people who are expert
in the correct areas (like the C++ front end).
More people working on bug-fixing is wonderful, of course; I'm just
warning that it may have a significant delay before having any positive
effects, due to people investigating areas of code they're not used to.
--Nathanael
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-12-09 10:14 Volker Reichelt
@ 2002-12-09 10:42 ` Mark Mitchell
0 siblings, 0 replies; 15+ messages in thread
From: Mark Mitchell @ 2002-12-09 10:42 UTC (permalink / raw)
To: Volker Reichelt, gcc, pfeifer; +Cc: nathan
--On Monday, December 09, 2002 08:08:52 PM +0100 Volker Reichelt
<reichelt@igpm.rwth-aachen.de> wrote:
> Most of these bugs aren't missing crucial information (like a
> preprocessed file), but are left in an inconclusive state about what
> action to take.
You're right that these shouldn't be closed.
But, in fact, they shouldn't be in the feedback state at all. The
feedback state is for bugs that we don't have enough information to
analyze.
We may be using the feedback state for some other purpose, but
we should stop. :-)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
@ 2002-12-09 10:14 Volker Reichelt
2002-12-09 10:42 ` Mark Mitchell
0 siblings, 1 reply; 15+ messages in thread
From: Volker Reichelt @ 2002-12-09 10:14 UTC (permalink / raw)
To: gcc, pfeifer; +Cc: mark, nathan
There are about 30 bugs in feedback state where no feedback was received
for more than 6 months. An additonal 20 reports got no feedback for 3
months.
Most of these bugs aren't missing crucial information (like a
preprocessed file), but are left in an inconclusive state about what
action to take.
I don't think they should be closed unconditionally, but should be
revisited. Maybe their state should be changed to "open" in some cases.
We could try to ping the respective developers, about what to do.
When adding an entry for the policies section of gnatswrite.html,
I would suggest closing only those PRs after 3 months that lack crucial
parts of information (like a preprocessed file) that hinder analysis.
Regards,
Volker
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-12-07 6:53 ` Gerald Pfeifer
@ 2002-12-08 19:16 ` Mark Mitchell
0 siblings, 0 replies; 15+ messages in thread
From: Mark Mitchell @ 2002-12-08 19:16 UTC (permalink / raw)
To: Gerald Pfeifer, gcc, Nathan Sidwell
--On Saturday, December 07, 2002 03:36:43 PM +0100 Gerald Pfeifer
<pfeifer@dbai.tuwien.ac.at> wrote:
> On Mon, 7 Oct 2002, Nathan Sidwell wrote:
>>> 2. I suggest that we close PRs that have been in feedback state but
>>> not received any response for more than 6 months:
>> I'd think 3 or 4 months even.
>
> There were no responses to this, but 3 or 4 months would be fine with
> me as well.
>
> What should I add to our new section on "Procedures and Policies" at
> the end of http://gcc.gnu.org/gnatswrite.html ? Mark?
I think 3 months is fine; please add that.
Thanks!
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:50 ` Nathan Sidwell
2002-10-08 12:38 ` Mark Mitchell
@ 2002-12-07 6:53 ` Gerald Pfeifer
2002-12-08 19:16 ` Mark Mitchell
1 sibling, 1 reply; 15+ messages in thread
From: Gerald Pfeifer @ 2002-12-07 6:53 UTC (permalink / raw)
To: gcc, Nathan Sidwell; +Cc: Mark Mitchell
On Mon, 7 Oct 2002, Nathan Sidwell wrote:
>> 2. I suggest that we close PRs that have been in feedback state but
>> not received any response for more than 6 months:
> I'd think 3 or 4 months even.
There were no responses to this, but 3 or 4 months would be fine with
me as well.
What should I add to our new section on "Procedures and Policies" at
the end of http://gcc.gnu.org/gnatswrite.html ? Mark?
Gerald
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-08 12:38 ` Mark Mitchell
@ 2002-10-08 16:07 ` Pop Sébastian
0 siblings, 0 replies; 15+ messages in thread
From: Pop Sébastian @ 2002-10-08 16:07 UTC (permalink / raw)
To: Mark Mitchell; +Cc: Nathan Sidwell, Gerald Pfeifer, gcc
On Tue, Oct 08, 2002 at 06:41:26AM -0700, Mark Mitchell wrote:
> If we all fix three or four, we'll be done in no time.
This sounds like a Stakhanovist ideal... I hope that the comparison stops here.
> Your branch isn't going to be released until we are done with
> this release, so your work is going to see the light of day much sooner
> if you pitch in now.
>
I will try to help fixing some more bugs.
(Mark, sorry for my last email...)
Sebastian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:50 ` Nathan Sidwell
@ 2002-10-08 12:38 ` Mark Mitchell
2002-10-08 16:07 ` Pop Sébastian
2002-12-07 6:53 ` Gerald Pfeifer
1 sibling, 1 reply; 15+ messages in thread
From: Mark Mitchell @ 2002-10-08 12:38 UTC (permalink / raw)
To: Nathan Sidwell, Gerald Pfeifer; +Cc: gcc
--On Monday, October 07, 2002 05:23:13 PM +0100 Nathan Sidwell
<nathan@codesourcery.com> wrote:
> Gerald Pfeifer wrote:
>> Checking the GNATS database which currently shows 62 high priority
>> problems, there are some points I'd like to raise:
>>
>> 1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
>> bug count has been significantly reduce.
> I concur.
Me too.
I will be making a concerted effort to fix the C++ bugs.
Please help as you are best able.
If you are laboring along on a branch, please take the time to work on
fixing a few bugs. If we all fix three or four, we'll be done in
no time. Your branch isn't going to be released until we are done with
this release, so your work is going to see the light of day much sooner
if you pitch in now.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-08 8:53 ` Neil Booth
@ 2002-10-08 8:59 ` Roger Sayle
0 siblings, 0 replies; 15+ messages in thread
From: Roger Sayle @ 2002-10-08 8:59 UTC (permalink / raw)
To: Neil Booth; +Cc: gcc
> Roger Sayle wrote:-
> > all boot c&++ c++ dbug g77 java lgcj mid objc opt othr stdc targ
>
> You omitted "preprocessor"; there's only 3 of those!
My apologies. Of course, much credit to Neil and Zack that there are
so few bugs in the preprocessor that I didn't even bother tracking them.
Doubly so for its stability following its recent major overhaul.
I selected the subset of GNATS categories back in April based upon the
number of bugs in each category at that time, and the limitations of an
80 character terminal. There may also have been some bias to the
categories to which I thought I could contribute :>
Roger
--
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-08 7:31 Roger Sayle
@ 2002-10-08 8:53 ` Neil Booth
2002-10-08 8:59 ` Roger Sayle
0 siblings, 1 reply; 15+ messages in thread
From: Neil Booth @ 2002-10-08 8:53 UTC (permalink / raw)
To: Roger Sayle; +Cc: gcc, Gabriel Dos Reis, Gerald Pfeifer
Roger Sayle wrote:-
> date all boot c&++ c++ dbug g77 java lgcj mid objc opt othr stdc targ
> 20020430 1256 126 591 471 12 10 77 46 16 15 85 86 45 102
> 20020502 1262 127 596 478 11 11 78 44 16 15 86 86 42 102
> 20020508 1288 129 605 482 12 11 75 45 18 15 87 87 45 102
> 20020514 1301 130 606 483 12 9 75 46 19 15 94 91 49 104
> 20020519 1320 129 620 496 12 9 76 46 19 13 97 89 48 107
> 20020523 1355 134 623 499 12 10 77 48 19 13 102 93 58 109
> 20020527 1383 139 638 505 12 10 81 49 18 13 107 95 55 108
> 20020601 1418 143 656 512 12 10 80 49 18 13 114 98 50 113
> 20020607 1451 148 658 510 12 10 79 49 20 18 118 101 48 120
> 20020612 1475 148 668 518 12 10 77 49 21 18 128 102 50 121
> 20020616 1502 157 677 520 12 10 77 49 23 17 132 88 52 133
> 20020626 1504 157 694 536 14 11 81 51 22 17 133 91 56 103
> 20020702 1519 164 696 537 14 11 80 49 22 16 140 91 60 104
> 20020721 1591 169 720 538 18 12 84 49 29 11 150 98 61 113
> 20020802 1640 173 741 553 18 13 84 50 29 11 156 100 58 122
> 20020826 1787 189 783 610 24 15 84 56 47 11 176 110 60 154
> 20020908 1885 198 838 652 24 15 90 60 48 9 178 116 67 160
> 20020928 1940 214 829 644 26 15 91 58 55 5 186 122 79 170
> 20021005 1908 217 828 644 29 14 91 60 53 5 175 124 77 156
>
> As you can see with the exception of the hard work of Nicola Pero (and
> Stan Shebs?) to bring down the objc numbers most other columns are out
> of control. But notice also the recent effects of Mark Mitchell's
> requests to fix bugs (or threats to close branches) has resulted in
> the first significant drop in the total number of PRs in 6 months.
You omitted "preprocessor"; there's only 3 of those!
Neil.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
@ 2002-10-08 7:31 Roger Sayle
2002-10-08 8:53 ` Neil Booth
0 siblings, 1 reply; 15+ messages in thread
From: Roger Sayle @ 2002-10-08 7:31 UTC (permalink / raw)
To: gcc; +Cc: Gabriel Dos Reis, Gerald Pfeifer
Gabriel Dos Reis writes:
> Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
> | Checking the GNATS database which currently shows 62 high priority
> | problems, there are some points I'd like to raise:
> |
> | 1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
> | bug count has been significantly reduce.
>
> Agreed.
>
> Seems like, somewhere at some point, our development model failed to
> cope with only-bug-or-regression fixes and improving (in the broad
> sense) the development branch: Balance interests in fixing bugs and
> adding new functionality. Clearly closing all branches won't
> automatically make people fixing bugs, but somehow we need to improve
> on the current situation.
[Lots of my very humble opinions...]
I'd like to offer an alternative perspective. I think 62 high priority
PRs in GNATS is very impressive given that there were 75 just over a week
ago. At this rate there'll be no outstanding high priority PRs by the
3.3 release! :>
The "obvious" source of the problem is that the rate at which bugs are
submitted to GNATS is significantly higher than the rate at which they're
getting fixed. I've been following the graphs since April...
Table of non-closed PRs in GNATS by date (row) and category (column)...
date all boot c&++ c++ dbug g77 java lgcj mid objc opt othr stdc targ
20020430 1256 126 591 471 12 10 77 46 16 15 85 86 45 102
20020502 1262 127 596 478 11 11 78 44 16 15 86 86 42 102
20020508 1288 129 605 482 12 11 75 45 18 15 87 87 45 102
20020514 1301 130 606 483 12 9 75 46 19 15 94 91 49 104
20020519 1320 129 620 496 12 9 76 46 19 13 97 89 48 107
20020523 1355 134 623 499 12 10 77 48 19 13 102 93 58 109
20020527 1383 139 638 505 12 10 81 49 18 13 107 95 55 108
20020601 1418 143 656 512 12 10 80 49 18 13 114 98 50 113
20020607 1451 148 658 510 12 10 79 49 20 18 118 101 48 120
20020612 1475 148 668 518 12 10 77 49 21 18 128 102 50 121
20020616 1502 157 677 520 12 10 77 49 23 17 132 88 52 133
20020626 1504 157 694 536 14 11 81 51 22 17 133 91 56 103
20020702 1519 164 696 537 14 11 80 49 22 16 140 91 60 104
20020721 1591 169 720 538 18 12 84 49 29 11 150 98 61 113
20020802 1640 173 741 553 18 13 84 50 29 11 156 100 58 122
20020826 1787 189 783 610 24 15 84 56 47 11 176 110 60 154
20020908 1885 198 838 652 24 15 90 60 48 9 178 116 67 160
20020928 1940 214 829 644 26 15 91 58 55 5 186 122 79 170
20021005 1908 217 828 644 29 14 91 60 53 5 175 124 77 156
As you can see with the exception of the hard work of Nicola Pero (and
Stan Shebs?) to bring down the objc numbers most other columns are out
of control. But notice also the recent effects of Mark Mitchell's
requests to fix bugs (or threats to close branches) has resulted in
the first significant drop in the total number of PRs in 6 months.
As a contributor, virtually all high priority optimization PRs have
now been fixed or are assigned to someone (7124 == 7426, 7034 == 6845).
But by far the largest category of high priority PRs is C++. My numbers
from the weekend before last are 28 C++, vs. 8 optimization, 8 target,
7 C with all other categories 4 or less.
By their very nature C++ bugs are difficult to fix. Hence GCC forked
a C++ parser branch to tackle many of these problems in the medium to
longer term. I believe the current problems are a side-effect of the
decision between short-term fixes in the current C++ infrastructure
vs. longer-term fixes in the new parser.
[I could go into a longer analysis of why the current situation is
as it is, but suffice to say the problems couldn't be avoided and
everyone involved is doing the best they can].
One possible improvement in the current situation would be for the C++
maintainers to review patches as quickly as possible. Patches to most
other parts of the compiler are reveiwed by RTH at a phenomenal rate,
but my impression is that C++ changes/fixes are typically approved by
someone else and therefore take slightly longer. [I've absolutely no
data to support this claim]. However reducing this negligible barrier
to C++ patches may improve the overall dynamic.
And I really hate to say it, but a longer term solution might be better
C++ internals documentation. This would reduce the effort required to
become a g++ front-end wizard. Ultimately, g++'s problems can't be
fixed by making the maintainers work harder. What's needed are ways
to get more volunteers to offer solutions.
Roger
--
Roger Sayle, E-mail: roger@eyesopen.com
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:38 Gerald Pfeifer
2002-10-07 9:42 ` David S. Miller
2002-10-07 9:50 ` Nathan Sidwell
@ 2002-10-08 0:43 ` Gabriel Dos Reis
2 siblings, 0 replies; 15+ messages in thread
From: Gabriel Dos Reis @ 2002-10-08 0:43 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:
| Checking the GNATS database which currently shows 62 high priority
| problems, there are some points I'd like to raise:
|
| 1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
| bug count has been significantly reduce.
Agreed.
Seems like, somewhere at some point, our development model failed to
cope with only-bug-or-regression fixes and improving (in the broad
sense) the development branch: Balance interests in fixing bugs and
adding new functionality. Clearly closing all branches won't
automatically make people fixing bugs, but somehow we need to improve
on the current situation.
Maybe more maintainers for some parts of the compilers?
[...]
| 3. We probably need some (further) volunteers who monitor GNATS more
| closely, ask submitters for further information/feedback and ping
| maintainers concerning problems in their areas.
Some maintainers have many things to sort out similtaneously so they
get quickly very busy...
-- Gaby
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:42 ` David S. Miller
@ 2002-10-07 10:26 ` Jakub Jelinek
0 siblings, 0 replies; 15+ messages in thread
From: Jakub Jelinek @ 2002-10-07 10:26 UTC (permalink / raw)
To: David S. Miller; +Cc: pfeifer, gcc
On Mon, Oct 07, 2002 at 09:12:05AM -0700, David S. Miller wrote:
> From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
> Date: Mon, 7 Oct 2002 18:03:28 +0200 (CEST)
>
> 1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
> bug count has been significantly reduce.
>
> 2. I suggest that we close PRs that have been in feedback state but
> not received any response for more than 6 months:
>
> Examples: 3931, 4650, 5971, 5515, 6545
>
> 3. We probably need some (further) volunteers who monitor GNATS more
> closely, ask submitters for further information/feedback and ping
> maintainers concerning problems in their areas.
>
> I agree on #1 and #2, but I'm not so sure #3 is going to help
> all that much.
>
> If maintainers aren't finding enough time to monitor GNATS in their
> particular area, it is likely they are overloaded enough that some
> volunteer pinging them they have stuff to look at won't get it done.
>
> The volunteer who does the "ask for more information" bit will need
> to be quite knowledgable. But if you found such a person who isn't
> already taxed with GCC things to do, it would be useful to have
> them help in this area.
A lot of GNATS bugreports come with huge testcases. Trimming them into
testcases suitable for gcc testsuite (and at the same time into a size
in which they can be easily debugged) and where easily possible figuring
roughly what the bug area is would surely help IMNSHO.
Jakub
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:38 Gerald Pfeifer
2002-10-07 9:42 ` David S. Miller
@ 2002-10-07 9:50 ` Nathan Sidwell
2002-10-08 12:38 ` Mark Mitchell
2002-12-07 6:53 ` Gerald Pfeifer
2002-10-08 0:43 ` Gabriel Dos Reis
2 siblings, 2 replies; 15+ messages in thread
From: Nathan Sidwell @ 2002-10-07 9:50 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc
Gerald Pfeifer wrote:
> Checking the GNATS database which currently shows 62 high priority
> problems, there are some points I'd like to raise:
>
> 1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
> bug count has been significantly reduce.
I concur.
> 2. I suggest that we close PRs that have been in feedback state but
> not received any response for more than 6 months:
I'd think 3 or 4 months even.
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Bug tracking / Release Quality Assurance
2002-10-07 9:38 Gerald Pfeifer
@ 2002-10-07 9:42 ` David S. Miller
2002-10-07 10:26 ` Jakub Jelinek
2002-10-07 9:50 ` Nathan Sidwell
2002-10-08 0:43 ` Gabriel Dos Reis
2 siblings, 1 reply; 15+ messages in thread
From: David S. Miller @ 2002-10-07 9:42 UTC (permalink / raw)
To: pfeifer; +Cc: gcc
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Date: Mon, 7 Oct 2002 18:03:28 +0200 (CEST)
1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
bug count has been significantly reduce.
2. I suggest that we close PRs that have been in feedback state but
not received any response for more than 6 months:
Examples: 3931, 4650, 5971, 5515, 6545
3. We probably need some (further) volunteers who monitor GNATS more
closely, ask submitters for further information/feedback and ping
maintainers concerning problems in their areas.
I agree on #1 and #2, but I'm not so sure #3 is going to help
all that much.
If maintainers aren't finding enough time to monitor GNATS in their
particular area, it is likely they are overloaded enough that some
volunteer pinging them they have stuff to look at won't get it done.
The volunteer who does the "ask for more information" bit will need
to be quite knowledgable. But if you found such a person who isn't
already taxed with GCC things to do, it would be useful to have
them help in this area.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug tracking / Release Quality Assurance
@ 2002-10-07 9:38 Gerald Pfeifer
2002-10-07 9:42 ` David S. Miller
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Gerald Pfeifer @ 2002-10-07 9:38 UTC (permalink / raw)
To: gcc
Checking the GNATS database which currently shows 62 high priority
problems, there are some points I'd like to raise:
1. I believe we should not ship GCC 3.2.1 (or branch 3.3.) until this
bug count has been significantly reduce.
2. I suggest that we close PRs that have been in feedback state but
not received any response for more than 6 months:
Examples: 3931, 4650, 5971, 5515, 6545
3. We probably need some (further) volunteers who monitor GNATS more
closely, ask submitters for further information/feedback and ping
maintainers concerning problems in their areas.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-12-09 18:42 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-10 8:01 Bug tracking / Release Quality Assurance Nathanael Nerode
-- strict thread matches above, loose matches on Subject: below --
2002-12-09 10:14 Volker Reichelt
2002-12-09 10:42 ` Mark Mitchell
2002-10-08 7:31 Roger Sayle
2002-10-08 8:53 ` Neil Booth
2002-10-08 8:59 ` Roger Sayle
2002-10-07 9:38 Gerald Pfeifer
2002-10-07 9:42 ` David S. Miller
2002-10-07 10:26 ` Jakub Jelinek
2002-10-07 9:50 ` Nathan Sidwell
2002-10-08 12:38 ` Mark Mitchell
2002-10-08 16:07 ` Pop Sébastian
2002-12-07 6:53 ` Gerald Pfeifer
2002-12-08 19:16 ` Mark Mitchell
2002-10-08 0:43 ` Gabriel Dos Reis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).