Fedora Board Recap 2007-JUL-31

[Jesse Keating]

On Thu, 02 Aug 2007 19:15:04 -0700
Manas Saksena <msaksena at marvell.com> wrote:

> There are patches that we need to apply to packages that enables them
> to build on ARM. Most of these are trivial. And, they have been
> sitting in bugzilla for a while. See the ARM tracker bug for pointers
> to these.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245418
> 
> If we can get these patches applied, we can move onto building
> packages for ARM per the secondary arch proposal. This simplifies our
> life, as we then have to only worry about failures (after a package
> initially builds).

A few of us were discussing this lately.  We think we could pretty
reasonably get the cvs access side of the secondary arch stuff in place
relatively soon.  This would allow you to have commit access to apply
these changes yourself.

> 
> There are a couple that are more difficult. They are worthy of a more
> open discussion. For e.g., GCJ does not work on ARM today. We have a
> patch that disables that and goes on with life. When gcj on arm works
> on upstream, we can enable it again, and move on with life. Or, glibc
> upstream has a glibc-ports tarball that carries support for ARM, and
> some other architectures. We have a patch that adds the port tarball
> to glibc to build for ARM and it has been refused by the maintainer.
> 
> See:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246800
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246801
> 
> A slightly more friendly attitude their would be most welcome :-)

Yes, that is a problem and we should kindly speak to these maintainers
and express to them what we're trying to accomplish in Fedora.  It's
often easy for maintainers to not "notice" new initiatives in Fedora
and not be aware that we're trying for new things.  Although upon
closer look it seems like you have a reasonable path for the second
one, and the first one just needs some expectations set for how long
gcj would be disabled on arm.

> 
> > I
> > speak for myself but I know the feelings of many, and
> > we /absolutely/ wish to see derivatives made of Fedora.  More than
> > just "I cut up the packages this way!".  Actual changes.  Cases we
> > haven't thought of before, things we've been too afraid to try.
> > We're doing things to make this easier, like a new campaign to make
> > it even easier to swap out our Fedora branding for more generic
> > ones or your own.    
> 
> Good to know :-)
> 
> > What else
> > can we do to foster this desire to play with the bits and make your
> > own distribution?  
> 
> A few things come to mind as things evolve in the future...
> 
> 1. The VCS discussion should explicitly recognize this use-case. So,
>     it should be possible for someone to clone the fedora src repo,
> and create derivatives from there, while staying synced up to the
>     fedora repository.

Yes, that is one of our forefront goals.  Make it easier for derivative
development.

> 2. As the compose tools evolve, hopefully they will not carry too much
>     of an x86/PC class system bias. For e.g., revisor/wevisor are
> based on kickstart. I havent looked closely at it, but at first
> glance it seems to have too much of that bias. I dont know whether
> these are fixable or not. It would be useful, if using the same set
> of tools (with appropriate modifications) I can create, for e.g.,
> jffs2 file system images.

I have to ask how you think a kickstart file is bias?  We have an
external parser in pykickstart.  The choice of using kickstart files is
so that all things take that as an input.  livecd-tools, eventually
pungi, anaconda itself, etc...  If the same config syntax and parser is
used everywhere then we gain the value of code sharing and lower
complexity for people creating new configs.  I have to wonder though
how this would be a bias against arm...

> 
> 3. It is useful to have Fedora packages stay close to upstream. And,
> if there is a need to put a desktop or server bias to them (by
> modifying them significantly from upstream sources) then maybe these
> should be considered in the same way -- i.e., as derivative distros
> of a base Fedora distro.

That is one of the stated goals of Fedora itself, to stay as close to
upstream as possible.  And yes, to start out with it would be nice to
hand the desktop team the infrastructure needed for them to play with
system level changes across the board while trying to create the
Desktop derivative.  Eventually those changes may be able to make it
into upstream, or we can find creative ways to make them for Desktop
spins.

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070803/0edc0a99/attachment.bin