[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crush 2.0 abandoned -- Review and Feedback from Neil's Post of August 7th

On Wed, 12 Aug 2009 17:32:21 +1000
Brendan Simon <Brendan@BrendanSimon.com> wrote:

> There seems to be a lot of work, and it's a very steep learning curve. 


Nobody should be under any illusions that Crush 2.0 needs a huge amount
of work and that the work itself *starts* at the top of that long and
steep learning curve.

> One has to be very Debian savvy before the extra knowledge and time
> required to be an emDebian developer/maintainer.
> I there anyway to partition this so that a smaller knowledge/experience
> base is required to contribute ??

There are some discrete problems that can be handled in isolation, yes,
but the main effort to actually make the results into a cohesive,
working, installable release candidate needs someone with an overview.
In particular, before changes are made to the build system you *must* be
familiar with a large number of package builds and build systems. It
takes a huge amount of time to rebuild everything to test a change to
the build system - someone needs that overview.

We are *NOT* in a position to dictate that packages change to suit our
build system - which is how a change like this would be implemented in
standard Debian (albeit after a lot of arguing/bike-shedding on
debian-devel). The build system for Crush must cope with all possible
build systems in Debian (including their bugs) without expecting changes
in those systems to accommodate what we'd like. Before Crush 1.0, I
filed bugs against debhelper and CDBS to ease cross-building support -
none have been fixed.

Task 14 in my list can be isolated - the packages affected should all
be listed in the Code Audit and the task only needs to be concerned
with those packages. (With the exception that Crush does not yet have
all the dependencies of new or updated packages and some of those may
not be easy to build - see task 19.)

Task 15 can also be isolated - cmake.

Tasks 6, 19, 20, 21 and 22 need to be done by one person or a group
with equal access to a test repository.

> I notice uClibc is a candidate, but I remember a post about embedded
> glibc which was/is a smaller lighter libc based on glibc sources.  Would
> this be a better candidate than uClibc ??  Should glibc, embedded-glibc
> and uclibc all be "supported" ??

No. I doubt there is time to do anything substantial with uClibc and
building stuff for uClibc means waiting until the majority of other
tasks are complete anyway (because not every package currently builds
cleanly against glibc).

The problem with isolating tasks is that people pick tasks that are
ahead of or rely upon changes needed within other tasks and then end up
having to do a lot of the work twice. uClibc was at the end of the list
because it is at the bottom of the pile of things that depend on other
things being fixed first. Don't even start thinking about that now.

If people want to proceed with the tasks, can the list be put on the
wiki somewhere so that we can give URL's instead of quoting the list in

Neil Williams

Attachment: pgptyORmKaKb2.pgp
Description: PGP signature

Reply to: