On 10/15/2012 12:55 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <507c3aa4.6050...@wwwdotorg.org> you wrote:
>>
>> Irrespective of the documentation (which I obviously read the way I
>> describe anyway...), the kernel practice is that everyone who writes or
>> commits a patch add
Dear Tom Rini,
In message <507c4e37.8000...@ti.com> you wrote:
>
> I will not claim the kernel practice to be 100% consistent, but yes.
> git am --signoff, git pull/merge and no -s in merge commits seems to
> be the practice. Perhaps we should stop saying we follow the kernel
> process, link to i
Dear Stephen Warren,
In message <507c3aa4.6050...@wwwdotorg.org> you wrote:
>
> Irrespective of the documentation (which I obviously read the way I
> describe anyway...), the kernel practice is that everyone who writes or
> commits a patch adds their S-o-b line, and everyone who simply merges a
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/13/12 15:25, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <5079d95e.4070...@ti.com> you wrote:
>>
>> While also IANAL (and I try and stay out of these discussions),
>> paging around in the kernel log it sure seems like Linus and
>> akpm bot
On 10/13/2012 01:17 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <50770155.20...@wwwdotorg.org> you wrote:
>>
>> and in particular, the following parts of that doc is what tells me that
>> committers should always add S-o-b even if the commit didn't change:
>>
>>> Develop
Dear Tom,
In message <5079d95e.4070...@ti.com> you wrote:
>
> While also IANAL (and I try and stay out of these discussions), paging
> around in the kernel log it sure seems like Linus and akpm both add
> S-O-B when they git am something in (perhaps why there is git am
> --signoff?) but not when i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/13/12 12:30, Wolfgang Denk wrote:
[snip]
> Yes, I am aware it is also possible to interpret this as "anybody
> in the patch's delivery path" - but even then I cannot derive any
> obligation for such a passer-on to add his SoB.
While also IANAL
Dear Scott Wood,
In message <1349980244.6903.13@snotra> you wrote:
>
> > The number of people working on next should be small and manageable.
>
> More people likely use next than some custodian branches, and those are
> supposed to be rebase-free...
>
> Wouldn't anyone developing code for the
Dear Albert ARIBAUD,
In message <20121011203003.02f27b2d@lilith> you wrote:
>
> > > The Signed-off-by: tag indicates that the signer was involved in the
> > > development of the patch, or that he/she was in the patch's delivery path.
>
> My bad. I've indeed misread the Linux doc. However, the U-
Dear Scott Wood,
In message <1349979213.6903.11@snotra> you wrote:
>
> I've been signing off patches I apply to the NAND tree. I recall
> stopping at one point in the past because someone complained, and then
> starting again -- not sure if someone else complained about doing it
> *that* wa
Dear Stephen Warren,
In message <50770155.20...@wwwdotorg.org> you wrote:
>
> and in particular, the following parts of that doc is what tells me that
> committers should always add S-o-b even if the commit didn't change:
>
> > Developer's Certificate of Origin 1.1
> >
> > By mak
Dear Stephen Warren,
In message <5076fb24.1080...@wwwdotorg.org> you wrote:
>
> True, tags can be moved. However, the point wasn't that they're
> immutable, but that using them can decouple the pull process from the
> commit process. For example, I could:
>
> git checkout -b foo bar
> git am
> gi
Dear Scott Wood,
In message <1349974486.6903.5@snotra> you wrote:
>
> Is this documented anywhere?
>
> http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has
> adopted the Linux kernel signoff policy".
>
> Actual behavior is probably inconsistent between custodians.
This is docum
Dear Stephen Warren,
In message <5076f9bd.5050...@wwwdotorg.org> you wrote:
>
> However, U-Boot is reported to only use Signed-off to indicate the
> original author(s), so I can see how the git committer field isn't
Delete the "original" here. Once a patch has been commited to a tree,
it cannot
On 10/12/2012 05:11:17 AM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 13:59:31 -0500, Scott Wood
wrote:
> On 10/11/2012 01:45:02 PM, Albert ARIBAUD wrote:
> > Hi Scott,
> >
> > On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
> > wrote:
> >
> > > FWIW I think putting policy documents i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/12 22:29, Stefan Roese wrote:
> On 10/11/2012 08:30 PM, Scott Wood wrote:
>>> But, yes, it bears more thinking if we want the next branch
>>> open for longer than it has historically been, if we want
>>> that. And we have at least historicall
Hi Scott,
On Thu, 11 Oct 2012 13:59:31 -0500, Scott Wood
wrote:
> On 10/11/2012 01:45:02 PM, Albert ARIBAUD wrote:
> > Hi Scott,
> >
> > On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
> > wrote:
> >
> > > FWIW I think putting policy documents in a wiki, without any
> > > guidance on who's sup
On 10/11/2012 08:30 PM, Scott Wood wrote:
>> But, yes, it bears more thinking if we want the next branch open for
>> longer than it has historically been, if we want that. And we have at
>> least historically been saying that next can and will be rebased.
>
> IMHO it would be nice for the next br
On 10/11/2012 01:45:02 PM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
wrote:
> FWIW I think putting policy documents in a wiki, without any
> guidance on who's supposed to edit it or how changes get approved,
is a
> bad idea. Why not put policy documents
Hi Scott,
On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
wrote:
> FWIW I think putting policy documents in a wiki, without any
> guidance on who's supposed to edit it or how changes get approved, is a
> bad idea. Why not put policy documents in the git-managed source
> tree? And changes
On 10/11/2012 12:27:57 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/12 10:16, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
>>>
Hi Stephen,
On Thu, 11 Oct 2012 11:26:45 -0600, Stephen Warren
wrote:
> On 10/11/2012 11:16 AM, Albert ARIBAUD wrote:
> > Hi Scott,
> >
> > On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
> > wrote:
> >
> >> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > Re committer identity, I don'
On 10/11/2012 12:16:58 PM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
wrote:
> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > > > Re committer identity, I don't see the relationship with "by"
> > tags, and
> > > > especially with Singed-off-by, since t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/12 10:16, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
>>> wrote:
>> [snip]
The problem with reba
On 10/11/2012 11:16 AM, Albert ARIBAUD wrote:
> Hi Scott,
>
> On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
> wrote:
>
>> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> Re committer identity, I don't see the relationship with "by"
>>> tags, and
> especially with Singed-off-by, sin
On 10/11/2012 11:16 AM, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
...
>> In the case of post-v2012.10, it will be rebased as we want the commit
>> to change how
>> ARM and unaligned accesses are handled to be the firs
Hi Scott,
On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
wrote:
> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > > > Re committer identity, I don't see the relationship with "by"
> > tags, and
> > > > especially with Singed-off-by, since the sign-off is not and must
> > not
> > > > be
On 10/11/2012 11:38:00 AM, Tom Rini wrote:
On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
[snip]
> > The problem with rebasing when pulling is that git commit IDs
change,
> > so it's much more difficult to determine wh
On 10/11/2012 01:19 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <5075f48a.2080...@wwwdotorg.org> you wrote:
>>
>> I believe that's (part of) why Linux is tending towards pull requests of
>> a (signed) tag rather than a branch, since the tag always points at a
>> specific commit,
On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > Re committer identity, I don't see the relationship with "by"
tags, and
> > especially with Singed-off-by, since the sign-off is not and must
not
> > be related to the committer of the patch, but to its author(s).
>
> At least the way the L
On 10/11/2012 01:28 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <50759a75.8060...@wwwdotorg.org> you wrote:
>>
>> Do note that linux-next doesn't become the next Linux kernel version
>> either; it's just a preview of the merges Linus will do. Linus re-does
>> all the merges base
On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
[snip]
> > The problem with rebasing when pulling is that git commit IDs change,
> > so it's much more difficult to determine when a commit is merged into
> > a parent tree; o
Hi Scott,
On Wed, 10 Oct 2012 17:02:18 -0500, Scott Wood
wrote:
> Ideally once a pull request happens the pull happens quickly. If that
> doesn't happen, you could reply to the pull request asking that it be
> ignored in favor of a new pull request, or create a new temporary
> branch. IM
On Thu, Oct 11, 2012 at 09:19:22AM +0200, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <5075f48a.2080...@wwwdotorg.org> you wrote:
> >
> > I believe that's (part of) why Linux is tending towards pull requests of
> > a (signed) tag rather than a branch, since the tag always points at
Hi Stephen,
> >> It provides documentation in the git history of when merges were made,
> >> and what the source of the merge was (at least using the remote name
> >> that the merger has configured, which is better than nothing).
> >
> > This is what it provides, but this does not tell me why it
Dear Stephen Warren,
In message <50759a75.8060...@wwwdotorg.org> you wrote:
>
> Do note that linux-next doesn't become the next Linux kernel version
> either; it's just a preview of the merges Linus will do. Linus re-does
> all the merges based on the pull requests people actually send him. So,
>
Dear Stephen Warren,
In message <5075f48a.2080...@wwwdotorg.org> you wrote:
>
> I believe that's (part of) why Linux is tending towards pull requests of
> a (signed) tag rather than a branch, since the tag always points at a
> specific commit, and incremental pull requests can just create a new ta
Dear Stephen Warren,
In message <50759c8c.3030...@wwwdotorg.org> you wrote:
>
> The documentation of merge commits seems good to me just in an of itself.
Linus has commented a lot about this for Linux in the past. You may
want to dig this out from the archives.
In general, we should always fast-
On 10/09/2012 06:20 PM, Scott Wood wrote:
> On 10/09/2012 06:25:47 PM, Stephen Warren wrote:
>> On 10/09/2012 05:00 PM, Scott Wood wrote:
>> > On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
>> >> I don't quite follow that; linux-next is also purely merge-based. Are
>> >> you referring to the fact
On 10/10/2012 04:02 PM, Scott Wood wrote:
...
> Ideally once a pull request happens the pull happens quickly. If that
> doesn't happen, you could reply to the pull request asking that it be
> ignored in favor of a new pull request, or create a new temporary
> branch. IMHO pull requests ought to r
On 10/10/2012 12:15 AM, Albert ARIBAUD wrote:
> Hi Stephen,
>
> On Tue, 09 Oct 2012 17:04:06 -0600, Stephen Warren
> wrote:
>
>> On 10/09/2012 04:19 PM, Albert ARIBAUD wrote:
>
>>> Apart from this, I'm not sure why forbidding fast-forward is a good
>>> thing, but if there are benefits, why not.
On 10/10/2012 10:55:33 AM, Stephen Warren wrote:
On 10/09/2012 06:20 PM, Scott Wood wrote:
> I don't use gitk much, but wouldn't it just show the mergeback as
> another edge in the graph (plus the merge commit itself of
course)? It
> doesn't seem like a big deal.
One big problem is the abili
Hi Stephen,
On Tue, 09 Oct 2012 17:04:06 -0600, Stephen Warren
wrote:
> On 10/09/2012 04:19 PM, Albert ARIBAUD wrote:
> > Apart from this, I'm not sure why forbidding fast-forward is a good
> > thing, but if there are benefits, why not.
>
> It provides documentation in the git history of when
On 10/09/2012 06:25:47 PM, Stephen Warren wrote:
On 10/09/2012 05:00 PM, Scott Wood wrote:
> On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
>> I don't quite follow that; linux-next is also purely merge-based.
Are
>> you referring to the fact that it's re-created every day, and the
>> source
On 10/09/2012 05:00 PM, Scott Wood wrote:
> On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
>> >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200,
Hi Tom,
On Wed, Oct 10, 2012 at 9:59 AM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
>> >>> On Sun, O
On 10/09/2012 04:59 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
>>> wrote:
On 10/09/2012 08:23 AM, Tom Rini wrote:
> On Sun, Oct 07, 2012 at 08:
On 10/09/2012 04:19 PM, Albert ARIBAUD wrote:
> Hi Tom,
>
> On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini wrote:
>
>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>>> On 10/09/2012 08:23 AM, Tom Rini wrote:
On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>
Hi Albert,
On Wed, Oct 10, 2012 at 9:43 AM, Albert ARIBAUD
wrote:
> Hi Stephen,
>
> On Tue, 09 Oct 2012 16:14:23 -0600, Stephen Warren
> wrote:
>
>> This actually turns out to be less work for custodians if there aren't
>> any dependencies between patch series, since whenever you send a pull
>>
On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
On 10/09/2012 03:32 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> On 10/09/2012 08:23 AM, Tom Rini wrote:
>>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>>>
NOTE: I get a few more si
On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
> On 10/09/2012 03:32 PM, Tom Rini wrote:
> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
> >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> >>>
>
Hi Stephen,
On Tue, 09 Oct 2012 16:14:23 -0600, Stephen Warren
wrote:
> This actually turns out to be less work for custodians if there aren't
> any dependencies between patch series, since whenever you send a pull
> request right now, you do:
>
> a) Fetch latest upstream.
> b) Rebase onto it.
Hi Tom,
On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> > On 10/09/2012 08:23 AM, Tom Rini wrote:
> > > On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> > >
> > >> NOTE: I get a few more size issues with ELDK 4
On 10/09/2012 03:32 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> On 10/09/2012 08:23 AM, Tom Rini wrote:
>>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>>>
NOTE: I get a few more size issues with ELDK 4.2 on IXP
(that big-endi
On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> On 10/09/2012 08:23 AM, Tom Rini wrote:
> > On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> >
> >> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
> >> big-endian ARM) after this patchset is applied. I w
On 10/09/2012 08:23 AM, Tom Rini wrote:
> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>
>> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
>> big-endian ARM) after this patchset is applied. I wonder if we
>> shouldn't just throw these away, since they're dead code mo
56 matches
Mail list logo
