Re: Debian Re-organization proposals (was: Re: so what?)
Manoj Srivastava <firstname.lastname@example.org> wrote:
> Every once in a while, the stable set is copied off
> ("Frozen"), tested, and released as a nerw version. Since there is
> always a release ready set of packages, presumably one may release at
> regular intervals.
We'd really like to parallelize the testing process.
Also, maintainers have blind spots and testing a package isn't that
onerous of a deal.
We already have one tool to help us test: the bug tracking system.
We also have people actively testing packages, and we have the work
of the ftp site maintainer (plus whatever the maintainer does,
I'm wondering if we couldn't instigate something like installation
reports and success reports.
Person puts something in /etc/ and dselect sends an installation log
summary (perhaps also indicating errors) after every installation run.
You want this as a tool, so dpkg users can also generate such reports.
You want some kind of reminder to be displayed so that it's obvious
this feature is turned on (don't want people being angry with us for
invading their privacy).
some kind of tool to expedite writing up "I used ___ and it worked".
Perhaps keep a check list of what's been reported, and perhaps include
something like a tool to quickly scan over .bash_history to give a hint
about things which have been used but not reported. [This can't be 100%
reliable, but the idea is to make the whole thing fast and quick, and to
provide distinct reference points.]
For the first n distinct reports we keep complete copies of the report,
after that we just track email addresses (and maybe key signatures if
the message was signed). We may want to track signed reports as having
more significance than unsigned reports.
What would this information mean?
(1) Lots of good reports and no bug reports means a stable package
version. [After some minimum delay for sanity purposes.]
(2) Conflicting bug reports and good reports still means the bug has
to be fixed [but now there are also people you can ask "did this
work for you"].
(3) Very few reports means we wait longer for a package to become
Note that this also gives people something that they can focus on
to do for us (that would really help): test our stuff. In my opinion,
we need several tiers of testers:
(A) The casual tester -- this should be really easy to get started
on, because we need feedback from people who are only moderately
familiar with our systems.
(B) The heavy duty tester -- this should be a bit more formal.
(C) Official maintainers (include ftp site maintainer here). We've
already got this.
Anyways, it's an idea...
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org