[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.0906201415400.4083@localhost.localdomain>
Date: Sat, 20 Jun 2009 14:27:59 -0400 (EDT)
From: Len Brown <lenb@...nel.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
sfi-devel@...plefirmware.org
Subject: Re: linux-next: Tree for June 19
> On Sat, 20 Jun 2009 00:16:49 -0400 (EDT) Len Brown <lenb@...nel.org> wrote:
> >
> > Please add the Simple Firmware Interface "sfi-test" branch to linux-next:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-sfi-2.6.git sfi-test
>
> Is this 2.6.31 or 32 material?
yes:-)
Most that is in in sfi-test at this moment I hope to catch .31.
There will be much more in .32 -- mostly things that depend on
the first batch...
> > A description of the project is on the SFI home page: http://simplefirmware.org/
> >
> > Note: like ACPI's test branch, this branch will be occasionally re-based
> > as the patches in it evolve.
>
> That's fine.
>
> Should I put just you as the contact, or add the mailing list as well?
The mailing list is fine (on cc), and I'm on that.
It is redundant to send to both.
> What I tell everyone: all patches/commits in the tree/series must
> have been:
>
> posted to a relevant mailing list
> reviewed
> unit tested
> destined for the next merge window (or the current release)
>
> *before* they are included. The linux-next tree is for integration
> testing and to lower the impact of conflicts between subsystems in the
> next merge window.
>
> Basically, this should be just what you would send to Linus (or ask him
> to fetch). It is allowed to be rebased if you deem it necessary.
The patches are tested on the pre-release platform that
makes use of them. There have been several internal reviews
and re-writes, but since we just got permission to release the
patches last week, they've not been publically vetted yet.
The content is quite close to what I plan to propose for upstream,
but the format is not. I'll be re-factoring the series into
"clean history" and senting them to LKML on Sunday night.
I don't expect much comment on the generic part,
but will want x86 maintainers to buy into the
parts that touch their architecture.
thanks,
-Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists