Jonathan Perkin <jperkin%joyent.com@localhost> writes: > * On 2015-11-06 at 15:52 GMT, Greg Troxel wrote: > >> I'd like to move Mac OS X 10.7 and 10.8 from SUPPORTED to DEPRECATED. >> It seems that still being on 10.9 is respectable, but I think older >> versions aren't getting security updates. >> >> (I just updated bootstrap/README.MacOSX, but avoided policy changes.) >> >> Objections/comments? > > Personally I don't see why we have this at all. We've always tried in > pkgsrc to support as many systems as possible, unless the support for > those systems is actively harmful and/or preventing reasonable > development from taking place. > > I'm not aware of any such situations at present, and I continue to > produce binaries for the DEPRECATED 10.6/i386 with no problems (in > some cases better than the SUPPORTED 10.9/x86_64). > I don't see why README.MacOSX is special compared to all the other OS > we support, and would prefer we just take things on a case-by-case > basis rather than writing hard and fast rules. The reason it exists is because there are or were PRs for older OS X systems, and they are in my view clutter. Proprietary systems tend to have users that are running older versions due to licensing reasons (IMHO that includes people on ppc). We would reject a bug report for NetBSD 4, presumably, because that's out of support, and there generally aren't good reasons to still be running it. > I would just delete that whole section, but as it seems primarily to > be about how PRs will handled my opinion should probably carry much > less weight than the folks who are actually handling them. I added it so that it would be socially comfortable to close PRs that are about older systems when the submitter doesn't update them to something more modern. So it's not about handling PRs as much as deleting cruft. Perhaps I can replace the entire section with a note about the oldest version that anyone appears willing to deal with, and that any PR < 10.6 may be asked to be updated to something more modern or closed. That would more narrowly meet the need in fewer bytes.
Attachment:
signature.asc
Description: PGP signature