Prev: AMD C1E aware idle support
Next: [ANNOUNCE] GIT 1.5.6
From: Jiri Kosina on 18 Jun 2008 19:30
On Wed, 18 Jun 2008, Benny Halevy wrote:

> Exposing the not-yet-ready-to-be-released code to linux-next will expose
> conflicts earlier, and hopefully in smaller, more manageable deltas.

I like the way linux-next works now, i.e. it should reflect what is going
into the next major kernel release. Nothing more, nothing less.

Also, when talking about entirely new drivers for hardware that hasn't
been supported by the kernel at all so far (this is the situation we are
talking about, right?), there shouldn't be a lot of conflicts to be dealt
with, right? Ideally, drivers should be pretty isolated standalone pieces
of code that don't have any business changing any code that has been
already there.

--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Kosina on 18 Jun 2008 19:50
On Wed, 18 Jun 2008, James Bottomley wrote:

> Arguably, I can do this by putting it into my upstream tree (which feeds
> into linux-next) the reason for not doing so is that Linus likes us to
> preserve history in there when we can.

This of course applies only for branches/trees for which there are
downstream git users.

If the only reason you merge the driver into your tree is to have it
propagated into linux-next, you could very well create a separate branch
for it, and pull this branch into the one linux-next pulls from you (I
guess you have a dedicated branch for linux-next which is safe to be
rebased by definition, right?).

> If I need to pull the driver for a reroll it really screws the git
> history

But not in any of the branches that have upstream git users.

--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benny Halevy on 19 Jun 2008 03:40
On Jun. 19, 2008, 2:20 +0300, Jiri Kosina <jkosina(a)suse.cz> wrote:
> On Wed, 18 Jun 2008, Benny Halevy wrote:
>
>> Exposing the not-yet-ready-to-be-released code to linux-next will expose
>> conflicts earlier, and hopefully in smaller, more manageable deltas.
>
> I like the way linux-next works now, i.e. it should reflect what is going
> into the next major kernel release. Nothing more, nothing less.
>
> Also, when talking about entirely new drivers for hardware that hasn't
> been supported by the kernel at all so far (this is the situation we are
> talking about, right?), there shouldn't be a lot of conflicts to be dealt
> with, right? Ideally, drivers should be pretty isolated standalone pieces
> of code that don't have any business changing any code that has been
> already there.
>

The showcase example I have in mind is our OSD initiator for which
we pushed all dependencies already upstream, so currently it has
no conflicts with the existing code. However, it is not ready
for the next release since it should be reviewed, documented,
and accepted by the sub-system maintainer first.

I would like it to be included in linux-next so to be alerted of any
arising conflict so I can fix it in "real time" rather than waiting
for the next release to come out. Initially I thought it'd be a good
candidate for linux-staging, but Greg doesn't quite agree with that
(http://lkml.org/lkml/2008/6/11/225) since it's destined for linux-scsi.
Hence, a -staging branch/tree based off of James' tree makes sense.

Benny

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 19 Jun 2008 05:20
James Bottomley wrote:
> On Thu, 2008-06-19 at 09:31 +1000, Benjamin Herrenschmidt wrote:
>> linux-next should, imho, exclusively be for things we are pretty much
>> commited to merge in the next release. ie, a staging place to fixup
>> things like build breakages, patch conflicts, etc...
>>
>> Or else, it will just be another -mm ....
>
> Well, as Greg said for his driver staging tree, I think we can elide
> this requirement for new drivers. The good thing about drivers is that
> there's nothing we're really doing to break anything: before the driver
> the hardware was just plane unusable with Linux after the driver well,
> we're hoping it might be ...

This requires that the staged driver does not contain build bugs on any
architecture.

Besides, the definition of what we published in -next so far was:

Everything in -next is *merge-ready* now (from a subsystem
maintainer's POV). The only reason that it is not merged yet
is that Linus doesn't have a merge window open right now.

And the goal of -next was to check for potential integration problems
that cannot be detected in a maintainer's tree.

So IMO the question is not whether to put stuff which is not ready to be
merged into -next. It shouldn't, IMO. The questions rather are:
- What are criteria for merge-readiness of drivers?
(When do we have to / are we able to address issues like CamelCase
names or use of obsolete APIs --- before or after merge?)
- How to publish drivers which are not yet merge-ready but should get
into the hands of testers?

IMO the answer to the latter question is still not -next, because the
testing that -next gets is (from what I understood) also with the
specific goal to detect potential integration problems. Remember, you
publish code in -next of which you can say: This is ready for mainline,
except that there is little experience yet WRT potential integration issues.
--
Stefan Richter
-=====-==--- -==- =--==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: AMD C1E aware idle support
Next: [ANNOUNCE] GIT 1.5.6