Debian Weekly News - email
Date: Sun, 28 Mar 1999 21:48:05 +0200 From: Martin Schulze <joey@finlandia.Infodrom.North.DE> To: Debian Development <firstname.lastname@example.org> Cc: Debian QA <email@example.com> Subject: Reviving Debian QA Hi, [ Mailing to Debian Development and Debian QA, please send replies *only* to Debian QA <firstname.lastname@example.org> ] as many people out here already know debian-qa has been quite quiet lately. 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 etc.) 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 properly . 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 needed. 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. Regards, Joey -- 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 email@example.com with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Date: Sun, 28 Mar 1999 21:55:16 +0200 From: Martin Schulze <joey@finlandia.Infodrom.North.DE> To: Debian Policy <email@example.com> 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 now. Regards, Joey --------------------------------------------------------------------------- * 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 <firstname.lastname@example.org>): 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 <debian-QA@lists.debian.org>", 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 email@example.com with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Date: Sun, 28 Mar 1999 18:14:36 -0700 (MST) From: Ward Deng <wdeng@KachinaTech.COM> To: debian-ultralinux@KachinaTech.COM, email@example.com, firstname.lastname@example.org, email@example.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, --ward -- To UNSUBSCRIBE, email to firstname.lastname@example.org with a subject of "unsubscribe". Trouble? Contact email@example.com
Date: Mon, 29 Mar 1999 02:16:58 -0600 (CST) From: Adam Heath <firstname.lastname@example.org> To: Debian Devel List <email@example.com> 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 done. Jason Gunthorpe, head debian admin, has setup mrtg on all major debian servers. This includes master. To see the stats, go to http://master.debian.org/mrtg/. 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(irc.debian.org(also irc.openprojects.net) > #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 'firstname.lastname@example.org' setup(joey?). Next, is a short followup to the original email, explaining something I left out. ---- > 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 email@example.com with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
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.