[U-Boot] Include patchwork patch ID in commit message?

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

Hi Tom,

I'm playing with the idea of including the patchwork patch ID in the
commit message of each commit that I apply to provide better
cross-reference ability.

* Access to comments on patches
* Clarity on exactly which version of a patch was applied
* No need to search by patch subject

Here is an example in a working branch:

http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a

What do you (or anyone else) think?

Thanks,
-Joe

[U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> I'm playing with the idea of including the patchwork patch ID in the
> commit message of each commit that I apply to provide better
> cross-reference ability.
> 
> * Access to comments on patches
> * Clarity on exactly which version of a patch was applied
> * No need to search by patch subject
> 
> Here is an example in a working branch:
> 
> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a

I'd prfer Patchwork or Patchwork-ID or something not just Patch.

> 
> What do you (or anyone else) think?

Well, I'm not a super fan of it.  For your second point, this is why I
use bundles, mutt and a macro.  For the other points, at least I find
google does a good job pulling up the right patch at least.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160127/e72d31c6/attachment.sig>

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> Hi Tom,
>>
>> I'm playing with the idea of including the patchwork patch ID in the
>> commit message of each commit that I apply to provide better
>> cross-reference ability.
>>
>> * Access to comments on patches
>> * Clarity on exactly which version of a patch was applied
>> * No need to search by patch subject
>>
>> Here is an example in a working branch:
>>
>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>
> I'd prfer Patchwork or Patchwork-ID or something not just Patch.

Would it be more or less compelling if it had a format similar this?

Patchwork: https://patchwork.ozlabs.org/patch/571773/

>
>>
>> What do you (or anyone else) think?
>
> Well, I'm not a super fan of it.  For your second point, this is why I
> use bundles, mutt and a macro.  For the other points, at least I find
> google does a good job pulling up the right patch at least.

Bundles seem awkward. Perhaps I'm just not using them effectively.
What benefit do they give you? How are they part of your workflow?

Thanks,
-Joe

[U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >> Hi Tom,
> >>
> >> I'm playing with the idea of including the patchwork patch ID in the
> >> commit message of each commit that I apply to provide better
> >> cross-reference ability.
> >>
> >> * Access to comments on patches
> >> * Clarity on exactly which version of a patch was applied
> >> * No need to search by patch subject
> >>
> >> Here is an example in a working branch:
> >>
> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >
> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> 
> Would it be more or less compelling if it had a format similar this?
> 
> Patchwork: https://patchwork.ozlabs.org/patch/571773/

Yes.

> >> What do you (or anyone else) think?
> >
> > Well, I'm not a super fan of it.  For your second point, this is why I
> > use bundles, mutt and a macro.  For the other points, at least I find
> > google does a good job pulling up the right patch at least.
> 
> Bundles seem awkward. Perhaps I'm just not using them effectively.
> What benefit do they give you? How are they part of your workflow?

OK, I'm going to delete this in a few days but here's my bundle for the
last import I did:
https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
My flow is:
1) Assign all unassigned patches
2) Open my todo list in patchwork
3) Create a bundle with all of the patches I want based on my critera at
the time.
4) Download bundle as mbox, git am -3 it, get big build going.
5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
at first
6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
each email group reply, run macro to insert applied message, postponed
7) Check output from big build, assuming good results, push and spam out
all of my queued messages.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160127/e6f428c4/attachment.sig>

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> >> Hi Tom,
>> >>
>> >> I'm playing with the idea of including the patchwork patch ID in the
>> >> commit message of each commit that I apply to provide better
>> >> cross-reference ability.
>> >>
>> >> * Access to comments on patches
>> >> * Clarity on exactly which version of a patch was applied
>> >> * No need to search by patch subject
>> >>
>> >> Here is an example in a working branch:
>> >>
>> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>> >
>> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>
>> Would it be more or less compelling if it had a format similar this?
>>
>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>
> Yes.

Are you being funny (more and less == not)? Or did you miss-read? :)

>> >> What do you (or anyone else) think?
>> >
>> > Well, I'm not a super fan of it.  For your second point, this is why I
>> > use bundles, mutt and a macro.  For the other points, at least I find
>> > google does a good job pulling up the right patch at least.
>>
>> Bundles seem awkward. Perhaps I'm just not using them effectively.
>> What benefit do they give you? How are they part of your workflow?
>
> OK, I'm going to delete this in a few days but here's my bundle for the

Doesn't that mean it will very soon not be traceable exactly which
patch version was applied? What I was proposing would mean that the
commit message could continue to refer back to the patch even if
archived.

> last import I did:
> https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> My flow is:
> 1) Assign all unassigned patches
> 2) Open my todo list in patchwork
> 3) Create a bundle with all of the patches I want based on my critera at
> the time.
> 4) Download bundle as mbox, git am -3 it, get big build going.
> 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> at first
> 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> each email group reply, run macro to insert applied message, postponed
> 7) Check output from big build, assuming good results, push and spam out
> all of my queued messages.

Gotcha. Thanks!

I'm trying to improve my workflow now, and this Patch tag was
something that came out of it. It's not required for the workflow, but
it is free to do within it. It has the potential to slightly simplify
one possible workflow, so no big deal.

If people think it will be simply noise, I'll leave it out.

I think this may speed up cross-referencing. Seemed like a good thing.

Cheers,
-Joe

[U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> >> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >> >> Hi Tom,
> >> >>
> >> >> I'm playing with the idea of including the patchwork patch ID in the
> >> >> commit message of each commit that I apply to provide better
> >> >> cross-reference ability.
> >> >>
> >> >> * Access to comments on patches
> >> >> * Clarity on exactly which version of a patch was applied
> >> >> * No need to search by patch subject
> >> >>
> >> >> Here is an example in a working branch:
> >> >>
> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >> >
> >> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> >>
> >> Would it be more or less compelling if it had a format similar this?
> >>
> >> Patchwork: https://patchwork.ozlabs.org/patch/571773/
> >
> > Yes.
> 
> Are you being funny (more and less == not)? Or did you miss-read? :)

Oops, yes, misread, yes, I like that.

> >> >> What do you (or anyone else) think?
> >> >
> >> > Well, I'm not a super fan of it.  For your second point, this is why I
> >> > use bundles, mutt and a macro.  For the other points, at least I find
> >> > google does a good job pulling up the right patch at least.
> >>
> >> Bundles seem awkward. Perhaps I'm just not using them effectively.
> >> What benefit do they give you? How are they part of your workflow?
> >
> > OK, I'm going to delete this in a few days but here's my bundle for the
> 
> Doesn't that mean it will very soon not be traceable exactly which
> patch version was applied? What I was proposing would mean that the
> commit message could continue to refer back to the patch even if
> archived.

It means the the link I gave for the bundle will be gone.  The patches
will be there, but I will also move them from Under Review to Accepted.

> > last import I did:
> > https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> > My flow is:
> > 1) Assign all unassigned patches
> > 2) Open my todo list in patchwork
> > 3) Create a bundle with all of the patches I want based on my critera at
> > the time.
> > 4) Download bundle as mbox, git am -3 it, get big build going.
> > 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> > at first
> > 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> > each email group reply, run macro to insert applied message, postponed
> > 7) Check output from big build, assuming good results, push and spam out
> > all of my queued messages.
> 
> Gotcha. Thanks!
> 
> I'm trying to improve my workflow now, and this Patch tag was
> something that came out of it. It's not required for the workflow, but
> it is free to do within it. It has the potential to slightly simplify
> one possible workflow, so no big deal.
> 
> If people think it will be simply noise, I'll leave it out.
> 
> I think this may speed up cross-referencing. Seemed like a good thing.

My concern is that since it's not injected by patchwork already I would
have to add it to each commit.  Today, unless I need to either make
something apply or do a minor fixup to the contents, I don't modify any
commit message, so my git am is it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160127/3c377601/attachment.sig>

[U-Boot] Include patchwork patch ID in commit message?

[Bin Meng]

On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
>> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
>> > On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>> >> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>> >> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> >> >> Hi Tom,
>> >> >>
>> >> >> I'm playing with the idea of including the patchwork patch ID in the
>> >> >> commit message of each commit that I apply to provide better
>> >> >> cross-reference ability.
>> >> >>
>> >> >> * Access to comments on patches
>> >> >> * Clarity on exactly which version of a patch was applied
>> >> >> * No need to search by patch subject
>> >> >>
>> >> >> Here is an example in a working branch:
>> >> >>
>> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>> >> >
>> >> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>> >>
>> >> Would it be more or less compelling if it had a format similar this?
>> >>
>> >> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>> >
>> > Yes.
>>
>> Are you being funny (more and less == not)? Or did you miss-read? :)
>
> Oops, yes, misread, yes, I like that.
>
>> >> >> What do you (or anyone else) think?
>> >> >
>> >> > Well, I'm not a super fan of it.  For your second point, this is why I
>> >> > use bundles, mutt and a macro.  For the other points, at least I find
>> >> > google does a good job pulling up the right patch at least.
>> >>
>> >> Bundles seem awkward. Perhaps I'm just not using them effectively.
>> >> What benefit do they give you? How are they part of your workflow?
>> >
>> > OK, I'm going to delete this in a few days but here's my bundle for the
>>
>> Doesn't that mean it will very soon not be traceable exactly which
>> patch version was applied? What I was proposing would mean that the
>> commit message could continue to refer back to the patch even if
>> archived.
>
> It means the the link I gave for the bundle will be gone.  The patches
> will be there, but I will also move them from Under Review to Accepted.
>
>> > last import I did:
>> > https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
>> > My flow is:
>> > 1) Assign all unassigned patches
>> > 2) Open my todo list in patchwork
>> > 3) Create a bundle with all of the patches I want based on my critera at
>> > the time.
>> > 4) Download bundle as mbox, git am -3 it, get big build going.
>> > 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
>> > at first
>> > 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
>> > each email group reply, run macro to insert applied message, postponed
>> > 7) Check output from big build, assuming good results, push and spam out
>> > all of my queued messages.
>>
>> Gotcha. Thanks!
>>
>> I'm trying to improve my workflow now, and this Patch tag was
>> something that came out of it. It's not required for the workflow, but
>> it is free to do within it. It has the potential to slightly simplify
>> one possible workflow, so no big deal.
>>
>> If people think it will be simply noise, I'll leave it out.
>>
>> I think this may speed up cross-referencing. Seemed like a good thing.
>
> My concern is that since it's not injected by patchwork already I would
> have to add it to each commit.  Today, unless I need to either make
> something apply or do a minor fixup to the contents, I don't modify any
> commit message, so my git am is it.

Does it make sense to enhance patchwork to inject such link into the
commit automatically? It can also be a project configuration option so
that other projects tracked by patchwork can turn it on on their
needs.

Regards,
Bin

[U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Bin,

Am 28.01.2016 um 02:49 schrieb Bin Meng:
> On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini <trini@konsulko.com> wrote:
>> On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
>>> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
>>>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>>>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> I'm playing with the idea of including the patchwork patch ID in the
>>>>>>> commit message of each commit that I apply to provide better
>>>>>>> cross-reference ability.
>>>>>>>
>>>>>>> * Access to comments on patches
>>>>>>> * Clarity on exactly which version of a patch was applied
>>>>>>> * No need to search by patch subject
>>>>>>>
>>>>>>> Here is an example in a working branch:
>>>>>>>
>>>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>>>>
>>>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>>>>
>>>>> Would it be more or less compelling if it had a format similar this?
>>>>>
>>>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>>>>
>>>> Yes.
>>>
>>> Are you being funny (more and less == not)? Or did you miss-read? :)
>>
>> Oops, yes, misread, yes, I like that.
>>
>>>>>>> What do you (or anyone else) think?
>>>>>>
>>>>>> Well, I'm not a super fan of it.  For your second point, this is why I
>>>>>> use bundles, mutt and a macro.  For the other points, at least I find
>>>>>> google does a good job pulling up the right patch at least.
>>>>>
>>>>> Bundles seem awkward. Perhaps I'm just not using them effectively.
>>>>> What benefit do they give you? How are they part of your workflow?
>>>>
>>>> OK, I'm going to delete this in a few days but here's my bundle for the
>>>
>>> Doesn't that mean it will very soon not be traceable exactly which
>>> patch version was applied? What I was proposing would mean that the
>>> commit message could continue to refer back to the patch even if
>>> archived.
>>
>> It means the the link I gave for the bundle will be gone.  The patches
>> will be there, but I will also move them from Under Review to Accepted.
>>
>>>> last import I did:
>>>> https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
>>>> My flow is:
>>>> 1) Assign all unassigned patches
>>>> 2) Open my todo list in patchwork
>>>> 3) Create a bundle with all of the patches I want based on my critera at
>>>> the time.
>>>> 4) Download bundle as mbox, git am -3 it, get big build going.
>>>> 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
>>>> at first
>>>> 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
>>>> each email group reply, run macro to insert applied message, postponed
>>>> 7) Check output from big build, assuming good results, push and spam out
>>>> all of my queued messages.
>>>
>>> Gotcha. Thanks!
>>>
>>> I'm trying to improve my workflow now, and this Patch tag was
>>> something that came out of it. It's not required for the workflow, but
>>> it is free to do within it. It has the potential to slightly simplify
>>> one possible workflow, so no big deal.
>>>
>>> If people think it will be simply noise, I'll leave it out.
>>>
>>> I think this may speed up cross-referencing. Seemed like a good thing.
>>
>> My concern is that since it's not injected by patchwork already I would
>> have to add it to each commit.  Today, unless I need to either make
>> something apply or do a minor fixup to the contents, I don't modify any
>> commit message, so my git am is it.
>
> Does it make sense to enhance patchwork to inject such link into the
> commit automatically? It can also be a project configuration option so
> that other projects tracked by patchwork can turn it on on their
> needs.

+1

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Thu, Jan 28, 2016 at 07:49:40AM +0100, Heiko Schocher wrote:
> Hello Bin,
> 
> Am 28.01.2016 um 02:49 schrieb Bin Meng:
> >On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini <trini@konsulko.com> wrote:
> >>On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
> >>>On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
> >>>>On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> >>>>>On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >>>>>>On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >>>>>>>Hi Tom,
> >>>>>>>
> >>>>>>>I'm playing with the idea of including the patchwork patch ID in the
> >>>>>>>commit message of each commit that I apply to provide better
> >>>>>>>cross-reference ability.
> >>>>>>>
> >>>>>>>* Access to comments on patches
> >>>>>>>* Clarity on exactly which version of a patch was applied
> >>>>>>>* No need to search by patch subject
> >>>>>>>
> >>>>>>>Here is an example in a working branch:
> >>>>>>>
> >>>>>>>http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >>>>>>
> >>>>>>I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> >>>>>
> >>>>>Would it be more or less compelling if it had a format similar this?
> >>>>>
> >>>>>Patchwork: https://patchwork.ozlabs.org/patch/571773/
> >>>>
> >>>>Yes.
> >>>
> >>>Are you being funny (more and less == not)? Or did you miss-read? :)
> >>
> >>Oops, yes, misread, yes, I like that.
> >>
> >>>>>>>What do you (or anyone else) think?
> >>>>>>
> >>>>>>Well, I'm not a super fan of it.  For your second point, this is why I
> >>>>>>use bundles, mutt and a macro.  For the other points, at least I find
> >>>>>>google does a good job pulling up the right patch at least.
> >>>>>
> >>>>>Bundles seem awkward. Perhaps I'm just not using them effectively.
> >>>>>What benefit do they give you? How are they part of your workflow?
> >>>>
> >>>>OK, I'm going to delete this in a few days but here's my bundle for the
> >>>
> >>>Doesn't that mean it will very soon not be traceable exactly which
> >>>patch version was applied? What I was proposing would mean that the
> >>>commit message could continue to refer back to the patch even if
> >>>archived.
> >>
> >>It means the the link I gave for the bundle will be gone.  The patches
> >>will be there, but I will also move them from Under Review to Accepted.
> >>
> >>>>last import I did:
> >>>>https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> >>>>My flow is:
> >>>>1) Assign all unassigned patches
> >>>>2) Open my todo list in patchwork
> >>>>3) Create a bundle with all of the patches I want based on my critera at
> >>>>the time.
> >>>>4) Download bundle as mbox, git am -3 it, get big build going.
> >>>>5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> >>>>at first
> >>>>6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> >>>>each email group reply, run macro to insert applied message, postponed
> >>>>7) Check output from big build, assuming good results, push and spam out
> >>>>all of my queued messages.
> >>>
> >>>Gotcha. Thanks!
> >>>
> >>>I'm trying to improve my workflow now, and this Patch tag was
> >>>something that came out of it. It's not required for the workflow, but
> >>>it is free to do within it. It has the potential to slightly simplify
> >>>one possible workflow, so no big deal.
> >>>
> >>>If people think it will be simply noise, I'll leave it out.
> >>>
> >>>I think this may speed up cross-referencing. Seemed like a good thing.
> >>
> >>My concern is that since it's not injected by patchwork already I would
> >>have to add it to each commit.  Today, unless I need to either make
> >>something apply or do a minor fixup to the contents, I don't modify any
> >>commit message, so my git am is it.
> >
> >Does it make sense to enhance patchwork to inject such link into the
> >commit automatically? It can also be a project configuration option so
> >that other projects tracked by patchwork can turn it on on their
> >needs.
> 
> +1

