[U-Boot] Custodian branch base commits

[U-Boot] Custodian branch base commits

[Stephen Warren]

The instructions at:

http://www.denx.de/wiki/U-Boot/CustodianGitTrees

... indicate that downstream branches should be rebased onto
${upstream}/master immediately prior to sending a pull request. I'm not
sure this is correct any more, given that upstream master branches now
pull in downstream branches via "git merge" rather than "git rebase".
Should that page be changed?

The question then becomes: What commit should downstream branches use as
their baseline. I assert that they should be free to choose any commit
in their upstream master branch (or merge in any upstream commit), or
any further upstream branch all the way up to u-boot/master.

As background, I want to send a commit to the Tegra tree that enables
use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in
Tegra's default environment to use the new shell commands that config
option enables.

However, the commits that implement CONFIG_CMD_FS_GENERIC are in
u-boot/master but not yet in u-boot-arm/master. So, Tegra's master
branch can't simply be based on current u-boot-arm/master, since if it
was, applying my patch would break functionality until it was merged
with u-boot/master and so picked up the actual implementation.

Hopefully, u-boot-arm/master will merge in (or get reset to)
u-boot/master fairly shortly. However, should Tegra's repo have to wait
for this?

Instead, I propose that 2nd-level custodians should be able to do
something like:

# (in u-boot-tegra.git, assuming everything is merged already)
git checkout master
git reset --hard u-boot/master
git am patch_that_depends_on_uboot_master
# send pull request to u-boot-arm/master

# (in u-boot-tegra.git, assuming some patches already applied locally)
git checkout master
git merge u-boot/master
git am patch_that_depends_on_uboot_master
# send pull request to u-boot-arm/master

This should work fine provided that u-boot/master and u-boot-arm/master
guarantee never to rebase. If they don't make that guarantee, then I
don't think we can be using merges at all anyway, so that shouldn't be
an issue.

What do people think?

[U-Boot] Custodian branch base commits

[Wolfgang Denk]

Dear Stephen Warren,

In message <50900FED.6040508@wwwdotorg.org> you wrote:
> 
> # (in u-boot-tegra.git, assuming everything is merged already)
> git checkout master
> git reset --hard u-boot/master

What would this specific command sequence be good for? [And what
exactly is "u-boot/master" supposed to be?]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ninety-Ninety Rule of Project Schedules:
        The first ninety percent of the task takes ninety percent of
the time, and the last ten percent takes the other ninety percent.

[U-Boot] Custodian branch base commits

[Stephen Warren]

On 10/30/2012 12:50 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <50900FED.6040508@wwwdotorg.org> you wrote:
>>
>> # (in u-boot-tegra.git, assuming everything is merged already)
>> git checkout master
>> git reset --hard u-boot/master
> 
> What would this specific command sequence be good for? [And what
> exactly is "u-boot/master" supposed to be?]

Starting a new branch of development from something in the upstream
repository. Here's we're re-using existing branch name "master" for the
new branch, hence "git reset" rather than "git checkout -b". Resetting
the branch and essentially starting from scratch means creating much
less of a rats-nest of merges in downstream repos.

