FreeBSD has serious problems with focus, longevity, and lifecycle

Andriy Gapon avg at
Wed Jan 18 00:00:38 UTC 2012

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

More information about the freebsd-hackers mailing list