Buildroot Archive on 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: Wed, 7 Jan 2009 12:50:05 +0100	[thread overview]
Message-ID: <200901071250.05379.markus.heidelberg@web.de> (raw)
In-Reply-To: <1231326832.32308.320.camel@elrond.atmel.com>

Ulf Samuelsson, 07.01.2009:
> ons 2009-01-07 klockan 04:09 +0100 skrev Markus Heidelberg:
> > CC-ing Hans-Christian Egtvedt
> > 
> > Peter Korsgaard, 06.01.2009:
> > > >>From talking with HcE on IRC, it seems like the Atmel fork of
> > > buildroot is the recommended solution for avr32 users anyway.
> > 
> > I wonder, why many of the patches are also included in uClibc's
> > Buildroot then. Don't the avr32 users use Atmel's Buildroot? I'm an
> > avr32 user myself and only use Atmel's Buildroot for development. One
> > drawback is that I'm not up-to-date with uClibc, because these changes
> > are only seldom merged into the Atmel branches, only short before their
> > release candidates. So I end up working on another file base, which
> > doesn't ease integration of changes into uClibc's Buildroot. I could
> > merge myself, a branch "upstream" is available and is updated often, but
> > that doesn't make sense somehow. I haven't yet tried it, so I don't know
> > whether it will cause some hassle or not.
> 
> I think it is desirable to have more people contributing
> with testing and patches.

Then what's the purpose of buildroot-avr32, when you seem to say
uclibc-buildroot should be used for AVR32 development? A personal
playground for HCE and cherry-picking for you into uclibc-buildroot?
Surely not. This repository is well-tested for all of Atmel's AVR32
boards for every release and even during the release candidates.

> > I haven't yet asked why this merge happens so rarely. Maybe lack of
> > time? OK, I'm already getting avr32-buildroot specific, but I think
> > updating the "devel" branch would be nice, even without testing
> > anything.  Currently the three branches "devel", "master" and
> > "atmel-2.3" are the same, pointing to the latest release.
> 
> Lack of time is the answer.
> The way it works is that HCE is doing the Atmel Branch
> and I am working on the main svn (even if HCE is providing
> patches from time to time).
> 
> >>From time to time I am taking HCEs additions
> from the Atmel branch and update the devel branch,
> but I did really not have time to do anything
> during most of the autumn.

What is the devel branch you mentioned? Above I refered to the devel
branch from HCE, I don't think you work on his devel branch, I haven't
seen a commit from you there. Do you mean uclibc-buildroot?

See my comment above. Why picking commits from HCE, making his
repository more valueless, because everything is also in
uclibc-buildroot and at the same time risk breaking it or prevent
updating packages (mplayer for example)?

Markus

  parent reply	other threads:[~2009-01-07 11: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
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 [this message]
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=200901071250.05379.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox