Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)

2012-10-26 Thread Mark Linimon
On Fri, Oct 26, 2012 at 09:34:20AM -0700, David O'Brien wrote:
 (there are no pre-build packages for 10-CURRENT).

Please see the first two entries on:

  http://pkgbeta.freebsd.org/

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)

2012-07-17 Thread Mark Linimon
On Tue, Jul 17, 2012 at 01:56:33PM -0700, Dave Hayes wrote:
 I've been using FreeBSD since the 90s. My perception (over many
 years of observation) is that the FreeBSD people most able to
 document what exists and how to use it seem to also have the
 greatest resistance to writing any documentation.

I'll just note that over the past ~6 months, the documentation team has
seen a lot of new contributors and new energy.  So from my view, the
situation is improving.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Mark Linimon
On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote:
 That is already done in Gentoo FreeBSD, or do you want me to do the
 work for you to integrate OpenRC in the base system?

We want you to do the work to prove that it is an improvement.  Otherwise
it's just another claim.

You seem to be missing a couple of principles here, the most important
of which is first, do no harm.  FreeBSD has as one of its underlying
principles not to violate POLA (Principle Of Least Astonishment.)  The
corollary is that we don't replace code unless we're convinced (not just
told) that the replacement is a better solution.

If this makes FreeBSD more conservative than the way other OSes do
things, so be it.

I'm not trying to be harsh here.  What I'm saying is that the burden
of proof is on the person making the claims it's better to demonstrate
that it's so.

Otherwise, there are a zillion PRs with patches already in the database
for committers to pick up and work on.

 I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate
 OpenRC into FreeBSD would be an inefficient use of my time. Not only
 would I fail to gain any improvements on my systems, but I would divert
 development time from things that do benefit me.

Then I expect the situation to remain unchanged.

fwiw, from previous discussions on FreeBSD boot time, ISTR that there
are other places where more time is spent.  Some analysis to prove that
indeed the rc subsystem is the dominant term would be a good starting
place.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Replacing rc(8) (Was: FreeBSD Boot Times)

2012-06-20 Thread Mark Linimon
On Wed, Jun 20, 2012 at 04:17:52PM +0300, Vitaly Magerya wrote:
 The last time concurrent rc patches where proposed I measured boot time
 on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from
 power on to login prompt, 20-25 where spent in rc, and parallel
 execution of it shaved off 7 seconds from boot time.

OK, I stand corrected.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-15 Thread Mark Linimon
On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote:
 I'm thinking we might jump straight from 8.x to 10 when the time comes,
 I'm really looking forward to Gleb's work on CARP and PF ;)

I don't know why you might think one .0 release would be more mature
than another .0 release.  Maybe I'm misunderstanding.

 There are not many boxes I could try 9.0 on, because they're in
 production with pfsync to conserve client sessions and I'm loath to
 take risks with most of our firewalls.

This is where having one or more systems for development is key.

Installations like yours are in a far better situation to test FreeBSD under
realistic loads than are all but a few of the FreeBSD developers.  I would
urge testing long before the leadup to a .0 release, not afterwards.

Apologies if I'm just repeating myself here, but FreeBSD does not have a
dedicated QA department.  We are reliant on our users to test in real-
world conditions.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-14 Thread Mark Linimon
On Thu, Jun 14, 2012 at 06:50:34AM +0200, Wojciech Puchar wrote:
 does it matter. cvsup RELENG_8 and you see updates are done constantly.
 just sometime somebody decide to change number :)

The difference is the freeze-and-test work that goes between random
date and release time.  This requires a nontrivial time committment
from both developers and users.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-14 Thread Mark Linimon
On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote:
 Whoever said STABLE is no good for production ?
 
 I used to make us stick to 8.2-RELEASE here at work, but some bugfixes
 are just too important to skip (we're running firewalls and had a
 problem with a CARP bug).

In theory we try our best to keep -STABLE, well, stable in behavior and
not just the API, but in practice any given snapshot of -stable may or
may not have uncaught regressions in it.

I reiterate, the major difference between -stable and -release is a more
thorough QA process for the latter :-)

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-13 Thread Mark Linimon
On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote:
 The only way that this would really work is if there were dedicated
 sustaining engineers working on actively backporting code, testing it,
 committing it, etc.

I'm going to agree with Garrett here.  IMHO we've reached (or surpassed)
the limit of what is reasonable to ask volunteers to commit their spare
time to.  This is doubly true when we have more than one stable branch.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: usertime stale at about 371k seconds

2012-06-12 Thread Mark Linimon
On Wed, Jun 13, 2012 at 12:30:08AM +0400, Andrey Zonov wrote:
 No, I didn't.  I want to fix the problem not just file a PR and wait
 for years.

I do understand your frustration, but we have some new people interested
in picking up and handling src-related PRs, so I see the situation as
improving a bit.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-12 Thread Mark Linimon
On Tue, Jun 12, 2012 at 07:08:08PM -0400, Jerry McAllister wrote:
 You sound like the people who can't decide to get something because a
 new version is going to come out sometime before they die.

That may be how it seems to end-users, but as we have heard multiple
times from people who use FreeBSD to help run their businesses, information
about scheduling and support of releases is key to their decisions on when
to upgrade, or even whether to use FreeBSD in the first place.

To them, your characterization is going to sound quite unfair.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Upcoming release schedule - 8.4 ?

2012-06-11 Thread Mark Linimon
On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote:
 I am looking at the upcoming release schedule, and I only see 9.1
 listed - can anyone confirm or deny 8.4 ?

Although I am not on re@, AFAIK the only schedule that is on the table
is the one for 9.1.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-02-18 Thread Mark Linimon
On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote:
 1. Incidentally, what exactly does constitute a major release?

That point in time where we guarantee that we break a certain degree
of backwards compatibility.  (Well, that's the key component.  Feature-
additions ride on top of that.)

 2. Is there a reason to update the numbers so quickly?

Yes, so that we don't have to keep supporting backwards compatibility
for as long a period (see 1) -- it's a significant burden to maintain.
It's necessary to do these as we rework things like network layers for
higher performance, rework wireless to work with modern devices, and
other high-demand items.

 3. Could a higher bar be set to reach a major release than simply
 temporal objectives?

Yes.  We did that with 5.x, and blew it big-time.  The goal of rewrite
the entire system to support SMP in a scalable, reliable fashion was
simply too aggressive.  It led to ~5 years between major releases, and by
that time the system had changed very dramatically (SMP, suspend/resume,
IIRC GEOM, and too many other things to list).  It was a huge jump and
the learning curve for upgrading was way too large.  We lost userbase.

Also, keeping 5 years between major releases led to very high developer
frustration.  Why work on something when it will take 4+ years to even
see the light of day?

This is why we moved to the time-based releases.  18 months was seen as
a compromise between all the various demands.  Even so, we are almost
exactly at 24 months in practice; see the graphs I updated last month as
a result of all the recent discussion:

  http://people.freebsd.org/~linimon/schedule/

My own view is that 5 years between major releases is not going to happen,
due to how painful the 5.x experience was for all concerned.  But as I'm
not a src committer, I'm not one of the people who will be picking the
interval for our major-branch timeline.  I just try to graph it as it
goes by.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-26 Thread Mark Linimon
On Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote:
 http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html
 
 New releases of FreeBSD are released from the -STABLE branch at
 approximately four month intervals.

That was our intention at one point.  Obviously we've not stuck to that.
(IMHO doing releases quite that frequently is probably beyond what we can
do with volunteer staffing, but I'm not on re@ so take it as you will.)

In any case, various people within the project have now absorbed the
lesson that 10 months between releases is too long, and are trying to
figure out what to do about it.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-26 Thread Mark Linimon
On Thu, Jan 26, 2012 at 10:52:44PM +, Mark Blackman wrote:
 I suspect poor old RE is putting too much work into BETAs and RCs for
 point releases. 

The counter-argument is that we have a lot more leeway to make mistakes
on a .0 release.  We're not going to be cut any slack at all for shipping
a badly regressed point release.

Some minor regressions are inevitable in software, but they do indeed
need to be minor.

For how we're doing with regressions in general, see:

  http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html

Now, it's true that many of the recent PRs are against 9.0, and many of
the ones that aren't may be stale (certainly most of the pre-2010 ones),
but these are the types of things that users really notice and become
unhappy about.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-25 Thread Mark Linimon
 I might just be also interested to review/comment code, discuss
 regressions, and architecture, for a change ;-)
 Unfortunately, such threads rarely ever happen. Most of the time, the
 only food provided is a really indigestible +5000/-3000 patch, where
 all the thinking, architectural design and code has been done behind
 closed door of a limited few committers, research lab or company.

That's odd.  What the src committers usually tell me, when I have my
bugmeister-advocate hat on, is that they post patches and then no one
comments until after they check them in, at which time they complain.
This discourages them from going through this the next time.

You will also note that some of the large commits say MFp4 or MF:
projectname.  That means that either our Perforce repository, or
SVN project/ directory, were used as staging areas.  It's possible to
subscribe to these email messages.  (Exactly how is left as an exercise
for the reader; the hour is getting late.)

As for the research lab/company commits, I'm sure you'd complain equally
if the code that these groups develop in-house and then release when it's
in some kind of stable state, instead didn't get released at all.