Well, code it up and send the patchwork list a patch and see how it goes
:)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160128/0b74770b/attachment.sig>

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Wed, Jan 27, 2016 at 7:49 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini <trini@konsulko.com> wrote:
>> On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
>>> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini <trini@konsulko.com> wrote:
>>> > On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>>> >> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>> >> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>> >> >> Hi Tom,
>>> >> >>
>>> >> >> I'm playing with the idea of including the patchwork patch ID in the
>>> >> >> commit message of each commit that I apply to provide better
>>> >> >> cross-reference ability.
>>> >> >>
>>> >> >> * Access to comments on patches
>>> >> >> * Clarity on exactly which version of a patch was applied
>>> >> >> * No need to search by patch subject
>>> >> >>
>>> >> >> Here is an example in a working branch:
>>> >> >>
>>> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>> >> >
>>> >> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>> >>
>>> >> Would it be more or less compelling if it had a format similar this?
>>> >>
>>> >> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>>> >
>>> > Yes.
>>>
>>> Are you being funny (more and less == not)? Or did you miss-read? :)
>>
>> Oops, yes, misread, yes, I like that.
>>
>>> >> >> What do you (or anyone else) think?
>>> >> >
>>> >> > Well, I'm not a super fan of it.  For your second point, this is why I
>>> >> > use bundles, mutt and a macro.  For the other points, at least I find
>>> >> > google does a good job pulling up the right patch at least.
>>> >>
>>> >> Bundles seem awkward. Perhaps I'm just not using them effectively.
>>> >> What benefit do they give you? How are they part of your workflow?
>>> >
>>> > OK, I'm going to delete this in a few days but here's my bundle for the
>>>
>>> Doesn't that mean it will very soon not be traceable exactly which
>>> patch version was applied? What I was proposing would mean that the
>>> commit message could continue to refer back to the patch even if
>>> archived.
>>
>> It means the the link I gave for the bundle will be gone.  The patches
>> will be there, but I will also move them from Under Review to Accepted.
>>
>>> > last import I did:
>>> > https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
>>> > My flow is:
>>> > 1) Assign all unassigned patches
>>> > 2) Open my todo list in patchwork
>>> > 3) Create a bundle with all of the patches I want based on my critera at
>>> > the time.
>>> > 4) Download bundle as mbox, git am -3 it, get big build going.
>>> > 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
>>> > at first
>>> > 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
>>> > each email group reply, run macro to insert applied message, postponed
>>> > 7) Check output from big build, assuming good results, push and spam out
>>> > all of my queued messages.
>>>
>>> Gotcha. Thanks!
>>>
>>> I'm trying to improve my workflow now, and this Patch tag was
>>> something that came out of it. It's not required for the workflow, but
>>> it is free to do within it. It has the potential to slightly simplify
>>> one possible workflow, so no big deal.
>>>
>>> If people think it will be simply noise, I'll leave it out.
>>>
>>> I think this may speed up cross-referencing. Seemed like a good thing.
>>
>> My concern is that since it's not injected by patchwork already I would
>> have to add it to each commit.  Today, unless I need to either make
>> something apply or do a minor fixup to the contents, I don't modify any
>> commit message, so my git am is it.
>
> Does it make sense to enhance patchwork to inject such link into the
> commit automatically? It can also be a project configuration option so
> that other projects tracked by patchwork can turn it on on their
> needs.

That would certainly make it a more unified implementation. The way
I'm doing it is simply with an automatic git commit --amend after the
git am in my script that downloads and applies mbox files from
patchwork.

-Joe

