From: Nigel Kukard <nkukard@lbsd.net>
To: buildroot@busybox.net
Subject: [Buildroot] avr32 patches vs. x86 breakage
Date: Fri, 21 Mar 2008 09:12:54 +0000 [thread overview]
Message-ID: <1206090774.2562.82.camel@nigel-x60> (raw)
In-Reply-To: <20080321085200.GB8894@mx.loc>
Hi Bernhard,
> >The real problem is that apparent quality issues of some of the arch
> >specific patches.
>
> They should fix their arch and you should not add kludge to work around
> such bugs, imo.
In an ideal situation yes .... but buildroot is an opensource project
with no time constraints imposed on its contributors.
If I contributed a patch to add an arch to GCC, and it broke 2 months
down the line when people began to use it, are you just going to remove
it out of buildroot until it gets fixed? What happens if it broke
support for everything except its own arch? What happens if there were
thousands of users of it, more than any other arch?
In this case its the AVR32 support which breaks x86 .... I'm sure there
are more users of AVR32 than x86. 1) its impractical to remove AVR32
support until its fixed, we don't know how long it will take 2) its
senseless to drop support for x86 because an AVR32 patch breaks it.
People new to buildroot trying it out don't want to scrape through years
of mailing lists to try find these few mails about everything building
fine on x86, then WHAM BAM .... corruption in the weirdest ways in the
generated images. It puts people off and they get the first impression
that buildroot doesn't work ... something I've seen happen ALOT!
Only alternative I can see is adding kludge to work around horribly
broken patches until someone fixes them or no one bitches and they are
removed like 6-12 months later. This way everything works out of the
box.
The proposed kludge isn't too bad either, its merely splitting the
patches up into different dirs. I am willing to spin a set of patches to
implement these changes.
-N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://busybox.net/lists/buildroot/attachments/20080321/4bc080ca/attachment.pgp
next prev parent reply other threads:[~2008-03-21 9:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 6:00 [Buildroot] avr32 patches vs. x86 breakage Nigel Kukard
2008-03-21 7:45 ` Peter Korsgaard
[not found] ` <1206086506.2562.64.camel@nigel-x60>
2008-03-21 8:18 ` Peter Korsgaard
2008-03-21 8:38 ` Nigel Kukard
2008-03-21 8:52 ` Bernhard Fischer
2008-03-21 9:12 ` Nigel Kukard [this message]
2008-03-21 9:30 ` Peter Korsgaard
2008-03-25 8:55 ` Ulf Samuelsson
[not found] ` <87hcf01m0r.fsf@macbook.be.48ers.dk>
2008-03-21 9:32 ` Peter Korsgaard
2008-03-21 11:36 ` John Voltz
2008-03-21 12:11 ` Bernhard Fischer
2008-03-21 12:47 ` John Voltz
2008-03-25 8:50 ` Ulf Samuelsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1206090774.2562.82.camel@nigel-x60 \
--to=nkukard@lbsd.net \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox