Subject: Re: [HEADS UP] Platform support
To: None <firstname.lastname@example.org>
From: Joerg Sonnenberger <email@example.com>
Date: 07/21/2007 18:11:43
On Sun, Jul 22, 2007 at 12:57:54AM +0900, OBATA Akio wrote:
> --On 2007-07-21 15:13 +0200 Joerg Sonnenberger <firstname.lastname@example.org>
> >On Sat, Jul 21, 2007 at 01:53:13PM +0900, OBATA Akio wrote:
> >>I have to disagree. Why "bulk build" means "supported"?
> >Because it is the most basic measurement.
> Bulk build is just a tool to build binary packages,
> help to find problems and confirm fix, rather than
Excuse me, but how is that not a metric for how well a platform *builds*?
I'm not talking about anything advanced like human testing, but the
level of automatic regression tests.
Please, before going into a fantasy world what the ideal definition of a
supported platform should be, take a look at what we have right now. The
list of supported platform is pretty arbitrary. Frankly, I wouldn't
trust some of the mentioned platforms to even bootstrap correctly. AIX
5.1 certainly does not. Does this definition of supported ("did
bootstrap once and has some mk/ templates filled out") have any
practical relevance? I don't think so.
Do you believe that a platform can be supported in any meaning full way
if we don't have a way to find regressions? A bulk is the most basic
measurement for regressions because it is (a) mostly automatic and (b) easy
to setup given the hardware. It does not mean that developers will
magically pop up and fix things. It does not mean that new breakage is
not introduced by updates and infrastructure changes. But it means that
we will at least know about it when it happens.
Now take a second look at the status quo. How hard to do you want to
make it to keep a platform as supported? I intenionally didn't special
case NetBSD here. Can you seriously say mips is a supported platform for
pkgsrc? On what foundation? A bulk build is again a relative low
barrier. I'm all for raising it later, but raising it too high in one
step is a lot more likely to kill effort than to help progress.