[U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Tom,

Am 28.01.2016 um 00:45 schrieb Tom Rini:
> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>>> Hi Tom,
>>>>
>>>> I'm playing with the idea of including the patchwork patch ID in the
>>>> commit message of each commit that I apply to provide better
>>>> cross-reference ability.
>>>>
>>>> * Access to comments on patches
>>>> * Clarity on exactly which version of a patch was applied
>>>> * No need to search by patch subject
>>>>
>>>> Here is an example in a working branch:
>>>>
>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>
>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>
>> Would it be more or less compelling if it had a format similar this?
>>
>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>
> Yes.

Sorry, for dummy question ... what should I see in the above link?

>
>>>> What do you (or anyone else) think?
>>>
>>> Well, I'm not a super fan of it.  For your second point, this is why I
>>> use bundles, mutt and a macro.  For the other points, at least I find
>>> google does a good job pulling up the right patch at least.
>>
>> Bundles seem awkward. Perhaps I'm just not using them effectively.
>> What benefit do they give you? How are they part of your workflow?
>
> OK, I'm going to delete this in a few days but here's my bundle for the
> last import I did:
> https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> My flow is:
> 1) Assign all unassigned patches
> 2) Open my todo list in patchwork
> 3) Create a bundle with all of the patches I want based on my critera at
> the time.
> 4) Download bundle as mbox, git am -3 it, get big build going.
> 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> at first
> 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> each email group reply, run macro to insert applied message, postponed
> 7) Check output from big build, assuming good results, push and spam out
> all of my queued messages.

Out of topic .... maybe tbot can help you here a lot. I have an automated
build for example for the smartweb board [1], which does:

+      - clone u-boot.git
+      - set toolchain
+      - get a list of patchwork patches from my U-Boots ToDo list
+      - download all of them, and check them with checkpatch
+        and apply them to u-boot.git
+      - compile U-Boot for the smartweb board
+      - install the resulting images on the smartweb board
+      - boot U-boot
+      - test DFU
+      - more TC should be added here for testing U-Boot

added to this list in the meantime some ported DUTS tests now,
last build see:
http://xeidos.ddns.net/buildbot/builders/smartweb_dfu/builds/48/steps/shell/logs/tbotlog
(currently I have 3 boards doing such tests periodically)

So, if you have a well-kept ToDo list in patchwork, this testcase
does a lot automatically (incl. execute testcases on board(s)) ...
You have only to look in the morning on for example a webpage
if all tests are "green" [2] ...

Then you can be sure, all patches in your ToDo list are checkpatch
clena, apply without errors to current master, compile clean and do not
break the boards you test u-boot ... (at last the testcases you run on
it).

Ok, I did not tried it with bundles, but it should also be possible to
download all patches you have in a bundle ... simple add a testcase
for downloading patches in a bundle only ...

Also an idea could be, to send an automated EMail if checkpatch
drops warnings/errors or if "git am" fails" ... but I do not really
know, if this would be a good idea ...

Also with the idea of tbot, you do not really need the hw at the place
where tbot runs ... for my example I run tbot on a raspberry pi in
Letkes/hungary, the boards are in munich/germany. So it is possible,
to test on boards, which other people have somewhere and give you
access to them ...

bye,
Heiko
[1] http://lists.denx.de/pipermail/u-boot/2016-January/243248.html
search there for:
"automated Testsetup with buildbot and tbot doing cyclic tests"

[2] http://xeidos.ddns.net/buildbot/tgrid
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

Hi Heiko,

On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher <hs@denx.de> wrote:
> Hello Tom,
>
> Am 28.01.2016 um 00:45 schrieb Tom Rini:
>>
>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>>>
>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>>>
>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>>>>
>>>>> Hi Tom,
>>>>>
>>>>> I'm playing with the idea of including the patchwork patch ID in the
>>>>> commit message of each commit that I apply to provide better
>>>>> cross-reference ability.
>>>>>
>>>>> * Access to comments on patches
>>>>> * Clarity on exactly which version of a patch was applied
>>>>> * No need to search by patch subject
>>>>>
>>>>> Here is an example in a working branch:
>>>>>
>>>>>
>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>>
>>>>
>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>>
>>>
>>> Would it be more or less compelling if it had a format similar this?
>>>
>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>>
>>
>> Yes.
>
>
> Sorry, for dummy question ... what should I see in the above link?

The link is the think to see, not what it points to. The idea is that
instead of just the patch number, include the patch number in a full
URL for even easier access to the patch.

Cheers,
-Joe

