On Wed, Apr 23, 2008 at 03:04:35AM +0200, Zbigniew Baniewski wrote:No, it's a valid question. There are hints of answers and even answers if you read the mailing-list archives, but it's possible to overlook them. Let me explain things to you another way. OpenBSD tries to have quality releases, with several goals. Those goals include keeping support for a variety of non mainstream architectures alive. There are various reasons for that, one of which being that it is useful for i386/amd64, because some other arches are good at finding some classes of bugs that affect all arches, but are more apparent on strict alignment architectures (for instance). It's also good because it attracts kernel and driver developers. With that in mind, OpenBSD-current is always high quality, in theory. In practice, comes release time, building and testing the release on each and every arch weeds out hundreds of bugs... and takes a big chunk of time and nerves out of Theo, and some other people involved. Thus the very quick reaction. We're trying hard to go up, up, up and have better and better releases. If you read the archives, you'll see lots of calls to test things, in a real community spirit, instead of the current `gimme, gimme, gimme' frame of mind a lot of our users have... so there have been some hard choices with respect to support, especially wrt backporting stuff to -stable, or actually making these releases. There will be hard choices in the future, undoubtedly. Hence the harsh reactions from the people involved in the release process. Just read the ml around `release build time' (which was a few months back, actually, that's how slow the release process is), and you'll figure out for yourself why `a release a month' is a bad idea, and also why the people involved reacted so violently to your apparently innocuous email... it kind-of implies the release process is something trivial you can change as you want, which it obviously is not... and it also dismisses the ten years of experience that our fearless leader has. Kind of insulting, don't you think ? ;-) Contrarily to what you might think, this email is NOT an exhaustive description of things as they are. It's a very quick, oversimplified summary, of a taxing process and decisions. There are glaring mistakes, for the sake of simplification. In a nutshell, release is ways harder to do than you think.
| Greg KH | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| mark gross | Re: intel-iommu: CONFIG_DMAR*=y kills my box |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Wink Saville | Resolving conflicts |
| Junio C Hamano | Re: People unaware of the importance of "git gc"? |
| Johannes Sixt | [PATCH 17/40] Windows: A pipe() replacement whose ends are not inherited to childr... |
| Junio C Hamano | Re: More precise tag following |
| Marco Peereboom | Re: Real men don't attack straw men |
| Michael | QEMU /dev/tun issue with tun device number > 3 (more than 4 guests) |
| Sam Fourman Jr. | Arc Raid Card trouble |
| Michael | Performance: OpenVPN vs IPsec |
| Vegard Nossum | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
| David Miller | [GIT]: Networking |
| Bernard Pidoux | inconsistent lock state with kernel 2.6.24.4 |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
