Date: Fri, 20 Jan 2012 17:32:26 +1000 From: Da Rock <freebsd-hackers@herveybayaustralia.com.au> To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <4F19188A.4090907@herveybayaustralia.com.au> In-Reply-To: <alpine.BSF.2.00.1201191511470.19710@kozubik.com> References: <20120119005658.218280@gmx.com> <alpine.BSF.2.00.1201191511470.19710@kozubik.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/20/12 09:13, John Kozubik wrote: > > > On Wed, 18 Jan 2012, Dieter BSD wrote: > >> John writes: >>> - EOL 7 >>> - mark 8 as legacy >>> - mark 9 as the _only_ production release >>> - release 10.0 in January 2017 >> >> Until a few days ago 8 was the latest, shinest release. >> So you want to suddenly demote it all the way down to legacy? >> I thought the goal was to have releases that can be used for a long >> time? > > > No, that's not quite what I meant. > > I was speaking at the same time about the problem of having two > concurrent "production" releases. > > Since 9.0 is already released, you can't stop having two production > releases with 8, since 9 is already here. > > So i was saying *after* you continue the normal 8.x lifecycle (perhaps > another 1 or 1.5 years, getting it to 8.5 *then* you make the drastic > changes, which I showed in the list above. > > So 8 would become legacy on the same schedule that it always had. No > changes there. The change comes with 9 being the only production > release, and 10.0-RELEASE being delayed. I'll weigh in :) I can sympathise with the need for longer support; but then on the other hand that means for things like fixes for drivers you have to wait 2 years or more- I've already done that, and I've been happier when things finally "just work" rather than having to root around and try to get things to work in any way I can. Case in point: I had a laptop with an iwn driver, there was no support for it, and it was going to wait for 8.0 (7.0 at the time). There was no option to backport as the driver wasn't working in current, so I tried to get involved and help but that quickly stagnated. So I was stuck to a cable (age had to be backported) and finally in 8 it worked, and wpa_supplicant was finally fixed as well. And when everything worked my laptop died and I bought another! :( Now I have ath. ath didn't work in 8. I tried a backport from current, and it worked for a bit and broke in 8.2. I was then forced to work with 9.0-RCx. Waiting longer would not have been an option- I was looking for a release date or some idea on where 9.0-RELEASE was at but the information was outdated and scarce. I was also hoping to get 802.11n support. Now apparently that is not really an option until 10. So what do I do? Some support is backported, but not all can be due to unresolvable API differences, same as what happened back with iwn. So based on this I face a continually moving target: my hardware lifetimes and the ability to keep up with new hardware produced by the dev team. I'd like to get involved, but drivers are still very much an enigma as yet. I also keep getting told to use current to help with testing, but given my userbase I can't do this without screams of agony, and vm's are useless here for hardware testing. I'm also advised to follow stable, but again- same deal. So I'm always asking myself "why is it so hard to run release?" I've read this entire thread now, but I still can't see a specific answer that resolves the issues presented. IF releases are supported longer, then backports are a must as near as I can see, but if the APIs are too different then how? If hardware or other feature support takes too long then users go elsewhere as well. I can't help being stubborn as mule, working with something no matter how hard it is, but I'm sure most users/sysadmins aren't. If a split was made between server and desktop edition that would be a disaster I believe. The only reason all this works so well is because there is no difference. The features required to make desktop more "user friendly" need to be added (probably by ports) as required, but that wouldn't kill server support. That only adds more labor to an already stressed environment. I will put my hand up to help with RE, or whatever will help in this situation; maybe even customised releases for rollouts for different organisations interested? I have cpu cycles to burn, and my missus is even egging me on :) I have enough systems to warrant this even for my own needs, and I'm sure I could pull it off with some help. My needs are more desktop than server though, and that should be helpful for the majority as support doesn't just stop at just what will provide for the sysadmins. I'll help in any way I can, if I get some support as well that would be handy. One thing that stands out to me I think is that svn (or similar) is a definite must and the cvs is too archaic for the needs here. The code freeze seems to be a real hindrance to a "healthy" release. Also, as to bugs, cannot some of the processes be automated (scripted?) somehow? Say if a patch is commited, can't this be detected and tested and a report sent to the stakeholders/interested parties? Depending on skill level required my missus could help on the poking side of things... On another point, Adrian: you mention that one can get involved, but that does seem to be an overwhelming task. I've tried to put up my hand a few times, but got lost in the clutter somehow. So how does one do it? I've put in a port to gnats, but that requires a committer to notice and actually commit so it seems to be a "who you know" thing. Although it seems that times are getting tougher now, and now one can get more noticed in the crowd...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F19188A.4090907>