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...
_______________________________________________
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"
