Latest for-4.14

Latest for-4.14

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"

On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> On 7/23/2017 9:04 AM, Leon Romanovsky wrote:

<snip>

> > BTW, when will you post for-4.14 branch so we will be able to base our
> > submission queue for the -next?
>
> Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
> fixes that went in this week.

Any news on the matter?

Thanks

>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Latest for-4.14

[Dennis Dalessandro]

On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"
> 
> On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
>> On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> 
> <snip>
> 
>>> BTW, when will you post for-4.14 branch so we will be able to base our
>>> submission queue for the -next?
>>
>> Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
>> fixes that went in this week.
> 
> Any news on the matter?
> 

Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch there.

-Denny

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest for-4.14

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro wrote:
> On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> > Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"
> >
> > On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> > > On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> >
> > <snip>
> >
> > > > BTW, when will you post for-4.14 branch so we will be able to base our
> > > > submission queue for the -next?
> > >
> > > Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
> > > fixes that went in this week.
> >
> > Any news on the matter?
> >
>
> Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch there.

Are you referring to this branch?
https://github.com/torvalds/linux/compare/master...dledford:k.o/for-next

It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.

Thanks

>
> -Denny
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Latest for-4.14

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1883 bytes --]

On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro wrote:
>> On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
>>> Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"
>>>
>>> On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
>>>> On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
>>>
>>> <snip>
>>>
>>>>> BTW, when will you post for-4.14 branch so we will be able to base our
>>>>> submission queue for the -next?
>>>>
>>>> Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
>>>> fixes that went in this week.
>>>
>>> Any news on the matter?
>>>
>>
>> Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch there.
> 
> Are you referring to this branch?
> https://github.com/torvalds/linux/compare/master...dledford:k.o/for-next
> 
> It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.

I created a for-next and then I've been making various other branches
through the week and sending them to github to be checked by 0day
testing.  Once they pass 0day, I merge them into the for-next and push
one more time to make sure the combination of everything merged together
passes 0day, and once I get confirmation that the build is good, I'll
push it to k.o where it will be considered unrebaseable, and so any
fixes after that may require incremental patches, reverts, etc.  The
slowdown this week has largely been the turnaround time on 0day testing.
 That's been taking in excess of 10 hours from a push to test results
:-/.  I pushed what I want to push to k.o this morning about 8am, not
sure when I'll get my 0day results back.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Latest for-4.14

[Doug Ledford]

On Thu, 2017-07-27 at 14:32 -0400, Doug Ledford wrote:
> On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> > On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro wrote:
> > > On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> > > > Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state
> > > > transition from reset to error"
> > > > 
> > > > On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> > > > > On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> > > > 
> > > > <snip>
> > > > 
> > > > > > BTW, when will you post for-4.14 branch so we will be able
> > > > > > to base our
> > > > > > submission queue for the -next?
> > > > > 
> > > > > Tomorrow.  I wanted to base it on 4.13-rc2 so it would get
> > > > > all of the
> > > > > fixes that went in this week.
> > > > 
> > > > Any news on the matter?
> > > > 
> > > 
> > > Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch
> > > there.
> > 
> > Are you referring to this branch?
> > https://github.com/torvalds/linux/compare/master...dledford:k.o/for
> > -next
> > 
> > It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.
> 
> I created a for-next and then I've been making various other branches
> through the week and sending them to github to be checked by 0day
> testing.  Once they pass 0day, I merge them into the for-next and
> push
> one more time to make sure the combination of everything merged
> together
> passes 0day, and once I get confirmation that the build is good, I'll
> push it to k.o where it will be considered unrebaseable, and so any
> fixes after that may require incremental patches, reverts, etc.  The
> slowdown this week has largely been the turnaround time on 0day
> testing.
>  That's been taking in excess of 10 hours from a push to test results
> :-/.  I pushed what I want to push to k.o this morning about 8am, not
> sure when I'll get my 0day results back.

The current for-next is pushed to k.o.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest for-4.14

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 1423 bytes --]

