On Mon, 2008-10-13 at 17:42 -0300, Horst H. von Brand wrote: > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > On Sun, 2008-10-12 at 16:48 -0300, Horst H. von Brand wrote: > > > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > > On Fri, 2008-10-10 at 16:53 -0500, Arthur Pemberton wrote: > > > > > On Fri, Oct 10, 2008 at 4:35 PM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > > > > On Fri, 2008-10-10 at 12:38 -0700, Toshio Kuratomi wrote: > > > > > >> Dmitry Butskoy wrote: > > > > > >> > Itamar - IspBrasil wrote: > > > > > [snip] > > > > > >> The fact that they switched to CentOS is *good* for Fedora. > > > > > > I can not disagree more - To me, it's yet another evidence of Fedora > > > > > > being on the loose. > > > > > > > > > > You're going to have to expound on that. I do not see Centos in any > > > > > way as in competition with Fedora. > > > > > > > EPEL drains away resources from Fedora. > > > > > Centos is something everyone should be proud of. > > > > > Well, to me CentOS is as important as any other arbitrary Linux distro. > > > > I am glad they are around, but not more and not less. > > > > It is around becase RHEL is popular, and open source. > > > And non-free > > It /is/ free... you pay for support only. Wrong. RHEL is opensource, but it is not free. You can't get RHEL binaries anywhere. > > > - If it was free, the CentOS folks could start directly > > contribute to Fedora > > No... Why not? CentOS would go out of business, because RH binaries could be used instead => their resources would be freed. > > > > > >> CentOS's goals are better oriented to the needs of someone > > > > > >> that wants to deploy a system and run it for years. Fedora is > > > > > >> good for people who want to get the latest technologies from > > > > > >> upstream as soon as they're stable enough to integrate into a > > > > > >> running system. > > > > > > > Right. But why can't Fedora do better? > > Define "better"... "Good Fedora" is bleeding edge, not fully stabilized > software, experimental stuff that may pan out (or it might not, being > replaced by something else), changing APIs (literally and sysadmin-wise), > fast turnaround. Yes, this is what it is supposed to be. Unfortunately this doesn't apply. Current Fedora isn't much more than a single-user desktop-focused RH development/rawhide snapshot. > > > > > > I feel Fedora could do better. > > > > > > Sure. With more devs, servers, time, etc. > > > > > ... less bureaucracy, less committees/less chiefs/more Indians, > > > > different people, different strategies. > > > > Show how! > > > Ease reviews, bodhi, packagedb, koji, bugzilla, track, re-consider FTBS, > > work-flow, trademark policy. > > Definite proposals that can be discussed? > > What does "trademark policy" have to do with anything, BTW? A lot. > > E.g. right now, the tools being in use are a heterogenious mixture of > > separate tools, > > Unix... My point is: Lack of integration and them being over-loaded with features. > > are often broken, > > Fixing hands are presumably wellcome... Well, ... > > are far from easy to use > > Concrete proposals on what to change how? Many, many tiny details. In fact, there are tons of usability issues with all of them. One pretty obvious example: bugzilla. IMO, it has never been less usable than it is now. It isn't possible anymore to reopen bugs, automatic CC:-adding when commenting to BZs, many lists are hidden in dropdowns, tags have changes (assignee), FTBS activities have rendered bugzilla "unsearchable", flagged review stuff, etc. > > and aim at > > implementing a highly bureaucratic process/work-flow. > > Again, proposals, please? E.g.: Work-flow: branch fc11 early (discussed and shot down last week). > > > Telling everybody here how awful things are going isn't helping > > > an iota. Everything has its limits, and for every desirable quality (newest > > > shiny toys, support for the newest fad in hardware in software) there is a > > > cost (can't be supported in the long range, fast turnaround, set procedures > > > to handle a huge stream of new stuff) > > > > > > > > But baring a sudden increase > > > > > in those, I would much prefer to see Fedora focus on dev and testing, > > > > > let other distros pretty things up. > > > > > > > ACK. Unfortunately, Fedora is drifting away from this group towards > > > > single-user desktops (e.g. OLPC). > > > > > > Then work towards drifting the opposite direction... > > > One reason why I am agitating ... > > "Agitating" doesn't help much. Of cause it does. It help making people aware about problems. > > > Fedora (or any other large group of people) will move where the majority > > > wants to go... > > > Well, deployment of an OS to servers, will always be a "minority use > > case" and will always collide somewhere with mere desktop oriented > > developments. > > So? Examples: NetworkManager, PulseAudio, setroubleshoot, SELinux-policies, PackageKit, defaults ... > > > > > Why would they, after often suggesting that Fedora _not_ be used on > > > > > production servers, use Fedora on their production servers? > > > > > Depends on how they mean it: > > > > - if they are referring to "long term maintained/everlasting support" > > > > servers, they are right. > > > > "Servers" are "long-time maintained" by definition... > > > To me, "server" is a "use-case of an OS" and is not at all connected to > > running the same OS for many years. > > That is "testing an OS with server workload", something different entirely. Just because some piece of hardware is labeled "server" or caged into a rack, doesn't make it a "server". A server is a use-case of software, the hardware doesn't actually matter. > > Yes, no doubt, running the same OS on a larger number of machines for a > > longer time helps maintenance, but I do not see how this is connected to > > a particular machine serving as "clients" or "servers". > > > > Yes, no doubt, there are use-cases where "long-term API" stability is > > important, but this applies to client use-cases as well as to server > > use-cases. > > Those /are/ the "server" use cases you want so badly! NO! I am talking about file-, yp/ldap-, nfs-, print-, streaming-, audio (mpd etc.)-, video-, VCS (CVS, svn, git, etc.)-, http-, SQL (postgres, mysql, etc.)- servers and similar. > > Finally, yes, no doubt, Fedora is not the "shoe that fits all sizes" nor > > are CentOS or RHEL, but ... this doesn't mean that Fedora may not be > > applicable to server scenarios. > > > > > > - if they mean it as "Fedora is technically too unstable", > > > > > > Because there is no "long term maintenance"... > > > Again, I don't see how "lack of stability" and "no long term > > maintenance" are linked together at all, nor how server and client > > use-cases matter. > > Again: "stability" is /not/ "when run on 10 thousand machines only one > crashes a day", it is "runs for thousands of days before crashing", and > /that/ is as un-Fedora as it gets. Again: server is a use-case of SW. Like on desktops, I can live with rebooting once a week due to kernel updates and don't need 1000hrs of uptimes nor do I have 1000s of users nor machines. > > What matters in use-cases of short lived-distros such as Fedora is: > > Upgrades "must simply work" and (admin-) personnel must be able to > > handle them in a particular scenario. > > Sure. Test upgrading for a few months until everything is A-OK, No, rolling release, respun distros. > > Lack of stability, > > Design objective. No, mismanagement, lack of QA > > ... tools > > Huh? koji, bodhi, bugzilla, packagedb ... One detail: The amount of administration emails I am receiving from koji, bodhi, packagedb: Often, several 1000s per month. > > The lack of people to me is not a cause, it's a consequence of mistakes > > in Fedora's history. > > Is there /really/ a lack of people? Yes, all over the place. Examples: * reviews * Fedora infrastructure "wining" on "lack of people" * Fedora infrastructure "signing" issues. > Are any statistics of contributors (and > contributions) at hand? None that I am aware about. Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
