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, -stable. > > 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 down. -- 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