On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro wrote:
>> On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
>>> Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"
>>>
>>> On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
>>>> On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
>>>
>>> <snip>
>>>
>>>>> BTW, when will you post for-4.14 branch so we will be able to base our
>>>>> submission queue for the -next?
>>>>
>>>> Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
>>>> fixes that went in this week.
>>>
>>> Any news on the matter?
>>>
>>
>> Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch there.
> 
> Are you referring to this branch?
> https://github.com/torvalds/linux/compare/master...dledford:k.o/for-next
> 
> It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.

Oh, and I never said I would be *done* processing the for-next area all
in one go.  You said you wanted regular progress and updates, and the
branch I have represents that.  But regular progress does not mean take
everything all at once.  As I process more patchsets, more will be added.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Latest for-4.14

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On Thu, Jul 27, 2017 at 02:34:57PM -0400, Doug Ledford wrote:
> On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> > On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro wrote:
> >> On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> >>> Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state transition from reset to error"
> >>>
> >>> On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> >>>> On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> >>>
> >>> <snip>
> >>>
> >>>>> BTW, when will you post for-4.14 branch so we will be able to base our
> >>>>> submission queue for the -next?
> >>>>
> >>>> Tomorrow.  I wanted to base it on 4.13-rc2 so it would get all of the
> >>>> fixes that went in this week.
> >>>
> >>> Any news on the matter?
> >>>
> >>
> >> Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch there.
> >
> > Are you referring to this branch?
> > https://github.com/torvalds/linux/compare/master...dledford:k.o/for-next
> >
> > It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.
>
> Oh, and I never said I would be *done* processing the for-next area all
> in one go.  You said you wanted regular progress and updates, and the
> branch I have represents that.  But regular progress does not mean take
> everything all at once.  As I process more patchsets, more will be added.
>

Regular sharing of information is also part of regular progress.

As I said more than once, I'm fine with sequential work, I'm fine with
the fact that not all my code is accepted, I'm fine with scheduled
delays, but I'm not fine with silence.

Thanks

>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Latest for-4.14

[Doug Ledford]

On Fri, 2017-07-28 at 07:32 +0300, Leon Romanovsky wrote:
> On Thu, Jul 27, 2017 at 02:34:57PM -0400, Doug Ledford wrote:
> > On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> > > On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro
> > > wrote:
> > > > On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> > > > > Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state
> > > > > transition from reset to error"
> > > > > 
> > > > > On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> > > > > > On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> > > > > 
> > > > > <snip>
> > > > > 
> > > > > > > BTW, when will you post for-4.14 branch so we will be
> > > > > > > able to base our
> > > > > > > submission queue for the -next?
> > > > > > 
> > > > > > Tomorrow.  I wanted to base it on 4.13-rc2 so it would get
> > > > > > all of the
> > > > > > fixes that went in this week.
> > > > > 
> > > > > Any news on the matter?
> > > > > 
> > > > 
> > > > Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch
> > > > there.
> > > 
> > > Are you referring to this branch?
> > > https://github.com/torvalds/linux/compare/master...dledford:k.o/f
> > > or-next
> > > 
> > > It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.
> > 
> > Oh, and I never said I would be *done* processing the for-next area
> > all
> > in one go.  You said you wanted regular progress and updates, and
> > the
> > branch I have represents that.  But regular progress does not mean
> > take
> > everything all at once.  As I process more patchsets, more will be
> > added.
> > 
> 
> Regular sharing of information is also part of regular progress.

Yes it is.  And there is a specific order to when maintainers share
information: when the code lands at k.o (or wherever that maintainer's
official repo is located), the maintainer notifies the author that the
code has been accepted (except Linus, who tends to take pull requests
without response unless there is something wrong with it).  That's the
standard process.  I'm following it.  I didn't get my successful 0day
result on the merged up branch until this morning, at which point I
pushed my branch to k.o, so today is "email everyone and update
patchworks" day.  You had access to my github repo where you could have
clearly seen what I was working on, but I guess you were just too busy
tapping your finger and waiting on an email to check it.  That's your
problem, not mine.  I don't know of any maintainers that email people
about their code while it's still being processed and before it has
officially landed in their repo (unless there are review issues or
build failures that kick it back out), so I don't know why you would
expect different from me, but it's not gonna happen.

> As I said more than once, I'm fine with sequential work, I'm fine
> with
> the fact that not all my code is accepted, I'm fine with scheduled
> delays, but I'm not fine with silence.



-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Latest for-4.14

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]

On Fri, Jul 28, 2017 at 12:54:56PM -0400, Doug Ledford wrote:
> On Fri, 2017-07-28 at 07:32 +0300, Leon Romanovsky wrote:
> > On Thu, Jul 27, 2017 at 02:34:57PM -0400, Doug Ledford wrote:
> > > On 7/26/2017 9:03 AM, Leon Romanovsky wrote:
> > > > On Wed, Jul 26, 2017 at 08:24:44AM -0400, Dennis Dalessandro
> > > > wrote:
> > > > > On 7/26/2017 1:37 AM, Leon Romanovsky wrote:
> > > > > > Reply to: "Re: [PATCH for-next 7/9] IB/core: Allow QP state
> > > > > > transition from reset to error"
> > > > > >
> > > > > > On Sun, Jul 23, 2017 at 09:14:02AM -0400, Doug Ledford wrote:
> > > > > > > On 7/23/2017 9:04 AM, Leon Romanovsky wrote:
> > > > > >
> > > > > > <snip>
> > > > > >
> > > > > > > > BTW, when will you post for-4.14 branch so we will be
> > > > > > > > able to base our
> > > > > > > > submission queue for the -next?
> > > > > > >
> > > > > > > Tomorrow.  I wanted to base it on 4.13-rc2 so it would get
> > > > > > > all of the
> > > > > > > fixes that went in this week.
> > > > > >
> > > > > > Any news on the matter?
> > > > > >
> > > > >
> > > > > Check Doug's GitHub, I see a 4.13-rc2 based "for-next" branch
> > > > > there.
> > > >
> > > > Are you referring to this branch?
> > > > https://github.com/torvalds/linux/compare/master...dledford:k.o/f
> > > > or-next
> > > >
> > > > It doesn't have most of mlx5/mlx4/cavium/core/e.t.c features.
> > >
> > > Oh, and I never said I would be *done* processing the for-next area
> > > all
> > > in one go.  You said you wanted regular progress and updates, and
> > > the
> > > branch I have represents that.  But regular progress does not mean
> > > take
> > > everything all at once.  As I process more patchsets, more will be
> > > added.
> > >
> >
> > Regular sharing of information is also part of regular progress.
>
> Yes it is.  And there is a specific order to when maintainers share
> information: when the code lands at k.o (or wherever that maintainer's
> official repo is located), the maintainer notifies the author that the
> code has been accepted (except Linus, who tends to take pull requests
> without response unless there is something wrong with it).  That's the
> standard process.  I'm following it.  I didn't get my successful 0day
> result on the merged up branch until this morning, at which point I
> pushed my branch to k.o, so today is "email everyone and update
> patchworks" day.  You had access to my github repo where you could have
> clearly seen what I was working on, but I guess you were just too busy
> tapping your finger and waiting on an email to check it.  That's your
> problem, not mine.  I don't know of any maintainers that email people
> about their code while it's still being processed and before it has
> officially landed in their repo (unless there are review issues or
> build failures that kick it back out), so I don't know why you would
> expect different from me, but it's not gonna happen.

I didn't expect anything different from you. What I expected from you is
to take a look on one patchset, decide go/no go, add to your branch, push
to github and 0-build (it very good in queuing jobs), announce and so on
till all patches are tested and it can be forwarded to k.o.

Sorry, if I expected too much.

>
> > As I said more than once, I'm fine with sequential work, I'm fine
> > with
> > the fact that not all my code is accepted, I'm fine with scheduled
> > delays, but I'm not fine with silence.
>
>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG KeyID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Latest for-4.14

[Doug Ledford]

[-- Attachment #1.1: Type: text/plain, Size: 2008 bytes --]

On 7/28/2017 3:29 PM, Leon Romanovsky wrote:
> On Fri, Jul 28, 2017 at 12:54:56PM -0400, Doug Ledford wrote:
>> On Fri, 2017-07-28 at 07:32 +0300, Leon Romanovsky wrote:

>> officially landed in their repo (unless there are review issues or
>> build failures that kick it back out), so I don't know why you would
>> expect different from me, but it's not gonna happen.
> 
> I didn't expect anything different from you. What I expected from you is
> to take a look on one patchset, decide go/no go, add to your branch, push
> to github and 0-build (it very good in queuing jobs),

Right now 0day is taking 10-13hours to give me results.  If people are
queueing up test runs for every single patch (or small patch series),
then no wonder it's taking so long.  That's horribly inefficient.  There
is enough stuff for me to look at that I'm batching it up, applying
multiple series to a specific branch, and then doing the build testing
at the end for the whole group.  If I know I'm looking at 10 small patch
series in a given day, then I doubt you will ever get me to send them
all separately to 0day as that sort of behavior is likely precisely why
it's taking 10+ hours to get results right now.  If people *didn't* do
that, then the results might get in much sooner.

> announce and so on
> till all patches are tested and it can be forwarded to k.o.
> 
> Sorry, if I expected too much.
> 
>>
>>> As I said more than once, I'm fine with sequential work, I'm fine
>>> with
>>> the fact that not all my code is accepted, I'm fine with scheduled
>>> delays, but I'm not fine with silence.
>>
>>
>>
>> --
>> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>     GPG KeyID: B826A3330E572FDD
>>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>>


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

Re: Latest for-4.14

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Fri, Jul 28, 2017 at 03:42:52PM -0400, Doug Ledford wrote:
> On 7/28/2017 3:29 PM, Leon Romanovsky wrote:
> > On Fri, Jul 28, 2017 at 12:54:56PM -0400, Doug Ledford wrote:
> >> On Fri, 2017-07-28 at 07:32 +0300, Leon Romanovsky wrote:
>
> >> officially landed in their repo (unless there are review issues or
> >> build failures that kick it back out), so I don't know why you would
> >> expect different from me, but it's not gonna happen.
> >
> > I didn't expect anything different from you. What I expected from you is
> > to take a look on one patchset, decide go/no go, add to your branch, push
> > to github and 0-build (it very good in queuing jobs),
>
> Right now 0day is taking 10-13hours to give me results.  If people are
> queueing up test runs for every single patch (or small patch series),
> then no wonder it's taking so long.  That's horribly inefficient.  There
> is enough stuff for me to look at that I'm batching it up, applying
> multiple series to a specific branch, and then doing the build testing
> at the end for the whole group.  If I know I'm looking at 10 small patch
> series in a given day, then I doubt you will ever get me to send them
> all separately to 0day as that sort of behavior is likely precisely why
> it's taking 10+ hours to get results right now.  If people *didn't* do
> that, then the results might get in much sooner.

It now explains why you are getting results so late.

Doug,
The 0-day service runs their checks on every commit which doesn't exist
in its database (it checks by hash) and posts results for latest commit
without relation to success/failure. For intermediate commits, it posts
result on failure only.

So your batch posting is the reason why you are not getting results
immediately and it is not relevant for "efficiency". One of the goals
for the 0-day service is to support bisectable commits, by ensuring
compilation at least.

Thanks

>
> > announce and so on
> > till all patches are tested and it can be forwarded to k.o.
> >
> > Sorry, if I expected too much.
> >
> >>
> >>> As I said more than once, I'm fine with sequential work, I'm fine
> >>> with
> >>> the fact that not all my code is accepted, I'm fine with scheduled
> >>> delays, but I'm not fine with silence.
> >>
> >>
> >>
> >> --
> >> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>     GPG KeyID: B826A3330E572FDD
> >>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
> >>
>
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>     GPG Key ID: B826A3330E572FDD
>     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
>




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]