[Buildroot] Buildroot maintainer and stable releases
jacmet at uclibc.org
Tue Jan 6 15:08:15 UTC 2009
>>>>> "Thomas" == Thomas Lundquist <lists at zelow.no> writes:
Thomas> On Mon, Jan 05, 2009 at 10:18:01PM +0100, Peter Korsgaard wrote:
>> I offer to do something about both: Take over maintainership and get
>> atual stable releases out the door (if Erik and the other developers
Thomas> The first question then is what kind of maintainer you mean.
Thomas> The One that makes releases or The One that maintains
Thomas> coherency and vetoes big changes?
Primarily the first, but also the 2nd where needed. I think we have
done relatively good so far without a maintainer, so I expect the 2nd
part to be fairly infrequent.
>> What is the plan? Getting the first release out is always the
>> hardest, so I would on purpose aim low for the first release and
>> get it out soon (February).
Thomas> That *is* quick.
It is, but why delay it any longer? People are using current svn
anyway, so we might as well make a release of it.
>> The target is to get all architectures to build (and
>> run where hw is available for test) using the default toolchain config
>> and busybox, anything else is just a bonus.
Thomas> Should we have some arch_testconfig as we have defconfigs?
Thomas> First start with a simple config then add more.
Maybe. I would just start with the rm .config; make menuconf, select
arch, save; make
>> I will put out the first
>> release candidate early next week, so from then on please don't add
>> anything else than bugfixes until the release it out. I believe in
>> time based releases, so any architectures that we cannot fix in time
>> will simply be disabled in kconfig (E.G. depend on BROKEN).
Thomas> BROKEN or ROTTEN or something that will alert future
>> The big issue with buildroot quality control is the mindblowing
>> number of configuration combinations and specialized hardware
>> needed to test.
Thomas> This has to be handles by a defined set of test cases based
Thomas> on more or less generic HW, like evaluation kits.
Thomas> And also devices actively maintained by someone wanting it to
Thomas> be a part of the test collection.
Thomas> The odd cases have to be taken care of by ordinary bug tickets.
Thomas> (BTW; WCHAR and LOCALE OFF is NOT a special case, it should
Thomas> be default. In my view, also LARGEFILE.)
You mean default on? They currently default to off, simply because of
their size impact.
>> I am therefore convinced we need to leverage qemu and
>> agressively deprecate legacy versions / packages + actively work with
>> upstream to keep the number of patches low.
Thomas> I am afraid we need more than one version of the kernel (Ulf
Thomas> wants is also) and I guess also of most of the toolchain but
Thomas> the packages/ is another story.
Maybe, but we can surely do better than todays' forest.
Thomas> If we do releases we should be able to cut down on the amount
Thomas> of versions in the toolchain aswell, since comppanies should
Thomas> freeze on a version if they plan to use it for years as Ulf
>> I think our users would
>> also be happier with a less ambitious project that wouldn't break left
>> and right, instead of the current situation.
Thomas> First thing I guess is to agree that we want this and
Thomas> then to make test criterias.
Thomas> After that, lay down which big changes we want and distribute
Thomas> maintainer responsibilities.
Bye, Peter Korsgaard
More information about the buildroot