This is levelling down a distinction: there's spam that's definitely
spam and can be filtered reasonably easily before or after being sent
to the list. Sending something to the list that's not readily
distinguishable from other content is no longer a problem for a spam
filter, wherever it may sit. The fact that the list doesn't filter
spam for you mechanically doesn't mean members shouldn't intervene
against a different class of posting.
Well, if the principle is that this list is to build and support
community around OpenBSD, it's a question about what's considered
acceptable conduct within the community. Clearly there are strong
feelings on either side, but I gotta ask whether advertising a
redistribution, where there's not a lot of evidence of other
involvement in the community, doesn't at least come across as, at
minimum, genuinely subject to question. We can disagree as to what the
answer is, but the exceptional characteristics that make this a
question don't just answer themselves by the kinds of characteristics
or implications that have been argued in its favour.
Sure, but how about substantial questions like code audits for the PHP
code and determining processes and mechanisms for patching? Binary
distribution may not be a sin in itself (I've come around to the
opinion that it's largely oversold as to its benefits), but,
particularly if it's claiming to carry the flag of simplification, one
may nevertheless be circumspect about the approach and implementation,
by people who've not otherwise established standing in the community
and demonstrated the viability of their work in that context. I
understand why people who've made sustained contributions to OpenBSD
would not be happy with advertising a redistribution vexed by these
kinds of questions.
I've had enough experience with Unix engineering to have both sympathy
for someone who does this kind of work independently of established
community organs and a strong scepticism as to whether the product
will be nearly as robust as advertised or imagined for lack of strong
challenges and correctives from peers and existing centres of
expertise. I can't think it reasonable to be so taken away with the
sympathetic element of response as to overlook or underweight the
strong prospect of flaws resulting from the approach taken, and I
think it's adequate here that the issues be merely prospective, as
vetting needs to happen before a product is announced as shipping.
Conversely, with time spent talking about how you might solve the
kinds of problems entailed by such project, developers have a decent
chance of establishing credibility and the prospective quality of
their project well enough that they wouldn't necessarily have to
overload an existing channel to make release announcements.
Alternatively, such developers would recognise some fundamental
misconceptions and find other projects on which to expend their
energies.
My 2p,
Buffer G. Overflow
