Fedora Board Recap 2007-JUL-31

[Manas Saksena]

Jesse Keating wrote:
> 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.

That would be helpful.

>  > 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.  

Fedora is a large project -- it is important that people march in the
same direction roughly. I think there is a gap between where some in the
Fedora leadership want to do and the thinking of a significant number of
maintainers.

> 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 will live with the compromise. I say compromise since the glibc stuff
will be 95% duplicate --- I dont see how that can be perceived to be
good. And, as for gcj -- I havent seen any need for it for what I see
as the user-base for me. So, I have no incentive to spend the time and
energy to get that fixed.

Hopefully, openjdk will come along and replace the need for gcj.

>  > 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.

Great.

>  > 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...

I dunno. I havent looked at it close enough yet. I like the goal, and
if we can leverage the shared code-base, then that would be wonderful.
It depends on how easy it will be to extend with new commands etc.

>  > 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.

Glad to see that we are on the same page. I dont know how much of the
rest of fedora community, maintainers, and leadership is on the same page.

For me, the attractions of Fedora are:

-- closely synchronized to upstream
-- secondary arch policy
-- opening up of infrastructure, processes, etc.
-- used by developers (especially in corporate settings)
-- separation of build and compose tools
-- a rich, well-maintained package repository
-- many developers active in upstream projects
-- regular 6m release schedule

The biggest problems that I see and get complaints from others are

-- server bias to serve RH's core business
-- desktop weakness compared to ubuntu

The above are both real and perceived. And, I think directly related
to Fedora's brand (cf the fedora brand discussion).

Regards,
Manas