From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] target/device/Atmel kernel patches
Date: Tue, 27 Jan 2009 10:25:26 +0100 [thread overview]
Message-ID: <87vds114op.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <1233008389.2298.129.camel@elrond.atmel.com> (Ulf Samuelsson's message of "Mon\, 26 Jan 2009 23\:19\:49 +0100")
>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
Hi.
Ulf> No, Just because you like to run with the latest kernel,
Ulf> that view is not shared by everyone else.
>>
>> Ok, so what patches can be removed? I take it that atleast *SOME* of
>> those 10 versions can go?
Ulf> I have customers still working on 2.6.22 ...
Working as in doing active development? Really?
Ulf> I think you need to understand that some people
Ulf> are planning for 10-15 year lifetime of products.
Ulf> They do not neccessarily update the kernel very often.
Ulf> If they do, they are likely to juyst add tweaks to
Ulf> their kernel instead of upgrading to a new version.
I work at a company developing display technology for the military
market, so you don't need to tell me about long term support ;)
But the problem is that you are mixing up configuration control of a
project, and development of buildroot. When you do a project you
ofcourse need to get your individual components under configuration
and be able to reproduce your build if you ever need to fix
something. This ALSO includes buildroot version.
Completely next to that is the state of buildroot svn. This has to be
suitable for starting new projects off, so it needs recent versions of
packages with the latest bugfixes included.
For starting a new project, selecting anything else than the 2.6.28
(or even better, the latest 2.6.29-rcX) seems pretty silly to me, but
I'm even stretching it to include 2.6.27 just in case.
So again, what kernel versions in arch-arm can we remove from svn?
Ulf> If you implement the patch downloading, there is
Ulf> very little reason to remove functionality.
Ofcourse there is, otherwise the number of configuration combinations
to test would grow astronomically.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2009-01-27 9:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-26 21:03 [Buildroot] target/device/Atmel kernel patches Peter Korsgaard
2009-01-26 21:29 ` Ulf Samuelsson
2009-01-26 21:37 ` Peter Korsgaard
2009-01-26 22:19 ` Ulf Samuelsson
2009-01-27 9:25 ` Peter Korsgaard [this message]
2009-01-29 14:33 ` Ulf Samuelsson
2009-01-29 14:57 ` Peter Korsgaard
2009-01-29 15:27 ` Ulf Samuelsson
2009-01-29 16:03 ` Peter Korsgaard
2009-01-29 16:28 ` Ulf Samuelsson
2009-01-29 16:54 ` Peter Korsgaard
2009-01-29 18:31 ` Ulf Samuelsson
2009-01-29 19:04 ` Peter Korsgaard
2009-01-29 22:04 ` 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=87vds114op.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