u-boot/master is the standard git nomenclature for remote u-boot
(assumed to point at git://git.denx.de/u-boot.git) branch master.

[U-Boot] Custodian branch base commits

[Wolfgang Denk]

Dear Stephen Warren,

In message <5090228A.7090606@wwwdotorg.org> you wrote:
>
> >> # (in u-boot-tegra.git, assuming everything is merged already)
> >> git checkout master
> >> git reset --hard u-boot/master
> > 
> > What would this specific command sequence be good for? [And what
> > exactly is "u-boot/master" supposed to be?]
> 
> Starting a new branch of development from something in the upstream
> repository. Here's we're re-using existing branch name "master" for the
> new branch, hence "git reset" rather than "git checkout -b". Resetting
> the branch and essentially starting from scratch means creating much

Why don't you do just

	git branch -D master
	git checkout -b master u-boot/master

instead?

BTW - why are you doing this on the "master" branch?  Any other branch
name appears more appropriate to me for such work?

> u-boot/master is the standard git nomenclature for remote u-boot
> (assumed to point at git://git.denx.de/u-boot.git) branch master.

standard git nomenclature? Do you happen to have a pointer for me?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875

[U-Boot] Custodian branch base commits

[Stephen Warren]

On 10/30/2012 02:47 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <5090228A.7090606@wwwdotorg.org> you wrote:
>>
>>>> # (in u-boot-tegra.git, assuming everything is merged already)
>>>> git checkout master
>>>> git reset --hard u-boot/master
>>>
>>> What would this specific command sequence be good for? [And what
>>> exactly is "u-boot/master" supposed to be?]
>>
>> Starting a new branch of development from something in the upstream
>> repository. Here's we're re-using existing branch name "master" for the
>> new branch, hence "git reset" rather than "git checkout -b". Resetting
>> the branch and essentially starting from scratch means creating much
> 
> Why don't you do just
> 
> 	git branch -D master
> 	git checkout -b master u-boot/master
> 
> instead?

That would work identically. The exact git commands to do this really
aren't the point of this conversation.

> BTW - why are you doing this on the "master" branch?  Any other branch
> name appears more appropriate to me for such work?

Well, the U-Boot wiki tells all custodians to use a branch named master,
and all the custodian repos I've needed to look at follow this convention.

>> u-boot/master is the standard git nomenclature for remote u-boot
>> (assumed to point at git://git.denx.de/u-boot.git) branch master.
> 
> standard git nomenclature? Do you happen to have a pointer for me?

http://git-scm.com/book/ch3-5.html

First sentence of the second paragraph in the body text.

[U-Boot] Custodian branch base commits

[Wolfgang Denk]

Dear Stephen Warren,

In message <5090423C.5070605@wwwdotorg.org> you wrote:
>
> >>>> git checkout master
> >>>> git reset --hard u-boot/master
...
> > Why don't you do just
> > 	git branch -D master
> > 	git checkout -b master u-boot/master
> > instead?
> 
> That would work identically. The exact git commands to do this really
> aren't the point of this conversation.

Maybe not for you.  But I was trying to understand what you are doing,
and I find your approach difficult to read.  A "git reset --hard" is
nothign I ever do in the normal course of actions.

> > BTW - why are you doing this on the "master" branch?  Any other branch
> > name appears more appropriate to me for such work?
> 
> Well, the U-Boot wiki tells all custodians to use a branch named master,
> and all the custodian repos I've needed to look at follow this convention.

You are supposed to _never_ reset or rebase the master branch.

> >> u-boot/master is the standard git nomenclature for remote u-boot
> >> (assumed to point at git://git.denx.de/u-boot.git) branch master.
> > 
> > standard git nomenclature? Do you happen to have a pointer for me?
> 
> http://git-scm.com/book/ch3-5.html
> 
> First sentence of the second paragraph in the body text.

Ummm... this does not exactly mention that it is considered standard
that "u-boot" refers to git://git.denx.de/u-boot.git .  Please keep in
mind that others might use different names - your original posting did
not explain your assumptions.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Horses just naturally have mohawk haircuts.

[U-Boot] Custodian branch base commits

[Stephen Warren]

On 10/30/2012 04:06 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <5090423C.5070605@wwwdotorg.org> you wrote:
>>
>>>>>> git checkout master
>>>>>> git reset --hard u-boot/master
> ...
>>> Why don't you do just
>>> 	git branch -D master
>>> 	git checkout -b master u-boot/master
>>> instead?
>>
>> That would work identically. The exact git commands to do this really
>> aren't the point of this conversation.
> 
> Maybe not for you.  But I was trying to understand what you are doing,
> and I find your approach difficult to read.  A "git reset --hard" is
> nothign I ever do in the normal course of actions.
> 
>>> BTW - why are you doing this on the "master" branch?  Any other branch
>>> name appears more appropriate to me for such work?
>>
>> Well, the U-Boot wiki tells all custodians to use a branch named master,
>> and all the custodian repos I've needed to look at follow this convention.
> 
> You are supposed to _never_ reset or rebase the master branch.

I assume that statement is conditionalized by "within the U-Boot
process" and "in the main u-boot.git repository"; it's not necessarily
required to be true just due to use of git.

Well, even in recent history, that hasn't been actual practice. The wiki
even explicitly tells you to rebase:

http://www.denx.de/wiki/U-Boot/CustodianGitTrees

Who owns updating that? I could take a stab, but since I'm pretty new to
U-Boot development, not a custodian, and pushing for changes, I'm
probably not the best person to re-write it, and least not without a
code-review/patch-based process.

>>>> u-boot/master is the standard git nomenclature for remote u-boot
>>>> (assumed to point at git://git.denx.de/u-boot.git) branch master.
>>>
>>> standard git nomenclature? Do you happen to have a pointer for me?
>>
>> http://git-scm.com/book/ch3-5.html
>>
>> First sentence of the second paragraph in the body text.
> 
> Ummm... this does not exactly mention that it is considered standard
> that "u-boot" refers to git://git.denx.de/u-boot.git .  Please keep in
> mind that others might use different names - your original posting did
> not explain your assumptions.

Oh, I thought you were talking about the syntax, not the exact names of
remotes and branches.

[U-Boot] Custodian branch base commits

[Jerry Van Baren]

On 10/30/2012 06:20 PM, Stephen Warren wrote:
> On 10/30/2012 04:06 PM, Wolfgang Denk wrote:
>> Dear Stephen Warren,
>>
>> In message <5090423C.5070605@wwwdotorg.org> you wrote:
>>>
>>>>>>> git checkout master
>>>>>>> git reset --hard u-boot/master
>> ...
>>>> Why don't you do just
>>>> 	git branch -D master
>>>> 	git checkout -b master u-boot/master
>>>> instead?
>>>
>>> That would work identically. The exact git commands to do this really
>>> aren't the point of this conversation.
>>
>> Maybe not for you.  But I was trying to understand what you are doing,
>> and I find your approach difficult to read.  A "git reset --hard" is
>> nothign I ever do in the normal course of actions.
>>
>>>> BTW - why are you doing this on the "master" branch?  Any other branch
>>>> name appears more appropriate to me for such work?
>>>
>>> Well, the U-Boot wiki tells all custodians to use a branch named master,
>>> and all the custodian repos I've needed to look at follow this convention.
>>
>> You are supposed to _never_ reset or rebase the master branch.
> 
> I assume that statement is conditionalized by "within the U-Boot
> process" and "in the main u-boot.git repository"; it's not necessarily
> required to be true just due to use of git.
> 
> Well, even in recent history, that hasn't been actual practice. The wiki
> even explicitly tells you to rebase:
> 
> http://www.denx.de/wiki/U-Boot/CustodianGitTrees
> 
> Who owns updating that?

It's a wiki, *nobody* owns it. :-O

> I could take a stab, but since I'm pretty new to U-Boot development,
> not a custodian, and pushing for changes, I'm probably not the best
> person to re-write it, and least not without a 
> code-review/patch-based process.

I wrote the advice in 2007, relatively early days in our (u-boot's and
my) git usage.
  <http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees?rev=1.19>
It is definitely worth updating to recommend better techniques.

Best regards,
gvb

[snip]

[U-Boot] Custodian branch base commits

[Tom Rini]

On Tue, Oct 30, 2012 at 11:35:41AM -0600, Stephen Warren wrote:

> The instructions at:
> 
> http://www.denx.de/wiki/U-Boot/CustodianGitTrees
> 
> ... indicate that downstream branches should be rebased onto
> ${upstream}/master immediately prior to sending a pull request. I'm not
> sure this is correct any more, given that upstream master branches now
> pull in downstream branches via "git merge" rather than "git rebase".
> Should that page be changed?

Yes.

> The question then becomes: What commit should downstream branches use as
> their baseline. I assert that they should be free to choose any commit
> in their upstream master branch (or merge in any upstream commit), or
> any further upstream branch all the way up to u-boot/master.

I disagree.  It should be limited to your direct upstream only because..

> As background, I want to send a commit to the Tegra tree that enables
> use of CONFIG_CMD_FS_GENERIC, and additionally, re-write bootcmd in
> Tegra's default environment to use the new shell commands that config
> option enables.
> 
> However, the commits that implement CONFIG_CMD_FS_GENERIC are in
> u-boot/master but not yet in u-boot-arm/master. So, Tegra's master
> branch can't simply be based on current u-boot-arm/master, since if it
> was, applying my patch would break functionality until it was merged
> with u-boot/master and so picked up the actual implementation.

Yay for making use of new functionality, but..

> Hopefully, u-boot-arm/master will merge in (or get reset to)
> u-boot/master fairly shortly. However, should Tegra's repo have to wait
> for this?

Yes, tegra has to wait otherwise you've just forced u-boot-arm into a
re-sync with master and now u-boot-arm can't where problems came from,
be it your tree or master.  Patience is required, and I expect that
Albert will update to current master before starting his pull requests.
I also think it's fine to state that your pull request depends on $rev
being merged in prior to your pull.  But this is roughly how the kernel
trees work I believe.  You do a series of patches, state your
pre-request and deal with merging the changes up the different trees as
they are ready for it.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121030/1fb7bfda/attachment.pgp>

[U-Boot] Custodian branch base commits

[Stephen Warren]

On 10/30/2012 03:19 PM, Tom Rini wrote:
> On Tue, Oct 30, 2012 at 11:35:41AM -0600, Stephen Warren wrote:
> 
>> The instructions at:
>> 
>> http://www.denx.de/wiki/U-Boot/CustodianGitTrees
>> 
>> ... indicate that downstream branches should be rebased onto 
>> ${upstream}/master immediately prior to sending a pull request.
>> I'm not sure this is correct any more, given that upstream master
>> branches now pull in downstream branches via "git merge" rather
>> than "git rebase". Should that page be changed?
> 
> Yes.
> 
>> The question then becomes: What commit should downstream branches
>> use as their baseline. I assert that they should be free to
>> choose any commit in their upstream master branch (or merge in
>> any upstream commit), or any further upstream branch all the way
>> up to u-boot/master.
> 
> I disagree.  It should be limited to your direct upstream only
> because..
> 
>> As background, I want to send a commit to the Tegra tree that
>> enables use of CONFIG_CMD_FS_GENERIC, and additionally, re-write
>> bootcmd in Tegra's default environment to use the new shell
>> commands that config option enables.
>> 
>> However, the commits that implement CONFIG_CMD_FS_GENERIC are in 
>> u-boot/master but not yet in u-boot-arm/master. So, Tegra's
>> master branch can't simply be based on current u-boot-arm/master,
>> since if it was, applying my patch would break functionality
>> until it was merged with u-boot/master and so picked up the
>> actual implementation.
> 
> Yay for making use of new functionality, but..
> 
>> Hopefully, u-boot-arm/master will merge in (or get reset to) 
>> u-boot/master fairly shortly. However, should Tegra's repo have
>> to wait for this?
> 
> Yes, tegra has to wait otherwise you've just forced u-boot-arm into
> a re-sync with master and now u-boot-arm can't where problems came
> from, be it your tree or master.

That is only true if the pull request sent to u-boot-arm from
u-boot-tegra is sent or processed before u-boot-arm pulls in the
u-boot commit that u-boot-tegra was based upon.

In other words, I don't think this issue requires that leaf repos be
based on a commit that's already in their immediate upstream repo, but
rather that leaf repos don't send a pull request to their upstream
repo until the leaf repo's baseline commit is included in their
upstream repo.

The difference here is that it would allow pipelining; leaf repos like
u-boot-tegra could grab the latest u-boot/master as a base, debug and
fix a bunch of bugs there, and be ready to send the pull request, all
in parallel with u-boot-arm actually pulling in u-boot/master.

Without this process, the Tegra maintainer has to synchronously wait
for the problematic commits to show up in u-boot-arm before he can
even apply fixes for them, even if the fixes are well known and fully
developed. Or, we try and apply patches to u-boot-tegra/master (based
only on u-boot-arm/master) that fix issues not yet in the branch, in a
way that when eventually merged into u-boot/master, the problems there
will be fixed. That's quite a lot harder in general!

> Patience is required, and I expect that Albert will update to
> current master before starting his pull requests. I also think it's
> fine to state that your pull request depends on $rev being merged
> in prior to your pull.

But that would imply that the git history in the pull request doesn't
actually build or run correctly on its own. The only way for it to
build or run correctly is for it to be actually based on the commit it
depends on. Simply stating patch dependencies works when sending
patches as a hint to say when to apply them, but as soon as something
is in git, it should work given the actual git history in that branch.

> But this is roughly how the kernel trees work I believe.  You do a
> series of patches, state your pre-request and deal with merging the
> changes up the different trees as they are ready for it.

For patches by email, yes.

For git merges/pulls, a variety of solutions exist:

* All the patches are applied to a single branch. This would require
the maintainer that would usually take a dependant patch to ack it so
that it can be taken through a different branch where the dependencies
are already present.

In this case, the change to use CONFIG_CMD_FS_GENERIC for Tegra could
be taken through u-boot/master rather than u-boot-tegra/master, with
the appropriate Ack from Tom Warren, since that's where the
implementation of CONFIG_CMD_FS_GENERIC was applied.

* The dependencies are placed into a topic branch, which itself is
based on an rc or release of the kernel, and this topic branch is
merged into all places that wish to apply patches that depend on the
topic branch. The topic branch gets pulled up into Linus' tree via
paths, which git handles just fine (at least for merges; duplicate
direct patch application would be more problematic and is generally
avoided).

* Or, development just gets synchronized every ~3 months via the
release process. However, that drastically slows the amount of forward
progress that can be made.

[U-Boot] Custodian branch base commits

[Albert ARIBAUD]

Hi Stephen,

On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren
<swarren@wwwdotorg.org> wrote:

> >> Hopefully, u-boot-arm/master will merge in (or get reset to) 
> >> u-boot/master fairly shortly. However, should Tegra's repo have
> >> to wait for this?
> > 
> > Yes, tegra has to wait otherwise you've just forced u-boot-arm into
> > a re-sync with master and now u-boot-arm can't where problems came
> > from, be it your tree or master.
> 
> That is only true if the pull request sent to u-boot-arm from
> u-boot-tegra is sent or processed before u-boot-arm pulls in the
> u-boot commit that u-boot-tegra was based upon.
> 
> In other words, I don't think this issue requires that leaf repos be
> based on a commit that's already in their immediate upstream repo, but
> rather that leaf repos don't send a pull request to their upstream
> repo until the leaf repo's baseline commit is included in their
> upstream repo.

Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some
commits from u-boot/master that are not already in u-boot/arm, then
when I fetch u-boot-tegra/master, these commits will automatically get
fetched along, and when I fetch u-boot/arm, these commits will just be
already there.

So what am I missing?

Amicalement,
-- 
Albert.

[U-Boot] Custodian branch base commits

[Stephen Warren]

On 11/03/2012 05:49 AM, Albert ARIBAUD wrote:
> Hi Stephen,
> 
> On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren
> <swarren@wwwdotorg.org> wrote:
> 
>>>> Hopefully, u-boot-arm/master will merge in (or get reset to) 
>>>> u-boot/master fairly shortly. However, should Tegra's repo have
>>>> to wait for this?
>>>
>>> Yes, tegra has to wait otherwise you've just forced u-boot-arm into
>>> a re-sync with master and now u-boot-arm can't where problems came
>>> from, be it your tree or master.
>>
>> That is only true if the pull request sent to u-boot-arm from
>> u-boot-tegra is sent or processed before u-boot-arm pulls in the
>> u-boot commit that u-boot-tegra was based upon.
>>
>> In other words, I don't think this issue requires that leaf repos be
>> based on a commit that's already in their immediate upstream repo, but
>> rather that leaf repos don't send a pull request to their upstream
>> repo until the leaf repo's baseline commit is included in their
>> upstream repo.
> 
> Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some
> commits from u-boot/master that are not already in u-boot/arm, then
> when I fetch u-boot-tegra/master, these commits will automatically get
> fetched along,

That's correct. The issue is whether this is acceptable, since it means
pulling non-Tegra commits into u-boot-arm/master along with the Tegra
commits.

> and when I fetch u-boot/arm, these commits will just be
> already there.

I'm not sure what "fetch u-boot/arm" means in that context. I believe
we're talking about merging u-boot-tegra/master into u-boot-arm/master,
and that merge would happen in your local branch, so I'm not sure why
you'd need to fetch anything after the merge?

Are you talking about when you later merge (not fetch) u-boot/master
(not u-boot/arm)? If so, then yes, that merge would simply pull in fewer
new commits because some would already be there.

[U-Boot] Custodian branch base commits

[Albert ARIBAUD]

Hi Stephen,

On Mon, 05 Nov 2012 10:17:23 -0700, Stephen Warren
<swarren@wwwdotorg.org> wrote:

> On 11/03/2012 05:49 AM, Albert ARIBAUD wrote:
> > Hi Stephen,
> > 
> > On Wed, 31 Oct 2012 10:56:08 -0600, Stephen Warren
> > <swarren@wwwdotorg.org> wrote:
> > 
> >>>> Hopefully, u-boot-arm/master will merge in (or get reset to) 
> >>>> u-boot/master fairly shortly. However, should Tegra's repo have
> >>>> to wait for this?
> >>>
> >>> Yes, tegra has to wait otherwise you've just forced u-boot-arm into
> >>> a re-sync with master and now u-boot-arm can't where problems came
> >>> from, be it your tree or master.
> >>
> >> That is only true if the pull request sent to u-boot-arm from
> >> u-boot-tegra is sent or processed before u-boot-arm pulls in the
> >> u-boot commit that u-boot-tegra was based upon.
> >>
> >> In other words, I don't think this issue requires that leaf repos be
> >> based on a commit that's already in their immediate upstream repo, but
> >> rather that leaf repos don't send a pull request to their upstream
> >> repo until the leaf repo's baseline commit is included in their
> >> upstream repo.
> > 
> > Stop me if I'm wrong, but if e.g. u-boot-tegra/master dependsn on some
> > commits from u-boot/master that are not already in u-boot/arm, then
> > when I fetch u-boot-tegra/master, these commits will automatically get
> > fetched along,
> 
> That's correct. The issue is whether this is acceptable, since it means
> pulling non-Tegra commits into u-boot-arm/master along with the Tegra
> commits.

To me it is, as long as these non-tegra commits come from a U-Boot repo
whose custodian has accepted them. It is the responsibility of the pull
requester to indicate if the commits in his request require any commit
not already in an upstream repo..

> > and when I fetch u-boot/arm, these commits will just be
> > already there.
> 
> I'm not sure what "fetch u-boot/arm" means in that context. I believe
> we're talking about merging u-boot-tegra/master into u-boot-arm/master,
> and that merge would happen in your local branch, so I'm not sure why
> you'd need to fetch anything after the merge?
> 
> Are you talking about when you later merge (not fetch) u-boot/master
> (not u-boot/arm)? If so, then yes, that merge would simply pull in fewer
> new commits because some would already be there.

This is what I meant.

Amicalement,
-- 
Albert.