www/111791: FreeBSD website messes up links

[Mark Linimon]

The following reply was made to PR www/111791; it has been noted by GNATS.

From: linimon at lonesome.com (Mark Linimon)
To: "Eric P. Scott" <eps+pcmt0704 at ana.com>
Cc: bug-followup at FreeBSD.org, remko at FreeBSD.org
Subject: Re: www/111791: FreeBSD website messes up links
Date: Fri, 20 Apr 2007 01:23:46 -0500

 Let me see if I can try to address some of the issues that you bring
 up in your mail.  I will note that I have no official status on the
 www team; my hats are portmgr@ and bugmaster at .
 
 On Thu, Apr 19, 2007 at 05:10:10PM +0000, Eric P. Scott wrote:
 > Justin, you're not the first person to be burned by this.  I
 > submitted my own PR (www/107291), and got blown off the same
 > way.  It's a legitimate complaint [...]
 
 If I can paraphrase what remko@ said when he originally closed the
 PR, the problem may be worth investigating, but the best approach
 would be to start a discussion on the freebsd-www mailing list to try
 to see what approach can be agreed on.  It's not something that can
 be fixed by an easy patch; we need to get people to agree on what we
 want to do first.
 
 > and it's one of the most frequent examples pointed out to me [by
 > Linux advocates] of how "we" "just don't get it."
 
 Are you speaking of this particular bug, or the type of response?
 
 I won't say that I would have worded the response exactly the same way
 that remko did (I do have the advantage of having English as my primary
 language, and several more years' experience dealing with FreeBSD PRs),
 but _what_ he said does not seem that unreasonable to me.
 
 To me, it's a big jump from a response to one PR to a generalization
 about how the project works.  If remko's response wasn't appropriate,
 I would rather this have been handled by email to bugmaster@, or, if
 that is unsatisfactory, to core at .
 
 FreeBSD does indeed have a few individuals (I do not count remko as one
 of them) who can be irritable, or even irritating.  However, the vast
 majority of people who work on FreeBSD just go about working on areas
 that they find interesting, without creating a great deal of fuss or
 bother.  These are the true heroes of our project and not enough is said
 about them.  To me, they're the ones that set the tone of the project,
 and the others I do my best to ignore.
 
 > Our web site is an important marketing and communications tool.  In
 > its current state, it's alienating the very people we're trying to reach.
 
 I know that the current website design is controversial, but not everyone
 agrees that it is that bad off.  The problem with any project is that
 achieving perfect consensus is impossible.
 
 > The adamant refusals to repair what is so obviously and seriously
 > broken only help fuel a mounting perception that FreeBSD has fallen
 > into the hands of arrogant jerks
 
 Please understand, it's your opinion that it's seriously broken; not
 everyone agrees.  (I, myself, have no opinion.)
 
 As for the 'mounting perception', I would counter that when I first
 started following FreeBSD around 2002, that there were indeed problems
 both with the volunteers, and the codebase.  (The extra years that it
 took to get past our rewrite to move towards SMP cost us, both in
 terms of user perception, and the stress level of the volunteers;
 some of which was reflected in the user lists.)
 
 However, since the release of 6.0 (which had a very small number
 of problem reports as compared to the 5.X releases), my impression
 is the opposite of yours: we seem to be seeing far fewer PRs for
 the base system (even as the ports PRs show that people are indeed
 adopting 6.X); the interest about new features on the mailing lists
 is up; and some companies that use FreeBSD in their products are
 taking interest in 6.X, including some that decided to simply skip
 5.X to see what happened.  In addition, behind the scenes there is
 some interesting work being done in increasing the performance for
 what will become 7.0.  With the 5.X series, there was simply too much
 code churn for anyone really to focus on performance.  We learned
 from the mistakes we made during that timeframe: we will no longer
 hold releases indefinitely waiting for features to be complete; we
 will try to release on a regularly scheduled basis rather than letting
 the feature set dictate; and we will be much stricter on backing out
 feature sets before major releases if we find that they aren't ready
 yet.  I think this proves that we are willing to admit mistakes,
 learn, and go forwards, even given that it's a painful process.
 
 > (believe me, I'm toning this down).
 
 Well, I'm thankful for that, at least.  It is very challenging to
 do a great deal of work and then get strongly negative feedback for it.
 I don't think this is something that one appreciates until sitting on
 this side of the equation ...
 
 > I'm seeing a lot of small and medium-sized businesses migrate their
 > [no longer supported] FreeBSD 4.x-based infrastructure
 
 4.X is no longer suitable for modern hardware.  5.X and 6.X completely
 revised (or introduced) the interrupt handling code, the power handling
 code, and the ATA code, among other things.  This is in addtion to all
 the rework necessary for pratical support of multiple CPUs and multiple
 cores, which are rapidly becoming the rule rather than the exception.
 
 Are there regressions in 6.2 vs. 4.11?  Yes, a few, mainly falling
 into the categories of a) performance and b) certain hardware.  As I've
 mentioned above, we are working hard on a).  For case b), I'm trying
 to work through GNATS and identify regressions on at least the most
 common hardware that's out there.  (It is impossible to support every
 single possible system, of course.)
 
 I would also be interested to know why the businesses you mention haven't
 been active on the mailing lists saying that that's what they are doing.
 Without this, it is hard for me to evaluate what kind of job we're really
 doing.
 
 Finally, developer attention to 4.X effectively stopped more than 2 years
 ago.  For a while, we required the ports developers to keep supporting it,
 but it's simple too much to ask for anyone to support 4 (!) major branches
 at once.  We're down to 3 now; I have strongly lobbied for there to only
 be two at any given time in the future.  However, we may well be stuck
 with 3, due to committments we've already made.
 
 The decision from the portmgr team (which I am on) to delete to support
 for 4.X was for two reasons: one, to ease the burden on our maintainers
 and committers (although we had told them that it was optional, they
 were still spending a fair amount of time trying to keep ports going
 with various changes anyways); and two, to try to move the userbase off
 of it, rather than letting the issue drag on into the indefinite future.
 This latter is what convinced me that it was time to make those commits.
 
 > away from FreeBSD entirely.  The number one reason they give for this
 > is "attitude."  This outranks concerns about technical issues (features,
 > performance, etc.).
 
 It depends on who you ask.  To some users, stability is the only thing
 that matters; to others, without high performance, it's not even worth
 considering FreeBSD.  Everyone else says "we're going to leave unless
 feature XYZ is added."  To other people, the way that the develpers
 interact with them is the most important.  However, my own feeling from
 reading the mailing lists is that they are in the minority.
 
 > They don't like the current state of affairs, and have little
 > confidence things will turn around any time soon.
 
 Again, my own impression is that we've made progress since 2002.  If
 these other users feel like this, they need to speak up (if not on
 the public mailing lists, to core@) so that we can try to identy and
 fix problems.
 
 > FreeBSD is driven by a large, enthusiastic volunteer community.
 > The vast majority are good, hard-working, caring people, who help
 > keep us on track.  There are a few--and I stress few--whose
 > actions (or inactions) reflect poorly on the rest of us.  This is
 > hardly a unique situation.
 
 This is going to be true of any volunteer project.  Again, although
 I would not have worded the response the way that remko@ did, I do
 feel he's one of the "good guys" on the project, and because of all
 the work he's done, deserves a little leeway.  I hope you can see my
 point of view on this.
 
 > Thank you for adding your voice, and try not to let this
 > experience dampen your enthusiasm.
 
 mcl