Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot maintainer and stable releases
Date: Wed, 07 Jan 2009 13:57:41 +0100	[thread overview]
Message-ID: <87d4ezl1dm.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <1231330238.32308.334.camel@elrond.atmel.com> (Ulf Samuelsson's message of "Wed\, 07 Jan 2009 13\:10\:38 +0100")

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> but I had to disable SAMBA and STRACE and change to uCLibc-0.9.30
 Ulf> since 0.9.29 does not compile for anything I tried.
 >> 
 >> Ok, why would you use 0.9.29 now 0.9.30 is out? Anyway, I'll do a
 >> 0.9.29 test compile in a moment.

Builds ok here on armv4l with gcc 4.24 / 2.6.28 headers (breaks with
4.3.x with the limits.h error). I'm not interested in fixing up 0.9.29
to work with current compilers, but feel free to do so.

 Ulf> I giess a new version of STRACE has probably been introduced
 Ulf> and this broke the socat.XXX.patch.avr32 patches.
 >> 
 >> socat or strace?

 Ulf> sorry - strace.

Ok, HcE will afaik check in the updated avr32 patch once he gets the
connection sorted out.

 Ulf> It is not fixed by a system which has stable distributions
 Ulf> which are removed and replaced with another stable
 Ulf> distribution which breaks support for a number of systems.
 Ulf> Then distributions might be stable, but the system as a whole
 Ulf> is totally unstable, and unacceptable for professional use.

Breaks support? That shouldn't happen if the release candidates gets
enough testing. 100% safety is not realistic, if you want that, just
don't upgrade to the new version.

 >> With main svn you mean this tree? Maybe it would make more sense to
 >> keep the Atmel stuff in your own fork?

 Ulf> That is not my own fork, it is Atmel Norways fork.

Yes, but Ulf == Atmel.no, right?

 >> I disagree. This is exactly what we SHOULDN'T do. We need to keep
 >> close to upstream and only provide the latest stable version (except
 >> for special situations) and work with upstream to fix problems if any.

 Ulf> Which will break architectures continously, so it will not allow
 Ulf> the use of Buildroot as more than a toy to introduce Linux
 Ulf> until people find something that really works.

Why? Seems to work pretty well elsewhere.

 >> Anything else is just too much work with too little improvements
 >> going upstream.

 Ulf> I do not disagree that we need to ensure that patches are fed
 Ulf> upstream, but the current way does not support working as a team
 Ulf> project.  It is a single user system.

This I don't get - What do you mean?

 Ulf> Since we have opposing views, then I think the rest of the 
 Ulf> people interested in maintaining buildroot, needs to 
 Ulf> also show their desires before any drastic actions in either
 Ulf> direction is taken.

Sure, feel free to speak up.

-- 
Bye, Peter Korsgaard

  parent reply	other threads:[~2009-01-07 12:57 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-05 21:18 [Buildroot] Buildroot maintainer and stable releases Peter Korsgaard
2009-01-06 12:02 ` Ulf Samuelsson
2009-01-06 12:39   ` Ulf Samuelsson
2009-01-06 12:55     ` Peter Korsgaard
2009-01-06 15:32       ` Ulf Samuelsson
2009-01-06 12:44   ` Peter Korsgaard
2009-01-07  3:09     ` Markus Heidelberg
2009-01-07  8:08       ` Peter Korsgaard
2009-01-07  8:27       ` Peter Korsgaard
2009-01-07  8:31         ` Nigel Kukard
2009-01-07 12:19         ` Markus Heidelberg
2009-01-07 13:02           ` Peter Korsgaard
2009-01-07 14:01           ` Thiago A. Corrêa
2009-01-08 17:50             ` Markus Heidelberg
2009-01-08 18:29               ` Ulf Samuelsson
2009-01-08 20:28                 ` Markus Heidelberg
2009-01-08 21:05                   ` Ulf Samuelsson
2009-01-08 22:06                     ` Markus Heidelberg
2009-01-08 22:33                       ` Ulf Samuelsson
2009-01-08 23:13                         ` Markus Heidelberg
2009-01-09  9:15                           ` Peter Korsgaard
2009-01-09  9:12                         ` Peter Korsgaard
2009-01-07 11:13       ` Ulf Samuelsson
2009-01-07 11:28         ` Peter Korsgaard
2009-01-07 12:10           ` Ulf Samuelsson
2009-01-07 12:24             ` Nigel Kukard
2009-01-07 12:57             ` Peter Korsgaard [this message]
2009-01-07 18:13             ` Thomas Lundquist
2009-01-07 19:16               ` Ulf Samuelsson
2009-01-07 19:39                 ` Peter Korsgaard
2009-01-08  8:25                 ` Thomas Lundquist
2009-01-08  9:10                   ` Peter Korsgaard
2009-01-07 11:50         ` Markus Heidelberg
2009-01-07 11:54           ` Peter Korsgaard
2009-01-07 12:55             ` Ulf Samuelsson
2009-01-06 14:01 ` Thomas Lundquist
2009-01-06 15:08   ` Peter Korsgaard
2009-01-06 18:32     ` Thomas Lundquist
2009-01-06 18:52       ` Peter Korsgaard
2009-01-06 19:09         ` Ulf Samuelsson
2009-01-06 19:23           ` Peter Korsgaard
2009-01-07 18:43           ` Thomas Lundquist
2009-01-07 19:26             ` Ulf Samuelsson
2009-01-07 20:22               ` Thomas Lundquist
2009-01-07 20:31                 ` Peter Korsgaard
2009-01-08  8:27                   ` Thomas Lundquist
2009-01-08  9:12                     ` Peter Korsgaard
2009-01-08 10:02                       ` Thomas Lundquist
2009-01-07 23:42                 ` Ulf Samuelsson
2009-01-08  9:00                   ` Peter Korsgaard
2009-01-06 14:52 ` Nigel Kukard
2009-01-06 15:01   ` Peter Korsgaard
2009-01-08 21:00   ` Markus Heidelberg
2009-01-06 18:22 ` Thiago A. Corrêa
2009-01-06 18:33   ` Peter Korsgaard
2009-01-06 18:53     ` Thiago A. Corrêa
2009-01-06 18:55     ` Ulf Samuelsson
2009-01-06 19:19       ` Peter Korsgaard
2009-01-06 19:02   ` Ulf Samuelsson
2009-01-06 19:16     ` Peter Korsgaard
2009-01-06 20:49       ` Ulf Samuelsson
2009-01-07 11:29         ` Peter Korsgaard
2009-01-07 12:34           ` Ulf Samuelsson
2009-01-07 13:15             ` Peter Korsgaard
2009-01-07 18:02             ` Thomas Lundquist
2009-01-07 19:13               ` Ulf Samuelsson
2009-01-07 19:36                 ` Peter Korsgaard
2009-01-07 20:36                   ` Joe George
2009-01-07 20:47                     ` Peter Korsgaard
2009-01-07 23:28                   ` Ulf Samuelsson
2009-01-08  8:07                 ` Thomas Lundquist
2009-01-08 19:22 ` Steve Calfee

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=87d4ezl1dm.fsf@macbook.be.48ers.dk \
    --to=jacmet@uclibc.org \
    --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