Hi! On 09.09.2010 00:24, Máirín Duffy wrote: > Think for a minute or two. What do *you* think Fedora should focus on > for F15 and F16? How about F17? F18? F19...or... F20? What should F20 > look like, how should it be, who uses it.... at least, for us to have > succeeded towards achieving our mission as a project? > > Okay, hold that thought. I'm not that active in Fedora these days -- partly because Fedora seems to more and more develop into a direction I don't like much. The later is the reason why I'll bit and answer this; but I write it here and not on IRC, as I think it's a lot easier to lay out thoughts like those below in a mail. Here we go: * latest kernels and all the userland packages with drivers (gutenprint, hplip, xorg-drv-*, sane-backends, ...) should go out to users as testing update within a few days after they got released and out as regular update within roughly three or four weeks after they got released. That way users won't have to wait months to make newly released hardware work with Fedora, as those hardware will often require new and improved drivers that are part of new kernels, xdrivers, ... * cooperate even more closely with upstream: (1) try harder to not include patches which are not upstream yet, (2) make upstream better aware of the problems distributions face (see also next bullet point below), and (3) if upstream ships a new version then normally sent it out to users as testing update a few days after it got released and as regular update within something like three weeks. This scheme needs a bit of flexibility depending on how good and sane the upstream in question works. Something like "kde 4.0.0" of course should not have immediately replaced kde 3.x for each and everyone. Another example: firefox 4.0.0 might better be shipped as testing update only till firefox 4.0.1 comes out; especially software that is not supported upstream anymore (for small software with only a handful of developers that'll most often include "x - 1" and older releases) should be updated to the latest version to make sure upstream is interested in bug reports for our users * for packages that properly honour above upstream policy do only accept packaging bugs in Fedora; everything else should be moved or directly reported upstream. Then it can get solved there (with involvement of the Fedora maintainer ) and will make upstream aware of the problems distributions and their users face; that is better than package maintainers of dozens or hundreds of distribution trying to fix and work around the same bugs or limitation, as that results in lot of wasted work * Okay, yes, grated, there are users that don't want updates like the ones I outlined at the first two pullet points. Those IMHO are better of with CentOS/RHEL, but support for consumer hardware is those sometimes is not the best. So to not ignore those users we should maintain two "current" releases (in parallel to rawhide); one that is maintained in a more rolling release like scheme similar to rawhide; it should contains up2date software (like outlined in the first two bullet points), but normally *not* contain any (pre-)alpha or beta code (like rawhide does). Such a distribution of course would be a bit more moving and up2date then Fedora is these days. But that is something some people want afaics; for those that find such a scheme to dangerous maintain a second "current" release in a similar way to how OpenSuse and Ubuntu maintain their distribution today: Mostly bug fixes only. * have a official sanctioned 3rd party repo and work with it way more closely than Fedora does today, to make sure it can do things properly Fedora can't or doesn't want to do; that should even include things Fedora doesn't like, to make sure that repo can provide a distro that is based on a unmodified Fedora, but offers some of those things that people like on Ubuntu (easy installation of those crappy proprietary drivers for example) * have a official sanctioned and supported external side for docs targeting users, to make sure that side can mention things from the official sanctioned 3rd party repo without risking legal problems * sudo or something like similar with a compatible "sudo" command by default That's all that sprung to my mind right now. HTH Cu knurd P.S.: I'd really would have liked to write "integrate CentOS into the Fedora project and make it our LTS release" as a bulled point, but I'd guess then even more people would have thought "Thorsten finally went completely mad" after reading this mail ;-) _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
