Help with creating a high-functionality, high-stability FSO/ASU based release
mwester at dls.net
Fri Jul 4 18:16:32 CEST 2008
Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
> | I'll volunteer to assist on kernel and the base image maintenance.
> | This is a community project, not an Openmoko (the company) project -- as
> | such I suggest that for the infrastructure we consider using the
> | development environment (and repository) that the OM git repository
> | originally derived from, and remains loosely in sync with. That would
> | be the OE (OpenEmbedded) stuff.
> Woohoo, fork city!
As Mickey noted in his earlier email on this topic, why fork OE? This
is not a fork, its continuing development of a project that originated
in OE, and was forked to a separate git repo later on.
As a matter of fact, OE isn't very good at creating forks. It assembles
distros from released software gathered from all points on the Internet,
and to cause it to make a significant deviation from a released bit of
software is rather painful.
Let me expound further on a few other potential misconceptions some
readers may have:
OE has a cadre of expert developers. The OM image is based on Angstrom
-- which is not only maintained by those OE developers, but is the
"reference" image within OE. So the net result is that by continuing
the development in OE, the project will minimize the amount of labor
expended just to keep the images building.
I'll underscore that point by noting that Fedora 9 was supported and
able to build full images in OE some time before the OM git repo caught up.
And to address any final concerns any readers may have, the objection
that OE uses monotone is addressed as well; OE will be switching to git
So fundamentally, OM (the repo) currently exists as a fork from OE to
facilitate the business goals and needs of OM (the company), and not for
the convenience of OM (the community). The conclusion is clear; OE is
the best choice for the community.
> Mike, I think you'd make a great choice as handling a community kernel.
Given our recent discussions, I'm not sure if you're being sarcastic,
but whatever. There will be no changes in the short term; the stock
kernel will continue to be the one marked "stable" in the OM git repo
(that's how OE works). For those interested, there will be experimental
kernels, just as there are now, with various changes and patches.
The OM kernel repo will continue to be the reference point for all GTA0x
kernels, for good or for bad -- no fork. As noted earlier, it's a pain
to create forks in OE, much easier to submit the patches to OM and get
them in the kernel that way.
> | I'll also suggest that we begin using a community development IRC
> | channel for those interested in development (of any sort), I propose
> | #openmoko-cdevel on freenode (since #openmoko-devel is already taken,
> | and is closed).
> That's nothing, they also have some core channel going on for "real
Non-Disclosure Agreements are nasty things. I've worked on a project
where the lawyers' interpretation would have prohibited discussions on
even a closed IRC channel.
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the openmoko-devel