On Sat, Jan 25, 2014 at 12:39:53PM +0100, Thorsten Leemhuis wrote: > Understood, but OTOH it makes me wonder if Fedora.next is a step to > big and needs to be split or something. Well, in practical implementation, it probably _will_ be done as incremental steps. For example, there's the possibility of decoupling the schedules of the base release from the products, but one of the few solid decisions we've already made is that that won't happen for F21. > point is needed obviously. But sometimes I miss a few introductions > words on the "why" we want all of that and how it's supposed to make > Fedora better. But that's obviously meta/abstract again, which I So, here's some things I see. * Fedora's drift towards being primarily a desktop OS (with other use areas considered secondarily if at all) ends up practically restricting uses which people really do want Fedora for. That's bad for people who want to use Fedora in innovative ways in server and cloud environments. Even though we have a lot of sysadmin users and there are many examples of real Fedora in production server environments, every time over the past decade that someone has tried to figure out what Fedora Server might actually mean, it's gotten stalled. This has left many sysadmins feeling like either Fedora isn't a place that they can meaningfully contribute, or else that their job is to be the Voice of No. Even when one doesn't want to just be the project's "stop energy", it sometimes felt like there was no other option. Fedora.next should *give* that option for postive contribution. * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist desktop is not ideal for an upstream for RHEL server and cloud products. That doesn't mean that there isn't room for one, but if we would focus Fedora on just that, we'd become increasingly irrelevant to our biggest downstream -- and to the project sponsor. (And make no mistake -- that concern of mine comes from a point of view of caring about Fedora first, not just my employer, because we benefit from taking part in that whole ecosystem cycle in ways beyond just Red Hat's direct employee and monetary contributions.) One particularly underserved area for Fedora is RHEL customers who would benefit from Fedora in some key areas (possibly even in production!), as well as those who are interested in experimenting with and possibily even shaping the future of the downstream. * General trend in Linux towards the base distribution being "boring" and not mattering. I asked several dozen different people at a gigantic Amazon conference why everyone was using the distribution they chose instead of Fedora, and the answer was almost universally "oh, I don't care; that's not really an interesting question because there's nothing important at that level". Now, that might not be really _true_, but it's definitely an increasing perception. How can we either fight that perception, or make sure that Fedora expands to also do work in the "interesting" space? * Difficulty building things on top of Fedora. This means both end-users with their own applications and bigger more complicated applications like OpenStack which it would be nice to have in the Fedora universe. There is value in the perfect-crystal-castle-of-all-packages approach, but if we build that in one place while everyone is going by on the highway, we're not really fulfilling our mission of leading free and open source software -- we're doing cleanup from behind and not making the impact we could be. I strongly believe that we can make room for this in the Fedora Project overall, even for things that are not appropriate in the Fedora *distribution* in its traditional sense. * As you mentioned in an earlier thread, it would be nice if we could make it easier to contribute minor changes, including big changes to more obscure packages. We can't just be Wikipedia and allow anonymous editing of packages (for one thing, we don't have an easy rollback mechanism and consequences could be much more severe), but maybe we can find a way of loosening things up for the fringes -- maybe even a really large fringe -- while keeping the core distribution under closer care. (Going way back to last summer's discussion, the problem with the former distinction between Core and Extras was that Core wasn't really open and the distinction was based on who you worked for; I'm quite certain we won't make that mistake again. Also, the standards for Extras were higher than those for Core, which was of course backwards and an example of community showing the way. But all that doesn't mean that we can't take the lessons and do it right.) * Wanting to eat our cake and have it too when it comes to balancing innovation and change management. In order to move fast while not breaking everybody all the time, it helps to break things up into larger logical segments than just packages. This helps draw out exactly what we really care about not breaking, what all might need to change together, and allows us be clear about what amount of breakage is an acceptable exchange. So that's some of my thoughts. More later -- gotta take the kids to the dentist now. :) -- Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