But, of course, I'm wasting my time trying to give you reasoned arguments
about why FreeBSD does one thing or another.  AFAICT you're only interested
in spreading FUD about what we do, how we do it, and what we say about it
before, during, and afterwards.  You seem to be obsessed by picking over
semantics and finding shortcomings to be aggreived over.

Whatever patches or review you've contributed to date, to my mind, are
like the last tiny little bits of onion that are left over after one peels
off all the outer layers.  There may be something to it, but the effort
to get down to that point is so painful that it's not worth it.

tl;dr: your drama outweighs your contributions.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-25 Thread Mark Linimon
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote:
  You seem to be obsessed by picking over
  semantics and finding shortcomings to be aggreived over.
 
 Semantics and proper, independent, API are crucial.

I'm talking about the semantics of the non-technical part: the wording
of things that people post in email.  viz: the time-wasting nonsense
about oh, it seems to be released already, has anyone noticed? from
a few weeks ago.

It was 100% FUD, which apparently you knew perfectly well at the time,
and thus AFAICT only posted it to draw attention to yourself.

That's the drama I'm talking about.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-24 Thread Mark Linimon
 On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote:
 It is less a problem of having the tools than having the will to do
 everything publicly. From experience, committers loves to do all kind
 of things privately/secretly.

Perhaps it's human nature because of all the increasingly nit-picky, passive-
agressive, whiny, sarcastic, and generally asinine postings such as yours.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-24 Thread Mark Linimon
On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote:
 It would also be good to have some wiki.freebsd.org page that
 would describe what information is needed to fill a good PR

See:

  http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ .

Your suggestion to include things like dmidecode is a good one, and
we should add those.

 I still was (or at least felt) that was a FreeBSD newbie that time,
 so I did not knew if my 'handbook part' was just rubbish, or stupid,
 or ... whatever, no one responded, so I assumed that its not
 needed/useless and moved along.

I'm hoping that the forums are a better place for new users to ask
questions these days, than the high-volume mailing lists.  In theory
it should be a more appropriate venue.  (Having said that, I don't
participate in the forums due to lack of time, but I understand there
is a community of moderators and seasoned users on it.)

 It would be also good to have a wiki.freebsd.org page describing
 what is needed and in what format a user should send the
 documentation changes

Perhaps there should be a docs analogue to the following:

  http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/

doc folks, any takers?

 I have now filled these PR's here:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=164431
 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432

Thanks.  This makes these issues visible.

 So its time for another article/page on wiki.freebsd.org, how to become
 a committer and help to solve PRs'

See:

  http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/
  http://wiki.freebsd.org/BecomingACommitter

 how to add your mirror to FreeBSD project

See:

  http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/index.html

So, let me add in conclusion, I'm willing to give a hearing to constructive
criticism such as this posting.  There are some good, concrete, suggestions
here.  If I've given the impression in my earlier response that I'm not,
I'm sorry.  OTOH I see a lot of non-constructive criticism go by and you'll
have to excuse me for being rude to those posters.  After the Nth posting
like that it's simply too much for my patience.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-22 Thread Mark Linimon
On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote:
 I submit PRs and try to help test them as some developer/committer
 will pick up the PR, submit a patch to test, but it was MANY times
 that the response from developer/committer was way too long that
 I even DID NOT HAVE THE HARDWARE anymore ...

I don't have a magic wand to solve this problem.  I've spent a lot
of time thinking about it and it's just a hard problem to solve in
general.  There are several aspects:

 - so many computers are very broken (specifically, horrible BIOS
   bugs).

 - most committers only have one or two computers that they work with.

 - most committers have their own tasklist, and support users is
   something they never have time to get around to.

support users is, in general, something Open Source OSes do not
do very well (at least without a paid support staff, as is the case
in some of the Linux distros.)

But what's discouraging for the people that try to clean up the stale
PRs is that they get yelled at when they try to do so.  Thus, they
tend to get demotivated as well.

Support/bug triage is hard and unrewarding work.  People can tend to
feel that they're being blamed for bugs that they had nothing to do
with creating, and burn out.

 Here is one of the messages that I sent by then to the mailing lists:
 http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html
 
 ... and NOTHING HAPPENED, no one told me what to do next,
 should I sent a SGML version or anything ... or just GTFO.

I'm sorry that nothing happened, but unfortunately that's common.
Submitters sometimes have to be persistent, and maybe even catch
new committers when they sign up.  Our documentation is certainly
in need of updating.

 What I have done about these 'Ports issues'? I contacted these
 ports maintainers and said that both RC script and AIO support for
 samba should be enabled by default by linking to several threads
 at FreeBSD Forums that the problem is known and exists ... and I
 did not get ANY RESPONSE till this very day, not even a GTFO
 (which would probably be better then nothing).

