RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

Aleksandar Kurtakov akurtako at redhat.com
Tue Jul 23 16:51:49 UTC 2013


----- Original Message -----
> From: "Marcela Mašláňová" <mmaslano at redhat.com>
> To: devel at lists.fedoraproject.org
> Sent: Tuesday, July 23, 2013 7:45:46 PM
> Subject: Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock	talk)
> 
> On 07/23/2013 06:07 PM, Jiri Eischmann wrote:
> > Matthew Miller píše v Po 22. 07. 2013 v 09:38 -0400:
> >>    Conclusion
> >>    ---
> >>
> >>    * Refocus Core to provide a better platform for building on
> >>    * Make room for innovation at the "Ring 2" level
> >>    * Empower SIGs to create solutions that fit
> >>    * Won't break what we have
> >>    * And we can start right now
> >>
> >> So there we have it. Comments and discussion,  please!
> >
> > The proposal looks frankly very cloud-centric. I have no problem with
> > that. What else should a Fedora cloud architect propose? But I'd like to
> > know a few things:
> > Is the proposal based at least a bit on some kinda of analysis of our
> > more successful competitors in the cloud area? Yeah, I'm speaking about
> > Ubuntu which currently holds 50 percent of the market. Ubuntu has been
> > very successful in the cloud and in the proposal I really don't see a
> > lot of things that Ubuntu has/does better and Fedora doesn't have/does
> > worse.
> > I just want to make sure that we won't turn the whole Fedora upside down
> > to make us more successful in the cloud and then find out that something
> > completely different was making us unsuccessful and competitors
> > successful. IMHO closings gaps between the competitors and us and
> > staying excellent in our strong areas would probably be probably a safer
> > strategy than turning everything upside down.
> >
> > BTW speaking of Ubuntu, I think they've got quite different strategy -
> > one tightly integrated product across all uses (server, cloud, desktop,
> > and now maybe even tablets and phones). To solve the problem of newer
> > versions, special interests etc., they've got the ecosystem of PPAs.
> > That's where third-party entities can deliver software the way they
> > want. And AFAIK it has been widely popular with upstream projects
> > because they've got free hands with PPAs. And Ubuntu still has one
> > defined product and doesn't have to lower standards for software
> > inclusion.
> > IMHO it's a better solution than breaking the distribution into several
> > parts with different speed of development and different quality
> > standards from which you can build all kinds of fragmented products. At
> > least from the marketing point of view. As a user, I'd rather use a
> > well-defined distribution with one set of quality standards (and if I
> > wanted something special, I'd easily enable a third-party repo for that)
> > than a distro with well-defined core, but not so well-defined layers of
> > grey zone above it.
> >
> > Just my 2c,
> > Jiri
> >
> I'm not cloud person at all and I like the Rings proposal. Server can be
> still based on Ring0 and Ring1, so I don't see how it harm other use-cases.
> Same standards for all packages simply didn't work. It can be seen
> during every (mass, language) rebuild, which brings many problems for
> those running the rebuild. Different people tend to package things
> differently, even if there are guidelines. Lowering standards in some
> areas and creating packages automatically might give people time to work
> on their projects based above these packages. I guess the example with
> Hadoop and Jetty is a good one, which can be often seen.

I want to make it more than clear the jetty case is not a packaging question at all.
We speak about http server with it's vulnerabilities. 

Alexander Kurtakov
Red Hat Eclipse team

> I also believe we need something like PPA. If koji needs new features,
> or if new build system would be used, that's another part of the discussion.
> 
> Marcela
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list