Fedora Board Recap 2007-JUL-31
Manas Saksena
msaksena at marvell.com
Fri Aug 3 18:45:08 UTC 2007
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
More information about the fedora-advisory-board
mailing list