Hello Stephen, linux-next'ers,
I am looking for some guidance on policy/procedure governing inclusion
of a tree to linux-next. For instance: Do I have to be arbitrarily
invited (e.g. by some committee on LKML), or do I explicitly request
consideration? I tried to Google around for answers, and also found the
linux-next wiki, but I was not getting any clear answers.
I have these guest drivers to support IO on top of the AlacrityVM
hypervisor:
http://lkml.org/lkml/2009/8/3/278
The comments have since died down. I realize this can mean anything
from "no objection" to "no interest" ;), but I assume the former unless
someone pipes up.
I believe I addressed the review comments and received an Ack from the
one maintainer of the tree that overlaps with the work (netdev/davem), here:
http://lkml.org/lkml/2009/8/3/505
Since the rest of the work doesn't really fall into any existing
subsystem, and David conceded that the netdev overlap portion should
carry elsewhere, I offer to fill this role myself from within the
AlacrityVM tree itself.
As such, I have taken the driver series and created a new branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
linux-next
Unlike the original posting, I have excluded the final ethernet patch
since I posted a v3 today (http://lkml.org/lkml/2009/10/2/239) that I
would like to have David re-Ack before including.
Once the driver has been suitably approved by David, and if he still
feels its ok to carry in a tree other than netdev, I will re-add it to
the linux-next branch.
Because I am not really sure of the policies for linux-next, let me
state my intentions of this branch, since I am an unknown in the
maintainership role:
I will only post patches to this branch that:
*) do not fall into an existing maintained subsystem category, unless
the appropriate maintainer has relinquished the patch to carry in my tree.
*) have previously been posted to LKML for suitable review.
IOW: The purpose is not to sneak something in, or subvert a maintained
subsystem. It is purely to carry pieces that have no other home and are
maintained under the AlacrityVM project. You can find more details of
the project here:
http://developer.novell.com/wiki/index.php/AlacrityVM
If this is not acceptable, or I need to follow some other procedure,
please advise me on the proper steps. Perhaps I will update the wiki
FAQ on what I learn from your responses :)
Thank you, and Kind Regards,
-Greg
Hi Greg,
Sorry for the slow response.
On Fri, 02 Oct 2009 13:08:43 -0400 Gregory Haskins <[email protected]> wrote:
>
> I am looking for some guidance on policy/procedure governing inclusion
> of a tree to linux-next. For instance: Do I have to be arbitrarily
> invited (e.g. by some committee on LKML), or do I explicitly request
> consideration? I tried to Google around for answers, and also found the
> linux-next wiki, but I was not getting any clear answers.
You just send me the location of your tree and ask for inclusion. You
should also mention who should be contacted if I have any problems with
this tree (I will assume yourself).
> I have these guest drivers to support IO on top of the AlacrityVM
> hypervisor:
>
> http://lkml.org/lkml/2009/8/3/278
>
> The comments have since died down. I realize this can mean anything
> from "no objection" to "no interest" ;), but I assume the former unless
> someone pipes up.
>
> I believe I addressed the review comments and received an Ack from the
> one maintainer of the tree that overlaps with the work (netdev/davem), here:
>
> http://lkml.org/lkml/2009/8/3/505
>
> Since the rest of the work doesn't really fall into any existing
> subsystem, and David conceded that the netdev overlap portion should
> carry elsewhere, I offer to fill this role myself from within the
> AlacrityVM tree itself.
>
> As such, I have taken the driver series and created a new branch here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
> linux-next
I will add this tree from tomorrow unless someone screams.
> Unlike the original posting, I have excluded the final ethernet patch
> since I posted a v3 today (http://lkml.org/lkml/2009/10/2/239) that I
> would like to have David re-Ack before including.
>
> Once the driver has been suitably approved by David, and if he still
> feels its ok to carry in a tree other than netdev, I will re-add it to
> the linux-next branch.
That sounds fine.
> Because I am not really sure of the policies for linux-next, let me
> state my intentions of this branch, since I am an unknown in the
> maintainership role:
>
> I will only post patches to this branch that:
>
> *) do not fall into an existing maintained subsystem category, unless
> the appropriate maintainer has relinquished the patch to carry in my tree.
> *) have previously been posted to LKML for suitable review.
Here is my boilerplate:
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux 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.
--
Cheers,
Stephen Rothwell
[email protected]
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
On 10/06/2009 01:57 PM, Stephen Rothwell wrote:
> Here is my boilerplate:
>
> Thanks for adding your subsystem tree as a participant of linux-next. As
> you may know, this is not a judgment of your code. The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
Hi, could you please add git://decibel.fi.muni.cz/~xslaby/linux#limits
into the -next tree?
> You will need to ensure that the patches/commits in your tree/series have
> been:
> * submitted under GPL v2 (or later) and include the Contributor's
> Signed-off-by,
> * posted to the relevant mailing list,
I posted the patches twice, nobody seems to want to pick them up.
The last repost is at:
http://lkml.org/lkml/2009/10/17/126
> * reviewed by you (or another maintainer of your subsystem tree),
> * successfully unit tested, and
> * destined for the current or next Linux merge window.
I'll try to merge it to 2.6.33.
Thanks.
Hi Jiri,
On Fri, 23 Oct 2009 10:36:26 +0200 Jiri Slaby <[email protected]> wrote:
>
> Hi, could you please add git://decibel.fi.muni.cz/~xslaby/linux#limits
> into the -next tree?
I have added it from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux 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.
--
Cheers,
Stephen Rothwell
[email protected]
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
Hi Jiri,
On Mon, 26 Oct 2009 09:47:41 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Fri, 23 Oct 2009 10:36:26 +0200 Jiri Slaby <[email protected]> wrote:
> >
> > Hi, could you please add git://decibel.fi.muni.cz/~xslaby/linux#limits
> > into the -next tree?
>
> I have added it from today.
It is actually git://decibel.fi.muni.cz/~xslaby/linux#writable_limits, right?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On 10/25/2009 11:55 PM, Stephen Rothwell wrote:
> On Mon, 26 Oct 2009 09:47:41 +1100 Stephen Rothwell <[email protected]> wrote:
>>
>> On Fri, 23 Oct 2009 10:36:26 +0200 Jiri Slaby <[email protected]> wrote:
>>>
>>> Hi, could you please add git://decibel.fi.muni.cz/~xslaby/linux#limits
>>> into the -next tree?
>>
>> I have added it from today.
>
> It is actually git://decibel.fi.muni.cz/~xslaby/linux#writable_limits, right?
Hi. Oops, of course it is.
/me wondering: am I that dumb?
Hi,
BTW you may want to check if the current wording is correct:
Stephen Rothwell <[email protected]> writes:
> You will need to ensure that the patches/commits in your tree/series have
> been:
> * submitted under GPL v2 (or later) and include the Contributor's
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It's not ok to submit under e.g. GPL v3 only, I'd suggest "under GPL v2
and optionally other licence(s)" or something like that.
For example code under BSD-style licence (in addition to GPLv2) is
present in Linux, though I think any additional licence (the "later" as
in "GPL v2 or later", GPL v3, MS EULA etc.) is acceptable as long as it
is really additional, i.e., if one can ignore it and "use" GPLv2
exclusively.
IANAL of course.
--
Krzysztof Halasa
Hi Krzysztof,
On Mon, 26 Oct 2009 01:35:11 +0100 Krzysztof Halasa <[email protected]> wrote:
>
> BTW you may want to check if the current wording is correct:
>
> Stephen Rothwell <[email protected]> writes:
>
> > You will need to ensure that the patches/commits in your tree/series have
> > been:
> > * submitted under GPL v2 (or later) and include the Contributor's
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It's not ok to submit under e.g. GPL v3 only, I'd suggest "under GPL v2
> and optionally other licence(s)" or something like that.
Or maybe "under a license compatible with the Linux kernel source".
This was pointed out to me once before but I was hoping not to have to
disturb the IBM lawyers again. I guess I will run it past them and see
what happens.
> For example code under BSD-style licence (in addition to GPLv2) is
> present in Linux, though I think any additional licence (the "later" as
> in "GPL v2 or later", GPL v3, MS EULA etc.) is acceptable as long as it
> is really additional, i.e., if one can ignore it and "use" GPLv2
> exclusively.
>
> IANAL of course.
Me neither :-)
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Stephen Rothwell <[email protected]> writes:
>> It's not ok to submit under e.g. GPL v3 only, I'd suggest "under GPL v2
>> and optionally other licence(s)" or something like that.
>
> Or maybe "under a license compatible with the Linux kernel source".
Right, it looks better. Now I think the author doesn't even have to
licence under GPLv2, e.g. BSD alone will do as well.
--
Krzysztof Halasa