[U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Joe,

Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
> Hi Heiko,
>
> On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher <hs@denx.de> wrote:
>> Hello Tom,
>>
>> Am 28.01.2016 um 00:45 schrieb Tom Rini:
>>>
>>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>>>>
>>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>>>>
>>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> I'm playing with the idea of including the patchwork patch ID in the
>>>>>> commit message of each commit that I apply to provide better
>>>>>> cross-reference ability.
>>>>>>
>>>>>> * Access to comments on patches
>>>>>> * Clarity on exactly which version of a patch was applied
>>>>>> * No need to search by patch subject
>>>>>>
>>>>>> Here is an example in a working branch:
>>>>>>
>>>>>>
>>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>>>
>>>>>
>>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>>>
>>>>
>>>> Would it be more or less compelling if it had a format similar this?
>>>>
>>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>>>
>>>
>>> Yes.
>>
>>
>> Sorry, for dummy question ... what should I see in the above link?
>
> The link is the think to see, not what it points to. The idea is that
> instead of just the patch number, include the patch number in a full
> URL for even easier access to the patch.

Uh, ah, got it ... I think the patchworks patchnumber would be enough.
I like Bins proposal, that patchwork add it automatically ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Include patchwork patch ID in commit message?

[Masahiro Yamada]

2016-01-29 14:14 GMT+09:00 Heiko Schocher <hs@denx.de>:
> Hello Joe,
>
>
> Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
>>
>> Hi Heiko,
>>
>> On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher <hs@denx.de> wrote:
>>>
>>> Hello Tom,
>>>
>>> Am 28.01.2016 um 00:45 schrieb Tom Rini:
>>>>
>>>>
>>>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>>>>>
>>>>>
>>>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> I'm playing with the idea of including the patchwork patch ID in the
>>>>>>> commit message of each commit that I apply to provide better
>>>>>>> cross-reference ability.
>>>>>>>
>>>>>>> * Access to comments on patches
>>>>>>> * Clarity on exactly which version of a patch was applied
>>>>>>> * No need to search by patch subject
>>>>>>>
>>>>>>> Here is an example in a working branch:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>>>>
>>>>>
>>>>>
>>>>> Would it be more or less compelling if it had a format similar this?
>>>>>
>>>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>>>>
>>>>
>>>>
>>>> Yes.
>>>
>>>
>>>
>>> Sorry, for dummy question ... what should I see in the above link?
>>
>>
>> The link is the think to see, not what it points to. The idea is that
>> instead of just the patch number, include the patch number in a full
>> URL for even easier access to the patch.
>
>
> Uh, ah, got it ... I think the patchworks patchnumber would be enough.
> I like Bins proposal, that patchwork add it automatically ...



X-Patchwork-Id: 561384

I assume this tag points to the last version which was actually
applied to the git tree.


If you want to know the whole history of each patch,
you should see former versions as well as the last one.

The last version is often mature,
so it may end up with just having "Applied to u-boot/master, thanks!",
which does not carry useful information at all.

Nor do I want to see something as follows.
X-Pachwork-Id-v1: 561184
X-Pachwork-Id-v2: 561284
X-Pachwork-Id-v3: 561384



-- 
Best Regards
Masahiro Yamada

[U-Boot] Include patchwork patch ID in commit message?

[Albert ARIBAUD]

Hello Masahiro,

On Fri, 29 Jan 2016 18:57:28 +0900, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2016-01-29 14:14 GMT+09:00 Heiko Schocher <hs@denx.de>:
> > Hello Joe,
> >
> >
> > Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
> >>
> >> Hi Heiko,
> >>
> >> On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher <hs@denx.de> wrote:
> >>>
> >>> Hello Tom,
> >>>
> >>> Am 28.01.2016 um 00:45 schrieb Tom Rini:
> >>>>
> >>>>
> >>>> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> >>>>>
> >>>>>
> >>>>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Tom,
> >>>>>>>
> >>>>>>> I'm playing with the idea of including the patchwork patch ID in the
> >>>>>>> commit message of each commit that I apply to provide better
> >>>>>>> cross-reference ability.
> >>>>>>>
> >>>>>>> * Access to comments on patches
> >>>>>>> * Clarity on exactly which version of a patch was applied
> >>>>>>> * No need to search by patch subject
> >>>>>>>
> >>>>>>> Here is an example in a working branch:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Would it be more or less compelling if it had a format similar this?
> >>>>>
> >>>>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
> >>>>
> >>>>
> >>>>
> >>>> Yes.
> >>>
> >>>
> >>>
> >>> Sorry, for dummy question ... what should I see in the above link?
> >>
> >>
> >> The link is the think to see, not what it points to. The idea is that
> >> instead of just the patch number, include the patch number in a full
> >> URL for even easier access to the patch.
> >
> >
> > Uh, ah, got it ... I think the patchworks patchnumber would be enough.
> > I like Bins proposal, that patchwork add it automatically ...
> 
> 
> 
> X-Patchwork-Id: 561384
> 
> I assume this tag points to the last version which was actually
> applied to the git tree.

It points to the message in Patchwork -- patchwork does not apply
patches on any tree; in fact, patchwork is totally unrelated to git.

> If you want to know the whole history of each patch,
> you should see former versions as well as the last one.
> 
> The last version is often mature,
> so it may end up with just having "Applied to u-boot/master, thanks!",
> which does not carry useful information at all.

The last message in the thread started by the patch will have this. But
that last message will be unknown by patchwork, which only records
patches [apart from rare false positive cases where PW thinks a message
is a patch, because there is git diff extract pasted into it].

> Nor do I want to see something as follows.
> X-Pachwork-Id-v1: 561184
> X-Pachwork-Id-v2: 561284
> X-Pachwork-Id-v3: 561384

AFAICT, patchwork is not able tell which patch is the vN-1 of a given vN
patch, and probably never will, as there is in fact no reliable way to
reconstruct this. A vN patch does not necessarily have the same subject
line as its vN-1, and does not necessarily have its vN-1's message-Id
listed in its 'Reference:' header.

So you would never see the above anyway.

What I have personally set up recently is a Python script which
goes through my Claws Mail U-Boot mail directory and, for each mail,
queries Patchwork with the Message-ID and, failing that, with each
Reference in turn, and adds X-Patchwork-{id,delegate,state...} to the
mail. There is some ad hoc logic for things like cover letters, and of
course, a caching mechanism so that I query PW only once per message-ID
-- so for a long thread about a single patch, there will be a single
actual query.

Oh, and it adds both an X-Patchwork-Id and an W-Patchwork-URL. :)

