Target market?

Manas Saksena msaksena at marvell.com
Tue Jul 24 04:27:12 UTC 2007


seth vidal wrote:
> On Mon, 2007-07-23 at 23:34 -0400, Luis Villa wrote:
>  > Not necessarily antithetical. After all, anyone who uses the thing as
>  > a base for their distro is going to want the base to be solid and
>  > well-integrated. Taking that route probably would mean that desktop
>  > polish is a lower priority than polishing the tools for making
>  > derivatives, though.
> 
> yes. the big-meeting-of-people-related-to-repositories+distro-making
> that we had last week was more or less about this subject.
> 
> we have some great tools, now we need to tie them together.
> 
> Here's the gist of what we came up with
> 
> EVERY TOOL WE MAKE MUST TAKE AS INPUT:
> kickstart.cfg
> yum repos
> 
> EVERY TOOL WE MAKE MUST EVENTUALLY OUTPUT:
> - distro + cds
> - livecd
> - xen/kvm images

While all of this is great, I am hoping that Fedora developers will
see a value in making it easier for downstream developers to
customize Fedora in whatever way they deem fit.

The Fedora-ARM effort is based on that premise. The goal there is to
use it build arbitrary custom distributions for devices -- handhelds,
wireless access points, routers, NAS boxes, digital cameras, TVs,
set-top-boxes, and so on.

The demands from the Fedora developers are very simple:

-- Allow support for ARM in the Fedora base. The Fedora-ARM distro will
    thus be the "meta-distro" -- which is essentially the package repo
    that is in-sync with the primary architectures.

    The only thing that is needed is for maintainers to not sit on
    patches that make things work on ARM.

-- Allow for cloning of the sources, making local changes, and easily
    maintaining the local changes. Essentially migrate from CVS to a
    distributed SCM and set it up in a way that allows this to happen.
    (Yes, like rpath).

-- Allow tools like rpm, yum, mock, pilgrim, koji to evolve that can
    support the needs of the downstream developers. For e.g., if some
    one adds patches to support cross-compilation, there is no reason
    to reject them on the grounds that it is not needed for Fedora as
    such.

-- Create a first class package repository/distribution that is:

	-- closely synchronized with upstream
	-- makes for a pleasing developer desktop
	-- as a whole, a collection that works well together
	-- etc.

-- Allow the downstream developers to push patches up (when Fedora
    specific; e.g., spec file changes) if those changes are broadly
    useful to multiple downstream use-cases.

-- Make it easy to replace any Fedora trademarks in the derivative
    distros.

This is not asking much from Fedora -- much of this is already in
place.

And, if you can do this and serve the needs of the embedded devices,
you would have also enabled derivative distros that create any of
the other "polished" end-user distros -- whether it is a traditional
desktop, a server, an online desktop or whatever.

Regards,
Manas












More information about the fedora-advisory-board mailing list