4 ms·

I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simp

I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases? Thank you for clarifying cperciva!

cperciva 12y ago
even relatively simple changes were not MFC'ed until someone asked for it To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.
tw04 12y ago
Given the limited resources available, what are you expecting to occur? Why would they dedicate staff to back porting drivers that may literally never be used? If the person implementing the driver doesn't personally have a need to run it in an older version of the OS, they aren't going waste precious time back porting it just for the sake of back porting it.
- emaste 12y ago
  In the case of drivers, a lot depends on the specific hardware. Some drivers are written by employees of the hardware manufacturer, some are written by employees of companies using FreeBSD, and some are written by interested volunteers. Hardware vendors have an interest in supporting whichever FreeBSD versions are of interest to their customers, and often merge to all supported branches.

cperciva 12y ago

even relatively simple changes were not MFC'ed until someone asked for it To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up. Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.

tw04 12y ago

Given the limited resources available, what are you expecting to occur? Why would they dedicate staff to back porting drivers that may literally never be used? If the person implementing the driver doesn't personally have a need to run it in an older version of the OS, they aren't going waste precious time back porting it just for the sake of back porting it.

emaste 12y ago
In the case of drivers, a lot depends on the specific hardware. Some drivers are written by employees of the hardware manufacturer, some are written by employees of companies using FreeBSD, and some are written by interested volunteers. Hardware vendors have an interest in supporting whichever FreeBSD versions are of interest to their customers, and often merge to all supported branches.