I run this regularly on my U-Boot inbox.

(if anyone knows how to query patchwork for "details for every patch
which has changed since the date I last asked", let me know.)

Amicalement,
-- 
Albert.

[U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Thu, Jan 28, 2016 at 07:39:54AM +0100, Heiko Schocher wrote:

[snip]
> Out of topic .... maybe tbot can help you here a lot. I have an automated
> build for example for the smartweb board [1], which does:
> 
> +      - clone u-boot.git
> +      - set toolchain
> +      - get a list of patchwork patches from my U-Boots ToDo list
> +      - download all of them, and check them with checkpatch
> +        and apply them to u-boot.git
> +      - compile U-Boot for the smartweb board
> +      - install the resulting images on the smartweb board
> +      - boot U-boot
> +      - test DFU
> +      - more TC should be added here for testing U-Boot

I do need to play with tbot and kind of want to use that locally.  For
my build tests however, it's a shared server elsewhere that doesn't have
access to the targets.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160128/3a1514ab/attachment.sig>

[U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Joe,

Am 27.01.2016 um 22:08 schrieb Joe Hershberger:
> Hi Tom,
>
> I'm playing with the idea of including the patchwork patch ID in the
> commit message of each commit that I apply to provide better
> cross-reference ability.
>
> * Access to comments on patches
> * Clarity on exactly which version of a patch was applied
> * No need to search by patch subject
>
> Here is an example in a working branch:
>
> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>
> What do you (or anyone else) think?

Good idea, I would prefer:

X-Patchwork-Id: 561384

Thats what is in the mbox file, you download from patchwork ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Thu, Jan 28, 2016 at 12:13 AM, Heiko Schocher <hs@denx.de> wrote:
> Hello Joe,
>
> Am 27.01.2016 um 22:08 schrieb Joe Hershberger:
>>
>> Hi Tom,
>>
>> I'm playing with the idea of including the patchwork patch ID in the
>> commit message of each commit that I apply to provide better
>> cross-reference ability.
>>
>> * Access to comments on patches
>> * Clarity on exactly which version of a patch was applied
>> * No need to search by patch subject
>>
>> Here is an example in a working branch:
>>
>>
>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>
>> What do you (or anyone else) think?
>
>
> Good idea, I would prefer:
>
> X-Patchwork-Id: 561384
>
> Thats what is in the mbox file, you download from patchwork ...

Good point. I think that makes sense if we end up not including the link.

> bye,
> Heiko
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany