Alfred Perlstein wrote:
> >  > Uh Joe... WhereTF is your patch to do this?
> >  > My or your MTA seems to have deleted it.
> >
> > This is the atypical, smug, "I'm a committer and your're not" attitude
> > that permeates so much of the upper echelons of the FreeBSD team.  It
> > really makes me sick that people seem to prefer to throw out useless
> > comments like this instead of giving actual answers to valide questions.
> These comments are not useless, most committers have day jobs that
> unfortunetly preclude them from having time to work on every little
> feature request.  Furthermore asking for patches is the exact
> opposite of being smug at least in the way of flaunting one's commit
> priveledges, it's providing the user an opportunity to present work
> for inclusion into the project.

A lot of us are punch-drunk with the upcoming BSDCon next
week, too.

The flipness of the comments aside (don't hold people's
personalities against them, Joe), doing a patch would be
a way to handle this.  I offered to help with the structural
stuff, but not write the patch itself, since I'm not really
a great follower of -current, and patches not against current
are frequently ignored by committers because they don't
represent "the latest, greatest thing".  I still haven't
figured out how to hande the dichotomy of most volunteer
work occurring in -current, while most commercial work on
FreeBSD occurs in the last RELEASE, or, to a lesser extent,

> > I believe that Terry has already pointed out several of the places in
> > the Makefile system that prevent anyone from reinstalling gcc over the
> > top of the standard one.  His comments were helpful and succinct.
> > David's comments are unhelpful and terse.  Quite a difference in
> > attitude.  And you wonder why it is so hard to get new volunteers.
> We have plenty of volunteers willing to point out problems, what
> would be even more helpful is people _submitting the fixes_ to these
> problems.  Not like problem reporting isn't important, but you can't
> fault David not being willing to take the time to implement a feature
> he doesn't find all that important.  In fact you should be happy that
> he'd be willing to review and commit code when it does appear.

It's not a trivial problem to fix, either.  It's tangled
up in the "make release" process, which is two measures
of intent down the road from the question that Joe asked.

I volunteered structural help (which would probably be
mostly just explaqining the status quo, so that anyone
writing the code could avoid breakage), and David
volunteered to do reviews of the resulting patches, which
is tantamount to volunteering to commit them, so long as
they aren't incredibly offensive.

> > This is a discussion of general principles.  After settling the debate,
> > *then* it is appropriate to ask if anyone would like to work on the
> > issues.  Then, I may or may not try to generate patches.
> Personally I don't have time to engage in a debate, and I doubt
> that David does either.

I don't think Joe is debating; I think he wants to have a
meta-discussion about what the problem space looks like,
before submitting patches that light up his little corner,
and dark up everything else.

Every time these tools issues come up, it really boils
down to the GNU build process sucking pretty hard, not
being very seperable, and, in general, expecting to be
installed in isolation as an add on, rather than as an
integral part of a larger whole.

You really can't hold David responsible for that, it's a
vendor problem that doesn't look to be solved any time
soon.  USL is the same way: they have some incredibly
smart stuff, but interacting with them is like sharing a
prison cell with a 500 pound man named "Bubba", even if
you are their employee.  Maybe especially if you are
their employee... guards have to see "Bubba" every day
of their career, while short timers have the promise that
their "Bubba" days will soon be over.  8-).

It's also not obvious that the DESTDIR phenomenon exists
with compilers from ports, until you get going and it bites
you on the arse.  David is the compiler maintainer, so it's
second nature to him to turn around and smack problems as
they are preparing to bite.  8-).  The rest of us end up
with rather more tender backsides... 8-) 8-).

I don't think that this is going to be resolved right before
BSDCon, when everyone is feeling incredible time pressure,
and those who aren't are having the stress rubbed off onto
them by the others.  I also don't think that this is a
shallow problem that's subject to easy dismissal.  But if
it's a choice between "have some, everything works", and
"have all, some works", the "everything works" wins hands

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to