From: Paul Bolle <pebolle@tiscali.nl>
To: dwalker@fifo99.com
Cc: David Brown <davidb@codeaurora.org>,
Bryan Huntsman <bryanh@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm: msm: remove board file for Nexus One (ie. mahimahi)
Date: Mon, 19 May 2014 13:53:28 +0200 [thread overview]
Message-ID: <1400500408.2007.29.camel@x220> (raw)
In-Reply-To: <20140515215726.GA1171@fifo99.com>
Daniel,
On Thu, 2014-05-15 at 21:57 +0000, dwalker@fifo99.com wrote:
> On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> > This is not something I get to decide. Nevertheless, given that this
> > file shouldn't have been merged to begin with, I'd appreciate it if some
> > deadline could be agreed upon.
>
> I think I merged it actually, but there's no rules about what gets merged. How when what order, etc.
> It's all free form.
There do not seem to be formal rules. But there surely are some
requirements for code to be added. One of the requirements is, I think,
that it should build. This file cannot be built: it is not wired into a
Makefile and it also includes, what appears to be, its own header file,
but that header is not part of the tree.
Even the most dubious of code in drivers/staging is expected to "compile
properly"!
> > That being said, I'm not sure how having just this file in mainline
> > helps your development efforts. It seems it did receive some updates
> > for, well, treewide stuff. But it surely didn't get build coverage or
> > runtime testing. So would you lose much if it only remains in your
> > development tree?
>
> It's effort to remove it.. Your asking for it to get removed, then re-added.. That sounds
> like a fairly large amount of effort vs just leaving it in place.
Yes, it takes some effort to remove code. And it will also take effort
to re-add that code later. But I think that's a risk one runs with code
that has clearly never been buildable.
Paul Bolle
WARNING: multiple messages have this Message-ID (diff)
From: pebolle@tiscali.nl (Paul Bolle)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: msm: remove board file for Nexus One (ie. mahimahi)
Date: Mon, 19 May 2014 13:53:28 +0200 [thread overview]
Message-ID: <1400500408.2007.29.camel@x220> (raw)
In-Reply-To: <20140515215726.GA1171@fifo99.com>
Daniel,
On Thu, 2014-05-15 at 21:57 +0000, dwalker at fifo99.com wrote:
> On Thu, May 15, 2014 at 08:10:13PM +0200, Paul Bolle wrote:
> > This is not something I get to decide. Nevertheless, given that this
> > file shouldn't have been merged to begin with, I'd appreciate it if some
> > deadline could be agreed upon.
>
> I think I merged it actually, but there's no rules about what gets merged. How when what order, etc.
> It's all free form.
There do not seem to be formal rules. But there surely are some
requirements for code to be added. One of the requirements is, I think,
that it should build. This file cannot be built: it is not wired into a
Makefile and it also includes, what appears to be, its own header file,
but that header is not part of the tree.
Even the most dubious of code in drivers/staging is expected to "compile
properly"!
> > That being said, I'm not sure how having just this file in mainline
> > helps your development efforts. It seems it did receive some updates
> > for, well, treewide stuff. But it surely didn't get build coverage or
> > runtime testing. So would you lose much if it only remains in your
> > development tree?
>
> It's effort to remove it.. Your asking for it to get removed, then re-added.. That sounds
> like a fairly large amount of effort vs just leaving it in place.
Yes, it takes some effort to remove code. And it will also take effort
to re-add that code later. But I think that's a risk one runs with code
that has clearly never been buildable.
Paul Bolle
next prev parent reply other threads:[~2014-05-19 11:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 21:07 [PATCH] arm: msm: remove board file for Nexus One (ie. mahimahi) Paul Bolle
2014-05-14 21:07 ` Paul Bolle
2014-05-15 17:44 ` dwalker
2014-05-15 17:44 ` dwalker at fifo99.com
2014-05-15 18:10 ` Paul Bolle
2014-05-15 18:10 ` Paul Bolle
2014-05-15 21:57 ` dwalker
2014-05-15 21:57 ` dwalker at fifo99.com
2014-05-19 11:53 ` Paul Bolle [this message]
2014-05-19 11:53 ` Paul Bolle
2014-05-19 14:30 ` dwalker
2014-05-19 14:30 ` dwalker at fifo99.com
2014-05-20 6:43 ` Ivan T. Ivanov
2014-05-20 6:43 ` Ivan T. Ivanov
2014-05-29 18:29 ` Pavel Machek
2014-05-29 18:29 ` Pavel Machek
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=1400500408.2007.29.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=bryanh@codeaurora.org \
--cc=davidb@codeaurora.org \
--cc=dwalker@fifo99.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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.