on 18/01/2012 01:36 Ian Lepore said the following: > On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote: >> on 17/01/2012 23:46 Ian Lepore said the following: >>> Now, before we're even really completely up and running on 8.2 at work, >>> 9.0 hits the street, and developers have moved on to working in the 10.0 >>> world. What are the chances that any of the patches I've submitted for >>> bugs we fixed in 8.x are ever going to get commited now that 8 is well >>> on its way to becoming ancient history in developers' minds? >> >> My opinion is that this will have more to do with your approach to pushing >> the >> patches (and your persistence) rather than with anything else. As long as >> stable/8 is still a supported branch or the bugs are reproducible in any of >> the >> supported branches. > > Well I submitted a sort of random sample of the patches we're > maintaining at work, 11 of them as formal PRs and 2 posted to the lists > here recently.
Just a note: the next best thing you can to _not_ have a patch committed is to just open a PR and stop at that. The best thing being not sharing the patch at all :-) > So far two have been committed (the most important one > and the most trivial one, oddly enough). I'm not sure just how pushy > one is supposed to be, I don't want to be a jerk. Some things that help: - send a problem description and a patch (or a short description and a link to a PR) to a relevant mailing list - maintain a discussion of the patch if it arises - try to be interesting and keep the interested folks hooked - find some folks who recently committed stuff in the area of the patch and contact them directly - don't just wait for too long, remind about yourself and the patch, try different mailing lists/people - never give up - stay technical, never get bitter or overly emotional - don't refuse when offered a commit bit :-) > Not to mention that I > wouldn't know who to push. That's actually why I'm now being active on > the mailing lists, I figured maybe patches will be more accepted from > someone the commiters know rather than just as code out of the blue > attached to a PR. That helps. And, as I've said above, being pro-active about the patches helps too. > I think it would be great if there were some developers (a team, maybe > something not quite that formal) who concentrated on maintenance of > older code for the user base who needs it. Yes, it would be great if some current developers found themselves interested/motivated to do that kind of work. Or if some new developers joined the ranks to do the job. > I'd be happy to contribute > to that effort, both on my own time, and I have a commitment from > management at work to allow me a certain amount of billable work hours > to interface with the FreeBSD community, especially in terms of getting > our work contributed back to the project (both to help the project, and > to help us upgrade more easily in the future). That sounds great! I am sure that this approach will be productive. > I have no idea if there are enough developers who'd be interested in > such a concept to make it work, co-op or otherwise. But I like the fact > that users and developers are talking about their various needs and > concerns without any degeneration into flame wars. It's cool that most > of the focus here is centered on how to make things better for everyone. -- Andriy Gapon _______________________________________________ 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"
