Hi, On Thu, Jul 7, 2011 at 7:45 PM, Adrian Chadd <adr...@freebsd.org> wrote: > (OT, yes, but I'd like to take a stab at explaining "why" these things > fall to the wayside..) > > On 7 July 2011 12:08, Arnaud Lacombe <lacom...@gmail.com> wrote: > >> What would be the point to even start looking at an issue? You guys >> (by "you", I mean "official" committers on public list) don't care > > When someone who has an active interest takes ownership of the problem. > >> about people providing patches, might it be for trivial, obvious, >> fixes. I'm not even talking about complex patches ... When you >> eventually ends up providing a patch, you ends up being slammed a door >> at by maintainers asserting their code is perfect, until logic and >> user complaints prove them wrong. >> >> That said, this comment is off-topic, but I will certainly re-state >> this next month when I'll be ping'ing trivial patches. > > The problem is that someone doesn't own the problem. > > If I commit someone's fix to the tree without really understanding > what's going on, I take ownership of that change and any > issues/breakages/changes that it creates. > > The people responsible for these areas are likely very busy with other > things. It's not that they don't want to help! It's much more likely > that they don't have the time. > > Trivial patches aren't always so trivial. You can change the behaviour > of something subtle which works great for you and not for others. This > is very likely what's going on with IO/CPU scheduling. It's a tricky > area. A simple fix isn't always as simple. > > So if there's a diagnosed problem, with reproducable test cases and > some patches which fix it, I suggest doing something like the > following: > > * create a webpage, even if it's a wiki somewhere (even > wiki.freebsd.org if you ask someone nicely) > * dump all the information you can in there. Having stuff in emails is > great - but it's only really helpful for tracking the 'flow' of a > discussion. Having a summarised analysis of all of that on a webpage > is much more helpful. > * Add the patches there. > * Encourage people who aren't in your immediate community to try them > too - to try and find if your changes mess up other configurations > somehow. > * Be persistent trying to get your changes in. If you've done the > background research, done some wide-spread testing and show you've not > caused any obvious regressions, you're much more likely to get your > changes in. > For the record, I would like to see enforced public review for _every_ patch *before* it is checked in, as a strong rule. gcc system is particularly interesting. But it is not likely to happen in FreeBSD where FreeBSD committers are clearly more free than other at checking-in un-publicly-reviewed stuff (especially _bad_ stuff).
This would of course apply even to long-time committers, no matter how it hurt their ego (which I definitively do not care about). - Arnaud > With all of that done, you can likely find a committer who will help > you get your fixes into the tree. > > Please just try not to interpret a lack of response as a lack of > interest. There's only so much time in the day and committers tend to > be a busy bunch, with day jobs that may in no way reflect their > FreeBSD interests. > > Finally, if people do enough of the above and begin to take ownership > of parts of the tree, you'll find someone will likely sponsor you for > a commit bit. > > HTH, > > > Adrian > _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"