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. Definitely. 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 email? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgptyORmKaKb2.pgp
Description: PGP signature