All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Heidelberg <markus.heidelberg@web.de>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot maintainer and stable releases
Date: Thu, 8 Jan 2009 18:50:39 +0100	[thread overview]
Message-ID: <200901081850.39916.markus.heidelberg@web.de> (raw)
In-Reply-To: <d6cda7730901070601o1c98127cv2df22e32808718b0@mail.gmail.com>

Thiago A. Corr?a, 07.01.2009:
> On Wed, Jan 7, 2009 at 10:19 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Peter Korsgaard, 07.01.2009:
> >> Markus Heidelberg writes:
> >
> >> Right now things are kind of a mess as avr32 is lacking from most
> >> upstream projects, so there's lots of big patches involved. As things
> >> are now, I don't see missing avr32 as a showstopper for a first
> >> release.
> >
> > Absolutely agreed. Especially given that there is this well-supported
> > AVR32 fork (which isn't really a fork I think, it rather sits on top of
> > uclibc-buildroot).
> >
> 
> This is not really true. The Atmel fork have numerous issues, and I
> can't do much about them, that's exactly why I looked up to this
> project. I didn't even knew what buildroot was before being introduced
> to Atmel's fork.
> John and Amaur, certainly had their issues with Atmel's fork as well,
> since they decided to contribute AVR32 specific changes here at some
> point. That probably could be said about most AVR32 user around.

Given that there are numerous issues, can you at least show me a few of
them? I'm interested. Everybody is calling for stable releases, HCE
offers such for AVR32, but nobody is using them!?

> I guess HCE and others from Atmel will only point users to Atmel's
> fork because of the quality issues we have here, and lack of release.
> It really doesn't look good for the company to point it's customers
> here and it sudenly doesn't even build today.

Agreed.

> Having our quality issues and releases sorted out, it's likely that
> their branch might just go away.

I don't know, but I don't necessarily think so. 

> On Wed, Jan 7, 2009 at 9:28 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >  Ulf> That is why other systems like OpenEmbedded allow having more
> >  Ulf> than one version of a package.
> >  Ulf> A system that only allows a single version is really not useful.
> >
> > Sorry, I disagree. Most packages only have a single version and that
> > works fine. Almost everything under packages builds just fine on any
> [cut]
> 
> I agree with Peter. We should strive to keep single versions only.
> There are cases like DirectFB and perhaps other libs that it's not
> possible, because the lib changes it's API. But in general, having
> several versions of the same package will add clutter and will be a
> maintenance nightmare.
> Ulf, I see your point. But suggesting to have versions for every
> package is too much. Perhaps we could have multiple versions for one
> very important package or another but every one doesn't make sense.

The point is, when you have to be stable for delivered products, you
won't update any package without a reason, let alone u-boot or the
toolchain. During development you can update whenever you want to. So if
you really need some new versions, you can cherry-pick them from the
latest buildroot into your stable-branch. No need for multiple version
inside buildroot itself.

Markus

  reply	other threads:[~2009-01-08 17:50 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 [this message]
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
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=200901081850.39916.markus.heidelberg@web.de \
    --to=markus.heidelberg@web.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.