When you don't get a response from a maintainer, your best bet is to
file a PR against the port.  If the maintainer doesn't respond, then
after 2 weeks any FreeBSD ports committer is free to work on the PR
and, if they agree with you, commit it via maintainer-timeout.

We don't have a way to track emails that various users send to individual
maintainers.  With a PR open, we have a way to do that.  We also track
maintainer-timeouts, and these can eventually lead to a maintainer reset.

 I got these maintainers email addresses from http://freshports.org
 page, are they up-to-date there?

They should be, but looking on cvsweb will tell you for certain.  IIRC
on each freshports page there is a link to cvsweb for the port.

 It's not that people does not try to help, a lot tried (and I am still
 trying), but its VERY unpleasant to have awareness, that you dedicated
 your time, tried to help as much as possible, made some steps to achieve
 that ... and no one even cares about that.

I think it's not don't care, I think it's that unable to cope with
number of incoming PRs and other requests for changes and support.
As I type this, there are 1122 ports PRs (6272 total PRs).  On most
days, around 40 come in.  It would take a few dozen more volunteers
to be able to keep up with them all.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-22 Thread Mark Linimon
On Wed, Jan 18, 2012 at 02:18:50PM +0200, Andriy Gapon wrote:
 So software can already send the reminders, but the real problem is to
 assign the PRs in the first place.  Currently most assignment are self-
 assignments.

My experience has been that assigning PRs to people who have not
specifically requested that PRs related to that subject be assigned
to them, almost always results in the PRs languishing.  This is why
I (with bugmeister hat on) discourage the bugbusters from doing so.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-22 Thread Mark Linimon
On Sun, Jan 22, 2012 at 11:15:09PM +1000, Da Rock wrote:
 Scroll up and count the serious and critical bugs too :)

 I didn't realise it broke the numbers into the sections.

Yeah.  The problem is that, over time, the values in those fields has
become meaningless.  Some of us try to triage what should and should not
be 'critical', but other than that, the whole concept has become useless.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-20 Thread Mark Linimon
On Tue, Jan 17, 2012 at 02:43:21AM +, Igor Mozolevsky wrote:
 To be realistic, I think any serious developer should expect to spend
 70% of their development time on maintenance

s/developer/paid developer/ and you've got a correct model of how commercial
software companies work.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD has serious problems with focus, longevity, and lifecycle

2012-01-20 Thread Mark Linimon
On Tue, Jan 17, 2012 at 06:45:17PM -0500, Daniel Eischen wrote:
 The problem I have with ports is that there is not a -stable branch
 that tracks with -stable core.

We've been working for 18 months to try to get the hardware infrastructure
in place to be able to consider such approaches.

 It doesn't even have to be every port, just the commonly used ports.

That's easy in theory, but extremely difficult in practice.  The infra-
sturcture is far more heavyweight (because of demand for features) than
most people give it credit for.

There's no concept of subset of ports tree.  Go examine the hierarchy
and it will become apparent why.

Even a server-only concept doesn't get you as far as you might think.

Again, the general problem is hard.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Giant lock gone? (was: Re: ...focus, longevity, and lifecycle)

2012-01-19 Thread Mark Linimon
(sorry to reply to Doug but not Dieter, but I have already deleted the
prior email)

 On 01/18/2012 16:58, Dieter BSD wrote:
 So you are saying that the Giant lock was completely removed in 7.0?

It was completely removed from the network stack.  That was the missing
qualifier in his sentence.

So, to a first approximation, it had been removed from all the places
that were true performance-killers.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Recommended amount of swap

2011-09-05 Thread Mark Linimon
On Mon, Sep 05, 2011 at 02:48:57PM -0500, Dan Nelson wrote:
 I suggest 2x RAM for systems less than 4gb or so.  Anything more than 4GB of
 swap is probably never going to be used

I see you don't do mass package builds :-)  Or, even build openoffice or some
of the math packages.

 and if it is used, you're just going to thrash your swap device.

That's us! :-)

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: A style proposal for referring to upper-level directories in Makefiles

2011-07-29 Thread Mark Linimon
To me, it just makes things less readable.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: [PATCH] __FreeBSD_kernel__

2011-07-04 Thread Mark Linimon
On Sun, Jul 03, 2011 at 05:47:02PM +0200, Robert Millan wrote:
 isn't it enough if support is present in the FreeBSD
 version of these compilers (for production and development releases of
 FreeBSD), plus the latest release of the upstream version of each of
 those compilers?

You may find the gcc team very uninterested in changing things around
to support FreeBSD.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: E-Mail if updates available? [SEC=UNCLASSIFIED]

2011-03-30 Thread Mark Linimon
On Wed, Mar 30, 2011 at 02:05:32PM +0800, Wilkinson, Alex wrote:
 
 0n Wed, Mar 30, 2011 at 07:31:27AM +0200, Jo Galara wrote: 
 
 on Debian I'm using apticron which sends me an email if there are
 updates available for installed packages. Is there a similar program for
 FreeBSD?
 
 subscribe to: http://www.freshports.org/

That covers ports, but not packages.  We don't have anything like that in
place right now.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: [patch] small fix to stop gcc warning for lib/libstand/assert.c

2010-03-14 Thread Mark Linimon
On Sun, Mar 14, 2010 at 01:12:14PM +0100, Alexander Best wrote:
 ah ok. thanks for the hint. just wanted to spare linimon from dealing with
 such minor prs. ;)

It's much more efficient for the project to have them in GNATS.

I tend to triage PRs with the TV on, so it's not like the trivial ones
are a great burden.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: package building failure irritation

2010-02-26 Thread Mark Linimon
fwiw, the canonical way to find out if a port will package up in a
clean environment (choort, with dependencies all loaded via package)
is on http://pointyhat.freebsd.org/errorlogs/ , e.g.,
http://pointyhat.freebsd.org/errorlogs/i386-8-full/ .

http://portsmon.freebsd.org gives you lots of cross-references into
it and the PR database.  Ignore the 'connection failed' message, it
is transient and I need to fix it RSN.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Weekend PR smashing

2010-02-05 Thread Mark Linimon
On Thu, Feb 04, 2010 at 04:09:48AM -0600, Mark Linimon wrote:
 Reports that are duplicates indicate that various users are being affected
 by one underlying problem.  At one point I was trying to gather them all
 into a page.  I was hoping more people would do the analysis and send me
 additions for it.  However, it looks as though the script that generates
 that page has rotted.  I'll re-add it to my list of things-to-do ...
 
   http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html

This report is now fixed.

 We have more kern/ PRs than any other category.  This category is
 overloaded to mean both kernel, libraries, networking, and device
 drivers.  http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html
 makes this much more tractable.

I forgot to mention the 2-level hierarchy that I have set up, where you
can look at PRs starting with e.g. disk/driver and then drill down to
a page that references all the related PRs by manpage.  It may have been
just as well, since the report had also gotten stale.  However, it is once
again up-to-date:

  http://people.freebsd.org/~linimon/studies/prs/prs_for_all_groups.html

 There would also a slightly different way of looking at things, the ones
 with '[panic]' in the Synopsis.  Hmm, I thought there was such a page,
 but it doesn't seem so.  I'll put it on my list to create one.

Now created:

  http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_panic.html

Finally, I have fixed other problems, such as broken links, in other various
pages under

  http://people.freebsd.org/~linimon/studies/prs/

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Weekend PR smashing

2010-02-04 Thread Mark Linimon
[adding freebsd-bugbusters@ to the Cc:]

I'm sorry I didn't respond to your earlier message.  I am currently way
behind on tasks that I've already promised people.

The KDE howto that you cited 
(http://quality.kde.org/develop/howto/howtobugs.php)
is quite a good one.  Our pr-guidelines document isn't as thorough.

Part of the problem is that we don't have enough metadata in GNATS to
capture some of the things that we would like bugbusters to do, e.g.,
as they suggest:

 - attempting to reproduce an 'unconfirmed' bug and change it to 'new'

The closest that we have is the 'analyzed' state, which we have used in
the past to indicate 'confirmed'.  If you can indeed reproduce a bug,
it's fair enough to let bugmeister@ know and we can change the state.
Alternatively, you can submit a followup and suggest that.  Several
of the folks on the bugbusting team (e.g. people who have GNATS access)
monitor the mailing lists and try to track followups.  (I personally
track bugs@, ports-bugs@, and a few of the others, but not some of the
specialty ones like n...@.)

 - check if a report is a duplicate

Reports that are duplicates indicate that various users are being affected
by one underlying problem.  At one point I was trying to gather them all
into a page.  I was hoping more people would do the analysis and send me
additions for it.  However, it looks as though the script that generates
that page has rotted.  I'll re-add it to my list of things-to-do ...

  http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html

At this point it may be easier to look at the template that I grind up to
produce that page:

  http://people.freebsd.org/~linimon/wellknown.prs

It's clearly over a year stale, and could thus use a new set of eyes.

 - add '(regression)' to the title if indicated

I think we've done a fairly good job of getting '[regression]' (our styling
of the same idea) into the existing ones, and keeping up with new ones as
they come in.

Similarly, we've done pretty well with '[patch]' AFAIK.

That's my reaction to some specifics on the the KDE page.  Now for some
more general comments.

We have more kern/ PRs than any other category.  This category is
overloaded to mean both kernel, libraries, networking, and device
drivers.  http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html
makes this much more tractable.  (I have other ideas about how to do
much better, but see below.)  Whether or not existing PRs are still
relevant seems to vary a bit by sub-category.

There would also a slightly different way of looking at things, the ones
with '[panic]' in the Synopsis.  Hmm, I thought there was such a page,
but it doesn't seem so.  I'll put it on my list to create one.

As for the bin/ PRs, you'd be surprised at how many of them are still
relevant, even after several years.  I've resisted the suggestion that
others have made in the past just to close them for this reason.  (In
the past I have made an effort to contact submitters and ask them if
they are still experiencing the problem, but portmgr duties have kept
me away from that for a long time.  This is something else where we
need help.)

The i386 and amd64 PRs are more likely to be can't install/run on a
particular piece of hardware, and generally require the most interaction
with users to isolate the problem (e.g. to ACPI interacting badly with
a buggy BIOS; irq problems; devices not being supported by our current
drivers; and so forth.)  To work with these people need to have a bit
of experience with low-level debuggers and how to examine stack traces.

 one of the things that concerns me is the sheer number of PRs with
 patches that either have been committed without the PRs being updated

Well, that's a task that needs more people working on.  You can start
by looking at:

  http://people.freebsd.org/~linimon/studies/prs/prs_possibly_committed.html

which is PRs that have had followups appended to their Audit-Trail by
the checkin scripts.  If these changes have already been merged to all
the relevant -stable branches, they should be closed; otherwise, if they
are not already set to 'patched', then they should be, and assigned to
the committer who made the change.

 or the patches are simply sitting idly in PRs.

There are certainly a large number of these.  IWBNI we could get more
of them into the 'analyzed' state to claim 'we think this patch might
solve the problem'.

 The list by the bugbusters waiting for committers to check them out
 is pretty huge as well:

Yes, I'm well aware of that, since I set it up :-)

This goes to the more general problem that it's more fun to add new things
than it is to fix existing things.  FreeBSD has traditionally done much
better at adding new features than in the more mundane maintenance work.
This is a problem not just with FreeBSD or even open source projects in
general, but all software.

What's interesting is that this situation is slowly changing (again IMHO).
Over the past year we have seen several 

Re: HAMMER FS port (status ?)

2009-09-24 Thread Mark Linimon
On Thu, Sep 24, 2009 at 01:35:21PM -0300, Leandro Quibem Magnabosco wrote:
 I think that one questions pops into the minds of a lot of people right  
 now: Why not just use DragonFly BSD?

Feel free, but take it off-list, please.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: genuine cpu I386_CPU kernel support

2009-09-23 Thread Mark Linimon
On Wed, Sep 23, 2009 at 05:54:34PM +0200, Julian H. Stacey wrote:
 4.11 fell out of security support some while back, but
   http://www.freebsd.org/security/index.html 
 only lists what's still in, not what fell out when.

Then see http://people.freebsd.org/~linimon/schedule/milestones.html.
(Yes, I know the data for 7.2 and 8.0 are stale.)

4.11 support was extended again and again but ended 01/31/2007.
Towards the end it was consuming a lot of people's time to support
it, since everything newer had changed dramatically.

 Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of
 BSD to 386.  Would be nice if we could still keep that first platform
 walking, even if speed can't be called running ;-)

The same comment applies.  Everything has changed dramatically.

 Maybe I'll get time to chase down all that came before
   http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784

I honestly can't see why you would want to waste your time like this,
but it's yours to waste I suppose.  (Even a notorious packrat like me
has gotten rid of hardware from that era.)

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: FreeBSD jobs

2009-05-15 Thread Mark Linimon
On Fri, May 15, 2009 at 06:54:53PM +0200, Julian Stacey wrote:
- Those that pushed to censor jobs@ some years ago ( succesors?)
  are not worth having, j...@freebsd would be better without them.

In your opinion.  Not in mine.

- Where better than hackers@ to look for support to liberate
  j...@freebsd from censors ?

c...@.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: x11 status

2009-02-25 Thread Mark Linimon
On Tue, Feb 24, 2009 at 10:24:29PM -0500, Chuck Robey wrote:
 Why is that?  Is XFree86 not getting any fixes?

We didn't have anyone that wanted to support it after we switched the
default to xorg.  (We actually need more people willing to support xorg,
as well).

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Fw: request responsibility timeout

2009-02-02 Thread Mark Linimon
On Mon, Feb 02, 2009 at 05:17:38PM +0100, Dominic Fandrey wrote:
 I want to request a responsibility timeout for bin/120784

(with bugmeister hat) AFAIK no one else other than rodrigc has been
doing work on the mount utilities, so I don't know who else to assign
it to.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: sun4v arch

2008-08-23 Thread Mark Linimon
On Sat, Aug 23, 2008 at 06:52:07PM -0700, Maxim Sobolev wrote:
 There is a better interpretation, which is that the only critical issue 
 is lack of real users for this port, not lack of serial port support :).

My understanding is the the port is in a pre-alpha state due to unfinished
work in the kernel, so expecting there to be any userbase is premature.

All of our 'new' architectures which are in this state have so few non-
developer users that there is hardly any reason to submit PRs.  AFAICT
the active developers already know what's missing :-)

Our implementation of GNATS barely serves us as a problem report system;
it fails almost completely as a system for listing missing features.  We
would need to have something like that to track the status of the non-
Tier-1 ports.  (I used to maintain a table of how feature-complete the
various ports are, but it is now way out of date.)

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD hacker 101

2008-01-25 Thread Mark Linimon
On Fri, Jan 25, 2008 at 01:58:51PM +0800, william wong wrote:
 That brings me to another ponder: why juniper and cisco are using
 FreeBSD and not Linux even Linux performs better in an UP environment?

Other posters have mentioned that there is a mix of Linux and BSD at
Cisco.  I don't work there, so I can't comment.

However, if you're shipping a product where you don't necessarily wish
to publish whatever code enhancements you've created, the BSD license
is most likely a better choice.

What was discussed at the last BSDCan was the fact that the companies
that use BSD-licensed components are evolving towards contributing back
improvements that they make to the system that they do not feel are
their differentiators, and keeping to themselves the intellectual
property that they feel puts them at a competitive advantage in their
market.

So it comes down to a legal and philosophical difference -- one that has
been argued incessantly in the BSD vs. GPL camps.  It can quickly become
a religious argument and one that can only be resolved by agreeing to
disagree -- if that.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Coverity problems?

2008-01-11 Thread Mark Linimon
On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote:
 These numbers seem strange and out of proportion. I know there has been 
 prior cooperation with Coverity - is this just old data?

IIRC Coverity is not tracking our use of their software, at least in
those statistics.  Someone was telling me yesterday that was because
we have our own copy of the Coverity server which we use, rather than
accessing the one on their site that generates the statistics.

Someone, please correct me if I'm wrong.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memset bugs.

2007-08-14 Thread Mark Linimon
On Tue, Aug 14, 2007 at 03:49:50PM -0400, Dave Jones wrote:
 I'm unfamiliar with how patch submission works in FreeBSD,
 but hopefully someone can eyeball this for correctness
 and get it committed, or forward it on to the right people.

The way to make sure your patch doesn't just get lost in the mailing list
noise is to send a Problem Report (PR).  There's no guarantee that it will
be handled promptly, however, as we have a large backlog (more people
willing to report bugs than to do some of the dirty work :-/  Many of
the developers are already stretched thin.)

The documentation is available at
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/.
If anything is unclear, you can email [EMAIL PROTECTED] and we'll
try to clarify things.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM

2007-06-18 Thread Mark Linimon
On Mon, Jun 18, 2007 at 02:35:59PM -0400, Mike Meyer wrote:
 While both FreeBSD and darwin ports (where I do development) have all
 the appropriate bits except oracle, the Linux distros don't have any
 of them in their packaging systems.

It might be nice to point that out to Oracle, as a way to try to sell
FreeBSD as a platform.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Looking for speed increases in make index

2007-05-27 Thread Mark Linimon
On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote:
 To gain some performance, a first idea would be to simplify
 bsd.ports.mk. I am convinced that a substantial part of the 4000 lines
 are historical crap which serve no useful purpose.

11272 of LOC in bsd.*.mk, but who's counting.

 There are tons of variables who have probably purely anecdotical
 interest. There are targets which could be happily suppressed.

Please let us know which functionality you think is extra.  You should
use the individual port Makefiles as well as ports/Makefile to figure
out what is unused.  For extra credit, please include
ports/Tools/portbuild/scripts so the build cluster will continue to work.

Please don't think I am picking on you specifically; however, about every
6 months or so someone decides that the ports framework is too complicated
without saying exactly what needs to be removed.  Since I look at all the
portmgr PRs as they come in, and participate in rejecting in some of the
(by our determination) more marginal features, I can assure you that not
every single new proposal makes it in there, nor has in the past.  Every-
thing that's in there is because there was some specific justification for
it (at least at the time).

Given that we had no install base, a significant rewrite would not be a
burden, but that's not the case.

Please note, I've agreed for several years that a great deal of the code
could be factored out into some kind of C library for speed and reduction
of code duplication.  Some work is going towards that in the Summer of Code.

But the hard part is making it work, in a backwards compatible fashion,
and doing the exhaustive regression testing to prove that it solves more
problems that it creates.  (portmgr spends a _lot_ of time on regression
testing, behind the scenes.)

In summary, the ports infrastructure is really complicated because it's
trying to deal with all kinds of constraints and conditions.  I challenge
anyone who thinks things can be removed to roll up their sleeves and make
a good case for it.  I'd be happy to have something easier to read.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD Status Report Third Quarter 2005

2005-11-22 Thread Mark Linimon
When I initially wrote the Ports Status report I included information
about a project that Edwin Groothuis created.  At that time I neglected
to get his approval for that text, and that was an oversight and a
mistake on my part and I apologize.  I did not intend for anyone to get
the impression that anyone other than himself should get the credit for
this project.

mcl
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: My project wish-list for the next 12 months

2004-12-02 Thread Mark Linimon
On Wed, 1 Dec 2004, Scott Long wrote:

 2.  New installer.  [... sysinstall] is fairly good at the simple
 task that it does [ ... ]

I'll put my bugmeister-hat on and simply say that query-pr suggests
otherwise.  I have not spent sufficient time examining each of the
PRs to figure out what the breakdown is between 'bugs within sysinstall'/
'unable to boot FreeBSD on hardware'/'user error' but IMHO the first
group contains more than a handful of PRs.  (the total # is 142.)

This is not to say we should abandon the KISS principle and try to
come up with some all-singing/all-dancing thing; in fact, the
opposite.  I'd rather we spent time on making something small and
solid which would contain enough of its own documentation to prevent
people from tearing their hair out while trying to use it.  Unlike
much of the rest of the system where we assume users have at least
some familiarity with FreeBSD (and a working browser), we have to
engineer an installer that assumes that both of those are false.

Unfortunately for me I probably will never be able to work on this
unless someone wants to pay me to work on FreeBSD full-time; too
many other things are ahead of it in my personal FreeBSD queue ...

mcl

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

2004-01-12 Thread Mark Linimon
 I forgot to mention on rather important factor in this equation:

Er, this is the *only* important factor.  IMHO, it made most of the
previous conversation be completely off-the-rails.

 If nothing happens, vinum is going to break even more very soon.

No ... if you do a commit that changes the code assumptions upon
which vinum was built, vinum will break.  vinum is not going to
magically break by itself.

This gets back to a problem with the FreeBSD development model:
people who commit changes that break things in other parts of the
system do not automatically get assigned the responsibility to fix
them.  Now, there's no way to impose something like that requirement
on a cooperative anarchy, so I am not playing the let's reorganize
card -- I think most of us would agree that that dog won't hunt as
we say down around these parts.

But, in the real world of software engineering, He Who Breaketh It,
Must Fixeth It.

Your mileage may vary.

mcl

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

2004-01-12 Thread Mark Linimon
 If vinum means a lot to you, you should do something to get it above
 that threshold:  start debugging/coding, learn to code if need be,
 donate money so somebody else can code if you can't do anything
 else.

I don't use vinum so I have no stake in this.

OTOH I'm not announcing changes which will affect it, either,
so the burden is not on me.

I have stated my opinion as well as I can, and will now go back
to working on things that I have a reasonable understanding
of and chance to fix.

mcl


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Where is FreeBSD going?

2004-01-07 Thread Mark Linimon
 The only thing any of the committers cares about is what they think.
 Got a problem? Submit a patch. Don't like the way things are done?
 Submit a patch. Don't like how such-and-such a util works? Submit a
 patch.

Please suggest an alternative, given that almost all the labor
is volunteer labor.

There are hundreds of PRs still to be processed that do have
patches -- in fact, on most days the backlog is getting bigger,
not smaller.  IMHO it's reasonable to prioritize concrete
suggestions over wish-list items.  What else should we be doing?

 Except, when Matt Dillon did submit, he was told to back out
 his changes

This had more to do with personalities than technology.  Other
people have had patches rejected, backouts requested, and in
some cases, backouts forced upon them.  Many of those people
are still with the project.  In a cooperative anarchy, things
are never going to be perfect; further, I think it's unfair
to generalize this one situation to saying this or that
contribution doesn't count.  This was the culminating incident
of a long-standing clash between strong personalities.  It's
too bad that it worked out the way it did, but I think other
than that it's not useful to make generalizations from this
one controversy.

 In short, you can put all the effort you want in, but -core
 and many with a commit bit will resent you for it, because
 you're just a user. 

What you may be interpreting as resentment may actually just
be frustration at being once again in the middle of being
told things are broken without concrete suggestions about
how it can be fixed.  Please come up with some kind of
definite proposal that you think would alleviate your, and
others', concerns; and post it and let us discuss it.  Keep
in mind that as you do so it's a volunteer project, and you
have to address the interests of the current volunteers too.
Perhaps you can suggest a way to bring more volunteers in
without losing any of the existing ones.  I certainly don't
have any answers to these kinds of questions; let me take
a look at yours.

mcl


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]