Debian Weekly News - email

Date: Sun, 28 Mar 1999 21:48:05 +0200
From: Martin Schulze <joey@finlandia.Infodrom.North.DE>
To: Debian Development <>
Cc: Debian QA <>
Subject: Reviving Debian QA


[ Mailing to Debian Development and Debian QA, please send replies
  *only* to Debian QA <> ]

as many people out here already know debian-qa has been quite quiet

What is debian-qa and is it eatable?

  QA stands for Quality Assurance and is intended to keep the quality
  of the distribution as high as it should be.  At the moment there is
  no real Quality Assurance for Debian.  This is mainly due to people
  who had initiated QA found themselves burried in other important
  (Debian-related) stuff.

Do we need Quality Assurance?

  With the growing number of developers working on Debian (>500
  registrated developers at the moment) QA is urgently needed.  It is
  very interesting (and usually not the case) that the quality of
  Debian is still that high.  With companies having more than 500
  concurrent developers ... I don't want to think about this...

  Although we have strict rules (Policy) that defines requirements for
  packages there is still missing a "department" which assures that
  every package is packaged well and integrates in the system nicely.

  To be honest, there are still *lots* of packages not using all the
  suggested tools and integration (menu files, dwww files, doc-base
  files, alternatives, proper suggests/recommends, proper priorities

Now that several new maintainers mentioned QA or QA-like work in their
new-maintainers application I'd like to invite people to work on QA
for Debian.  This doesn't need a fully fledged developer but also
people who can only spend a few hours on Debian.

I would appreciate if some people, both new and regular developers,
would decide to work on QA for Debian GNU.  Please look at the
following - incomplete - list of things which fall into the field of
duty for the QA team:

 . Check old bugs - and work on them

 . Check packages with lots of bugs - and work on them

 . Check if all packages providing user programs (X11 or not) come
   with menu files

   - Such packages have to call update-menus in their postinst and
     prerm scripts

 . Check if all packages that provide documentation register it for
   dwww, doc-base or whatever

 . Check if packages are policy conforming

 . Add documentation where it is needed - there are lots of places
   where documentation is missing.

 . Detect orphaned packages and take care of them

 . Check if packages still work - especially old ones

 . Check if priorities, recommends, suggests and depends are used

 . Check if packages are linked against proper libraries, maybe check
   if they would work with newer stable ones (especially for Gtk-based
   programs) as well

 . Watch out for new versions of software and notify maintainers if

If you find packages which lack support for some of the features
mentioned above the proper action would be to file a wishlist bug
report.  The bug report has to point to accurate documentation or
better include a description of the missing feature and a description
how to solve this.  It would be best if the report would include a
proper patch/menu file/doc file etc.



The good thing about standards is that there are so many to choose from.
	-- Andrew S. Tanenbaum

Please always Cc to me when replying to me on the lists.

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Date: Sun, 28 Mar 1999 21:55:16 +0200
From: Martin Schulze <joey@finlandia.Infodrom.North.DE>
To: Debian Policy <>
Subject: Maintainership, vanishing or absent maintainers (QA)

I'm trying to revive Debian QA.  With the growing number of new
maintainers showing interest in general QA for Debian it seems useful
that one of the 'old' maintainers shows direction.

However if it works and we have a working QA team we need to discuss
ways the QA team is allowed to upload packages.  They need to be able
to work on apparently orphaned packages even if the maintainer hasn't
orphaned the package.

The following is extracted from a text Vincent Renardias wrote in
February 1997.  I'm not modifying it in order to be able to discuss it
properly.  Please keep in mind that parts of it may be out dated by




* Bugfix upload policy:
	* Maintained packages: Send fixes to their maintainers, and eventually
		upload the fixed version if no feedback from the maintainer.
		(see "uploads delays" below)
	* Orphaned packages:
		Bugfix uploads can be done any time by DQAG members.
		Call for a maintainer on debian-devel;
		If no-one found after 1 month:
			- Important packages (ie: "required" or "standard"):
				The package will be maintained by DQAG until a maintainer is found.
			- Unimportant packages:
				If there's still no-one volunteering to take care of them
				after this delay, they'll be dropped in the section 'project/orphaned'.

* Takeover uploads delays:
	After a patch is posted by the DQAG to a maintainer, how long
	will the DQAG wait before uploading the package if the maintainer does
	not do the upload himself?

	Delays :
	- critical security fix:	2 days.
	- security fix:			7 days.
	- bug fix:			30 days.
		(Fix a bug reported in the bug tracking system or RFE)
	- cosmetic fix:			45 days.
		(typo. in man page, core file in source package,...)
		NB: "cosmetic fixes" are uploaded to "unstable" only; (neither "stable" nor "frozen").
	The above delays are reduced by a factor of 2 in the month preceding a freeze.
	During a freeze: Delay for security fixes (those announced on <>): 1 day.
	Other fixes: 1 week.
	[Are these delays too long/too short?]
		DQAG members making bugfix uploads will need not only to respect the delays above
	but will also have to announce their intent to upload on <debian-QA> with a cc: to the
	maintainer at least 2 days (or 1 day
	during a freeze) before to do the upload, saying which Package_Version they will upload,
	and the serial numbers of the bugs fixed by the upload.
		The 'Maintainer' field of those uploaded packages will stay unchanged.
		However if DQAG members make 3 consecutive bugfix uploads with still no action
	from the package maintainer, then the 'Maintainer' field will be set to
	"Orphaned Package <>", and the package will be considered as
	orphaned (this will be announced on <debian-devel>).
	- work on "stable" and "unstable" distributions:

The good thing about standards is that there are so many to choose from.
	-- Andrew S. Tanenbaum

Please always Cc to me when replying to me on the lists.

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Date: Sun, 28 Mar 1999 18:14:36 -0700 (MST)
From: Ward Deng <wdeng@KachinaTech.COM>
To: debian-ultralinux@KachinaTech.COM,,,
Subject: xia01 is now Debianized for UltraLinux development!

Debian developers,

I have spent some time this weekend to update our xia01, an UltraSPARC
system, to Debian 2.1 (slink). It went very smoothly. Thumbs up to all
who contributed. The TFTP image is identical to the one used to install
32-bit Debian 2.1 on xia02, a SPARCstation LX. We have enough space
to host a near-complete Debian mirror for i386 and SPARC architectures
including incoming/. The cron runs rsync every other day.

Now three systems (xia01-3) have two (xia01-2) running natively with
Debian. The remaining xia03 is still running UltraPenguin 1.09. I can
either convert it to Debian or upgrade it to the latest UP 1.19 and
take it as a reference system. Let me know what you think.

Again, these three systems are publically accessible to all Debian
developers and anyone who are interested in Debian UltraLinux project.
I will assign you account if you ask. I certainly hope every developer
get involved.

I will test this distribution with more hardware configurations and
document it in HTML some time next week. Frankly it is easy and smooth
to install.

Here is the latest motd:

             Welcome to Debian-UltraLinux Project!
  xia01: UltraSPARC I-170, 64MB, 3.5GB(system+/home2), 13GB(/Debian)
         Debian 2.1 (slink) Kernel 2.2.1 (updated on 3/27/99)
  xia02: SPARCstation LX, 64MB, 1.08GB, Debian 2.1 (Slink)
         Kernel 2.2.1 (updated on 3/18/99)
  xia03: Sun Ultra30, UltraSPARC II-250, 128MB, 4.2GB(system and data)
         UltraPenguin-1.0.9, kernel 2.1.125

  Note: xia01 and xia02 are contributed by Kachina Technologies, Inc.
  and xia03 is a loan system contributed by Sun Microsystems, Inc.

Best regards,


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Date: Mon, 29 Mar 1999 02:16:58 -0600 (CST)
From: Adam Heath <>
To: Debian Devel List <>
Subject: moving of dinstall's run time on master

This has turned into a heated topic, which was not my intention.  I never
meant to inflame anyone.  If I stepped on anyones toes, then I apologize for
doing so.

Now, for some clarifications.

My initial email was from the point of service provider.  Novare provides the
service of bandwidth to the debian project.  We also host several different
machines for debian.  Master, murphy(lists), faure, albert(both alphas).  New
to the list, and not yet online, are a sparc, and a new box donated by va.

Novare is charged based on how much actual data is transfered per month.  We
have a flat rate, upto a certain point.  After which, we get charged in
increments.  We have not come close to this limit, so we have not experienced
any additional charges.  Anyways, if we did, we would just pass them on to our
customers, so this point is mostly moot.

Our upstream provider, however, is charged based on how much bandwidth is
used based on a percentage of the available.  Having the mirror pulse happen
during peak net hours(3pm to 7pm, local time), can possibly hurt our upstream.
Now, you could say that we shouldn't care about our upstream, but, if we can
help them out, by having the mirror pulse moved, then I don't see any harm

Jason Gunthorpe, head debian admin, has setup mrtg on all major debian
servers.  This includes master.  To see the stats, go to  Note, that the numbers have been going down
over the past year.  This could probably be attributed to the fact that the
admin team has policed people to not do personal mirrors off master.  Having a
mirror pulse contact the tier-1 mirrors, which then contact master, and
pull-in the days updates, has helped the people who keep personal mirrors
spread their load around.

The stats at the address above, also include traffic that is generated by
novare itself.  This traffic does not go out to our isp, so it is not included
in the numbers that they tabulate.  Part of this novare traffic, includes a
local full mirror of debian, which is used by the alphas(and the soon to be
online sparc), and also by the rest of novare.  Master and murphy are not
physically located at novare anymore.  They reside at a colocation facility,
which is about 15 miles or so away.

I am a developer(see email above), and I also work at novare, which hosts
debian equipment.  So, I have a unique perspective on lots of sides of this
issue.  I know some of what master actually does, and what it is capable of
doing.  I also know about the donor's perspective.  This can sometimes lead me
in an awkward position.  Ean Schuessler, who is co-owner of debian, and my
boss, has very often asked for my opinion on internal debian affairs, seeing
as how I have a little over a year of actual 'debian work' over him.  He,
however, has been affiliated with debian, as an outsider, of sorts, for much
longer, longer than I even knew debian existed.

I will quote parts of my email, and add comments to them, so as to try and
explain, and to further clarify, what I meant.

My original email will be prepended with '> ', and my restatement will be
surrounded by '-'.  Any addition comments will follow the restatement.

> The current time that dinstall runs, 1:53pm CST(local), 7:53pm UTC, makes
> the mirror pulse happen around 3:30pm(9:30) to 5:30(11:30).  This is during
> peak network hours.  This is wrong, and this has to be changed.

Dinstall currently runs at 1:53pm(7:53pm).  Dinstall usually gets done
anywhere from 3pm(9pm) to 5pm(11pm), with a mirror pulse following immediately
after.  This mirror pulse contacts all tier-1 mirrors, ie, the mirrors that
update directly from master.  This is currently 9, split into 2 groups,
offset by 10 minutes.  3 of those are non-us mirrors(txs jason for the info).
The average update, for a full mirror, is around 50megs a day.

Peak hours locally are from 3pm(9pm), until normally about 7pm(1am).  This
corresponds to when kids get out of school, and get home, and go online, and
also when parents get out of work, and do the same thing.

Having the mass-update happen during peak, means the update might take longer,
as it has to fight with all the other accounts our isp has.  Our isp also is
charged differently for its bandwidth.  They are charged, not on the amount of
data they send over a month, but by how much bandwidth they use over a much
smaller period.  If they have a spike, during the day, they could see their
fees go up.  They, of course, would not like this.  They have noticed the
large spike coming from us(novare), and have inquired as to why it happens
during the middle of the day.

> I want to move the time that dinstall runs, and I was thinking about making
> it run at midnight (12:00am, 6am UTC).  This would put the mirror pulse at
> 1:30am (7:30) - 3:30(9:30).

We(novare) would like the time that dinstall runs to be changed.
Midnite(6am), is a nice round number.  This puts the mirror pulse at about
1am(7am) to 3am(9am).
Not much more can be said here.

> This email is not a discussion about whether to move dinstall's run time.
> It will happen no matter what.  This email is to discuss possible
> alternatives.

I am not going to restate this, because I find it a little hard to do so.  I
will just comment on it.

I am not aware of any technical problems with moving dinstall's time.  I was
under the impression that the current time was picked a little 'out of the
blue.'  So, I expected no opposition in having it moved.  I was looking for
discussions has to when a better time might be, as long as it wasn't during
local peak network hours.

> Did some initial discussion on irc(
> #debian).  Why can't we have dinstall run several times a day, and only have
> the mirror pulse run once?  Can dinstall's parts be run separately like
> this?

Again, I don't see much need for restatement.

This was thrown in, kind of as an after thought.  It doesn't quite fit in with
the tone of the rest of the email, and should probably go on a
'' setup(joey?).

Next, is a short followup to the original email, explaining something I left
> Sorry, forgot to say this won't be happening today, nor tomorrow.  I am
> shooting for the end of next week.  Say, saturday, apr 3.

This was to allay any fears people might have as to me doing something
unexpectedly.  The actual time that dinstall would have its time changed is
negotiable.  I wanted to make it clear that it would not happen suddenly.

Ok.  Done.  Phew.  Too much typing(I need to talk to Ean and enter into some
finger excercise classes).

I hope I have not left any loose ends, and I hope that this alleviates some
fears, that I have seen on this topic.

Adam, who was only trying to do his job

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.

Back issues of this newsletter are available.

This issue of Debian Weekly News was edited by Joey Hess.