[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Ludovic Courtès]

* doc/contributing.texi (Teams): Define the purpose of teams; provide
example; clarify membership and team creation.
(Reviewing the Work of Others): Link to “Teams”.

Change-Id: I5d75f69bc4653eb9da9c1d1f920718238ea83b9d
---
 doc/contributing.texi | 63 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 53 insertions(+), 10 deletions(-)

Hello Guix!

The recent discussion about creating a browser team¹ made it clear
that teams are not defined anywhere: the manual doesn’t say what their
mission is, how to become a member, how to revoke members, nor how
to create new teams.

This patch is an attempt to formalize that.  I believe there’s nothing
really new for someone who’s been following closely in recent times, but
it should definitely improve legibility for newcomers.

Thoughts?

I suggest that we iterate on this for at most one month so we have a
first version checked in by September 30th.

Ludo’.

¹ https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00168.html

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 73f7addbef..7705367bce 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2225,8 +2225,52 @@ Teams
 @subsection Teams
 @cindex teams
 
-There are several teams mentoring different parts of the Guix source
-code.  To list all those teams, you can run from a Guix checkout:
+To organize work on Guix, including but not just development efforts,
+the project has a set of @dfn{teams}.  Each team has its own focus and
+interests and is the primary contact point for questions and
+contributions in those areas.  A team's primary mission is to coordinate
+and review the work of individuals in its scope (@pxref{Reviewing the
+Work of Others}); it can make decisions within its scope, in agreement
+with other teams whenever there is overlap or a close connection, and in
+accordance with other project rules such as seeking consensus.
+@c TODO: Currently ``consensus-based decision making'' is discussed
+@c under ``Commit Access''.  Move that elsewhere and refer to it from
+@c here.
+
+As an example, the Python team is responsible for core Python packaging
+matters; it can decide to upgrade core Python packages in a dedicated
+@code{python-team} branch, in collaboration with any team whose scope is
+directly dependent on Python---e.g., the Science team---and following
+branching rules (@pxref{Managing Patches and Branches}).  The
+Documentation team helps review changes to the documentation and can
+initiate overarching documentation changes.  The Translations team
+organizes translation of Guix and its manual and coordinates efforts in
+that area.  The Core team is responsible for the development of core
+functionality and interfaces of Guix; because of its central nature,
+some of its work may require soliciting input from the community at
+large and seeking consensus before enacting decisions that would affect
+the entire community.
+
+Teams are defined in the @file{etc/teams.scm} file in the Guix
+repository.  The scope of each team is defined, when applicable, as a
+set of files or as a regular expression matching file names.
+
+@cindex team membership
+Anyone with interest in a team's domain and willing to contribute to its
+work can apply to become a member by contacting current members by
+email; commit access is not a precondition.  Membership is formalized by
+adding the person's name and email address to @file{etc/teams.scm}.
+Members who have not been participating in the team's work for one year
+or more may be removed; they are free to reapply for membership later.
+
+@cindex team creation
+One or more people may propose the creation of a new team by reaching
+out to the community by email at @email{guix-devel@@gnu.org}, clarifying
+the intended scope and purpose.  When consensus is reached on the
+creation of this team, someone with commit access formalizes its
+creation by adding it and its initial members to @file{etc/teams.scm}.
+
+To list existing teams, run the following command from a Guix checkout:
 
 @example
 $ ./etc/teams.scm list-teams
@@ -2234,15 +2278,12 @@ Teams
 name: Mentors
 description: A group of mentors who chaperone contributions by newcomers.
 members:
-+ Christopher Baines <mail@@cbaines.net>
-+ Ricardo Wurmus <rekado@@elephly.net>
-+ Mathieu Othacehe <othacehe@@gnu.org>
-+ jgart <jgart@@dismail.de>
-+ Ludovic Courtès <ludo@@gnu.org>
++ Charlie Smith <charlie@@example.org>
 @dots{}
 @end example
 
-You can run the following command to have the @code{Mentors} team put in
+@cindex mentoring
+You can run the following command to have the Mentors team put in
 CC of a patch series:
 
 @example
@@ -2905,12 +2946,14 @@ Reviewing the Work of Others
 is to review the work contributed by others.  You do not need to be a
 committer to do so; applying, reading the source, building, linting and
 running other people's series and sharing your comments about your
-experience will give some confidence to committers.  Basically, you must
+experience will give some confidence to committers.  You must
 ensure the check list found in the @ref{Submitting Patches} section has
 been correctly followed.  A reviewed patch series should give the best
 chances for the proposed change to be merged faster, so if a change you
 would like to see merged hasn't yet been reviewed, this is the most
-appropriate thing to do!
+appropriate thing to do!  If you would like to review changes in a
+specific area and to receive notifications for incoming patches relevant
+to that domain, consider joining the relevant team(s) (@pxref{Teams}).
 
 @cindex reviewing, guidelines
 Review comments should be unambiguous; be as clear and explicit as you

base-commit: d5312370b46ace47e138d84e1bb28e5651cee94b
-- 
2.45.2

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Noé Lopez]

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

Clear explanation, thank you. If the @dfn doesn't create an index entry then maybe add one for teams :)

[-- Attachment #2: Type: text/html, Size: 166 bytes --]

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Ludovic Courtès]

Noé Lopez <noelopez@free.fr> skribis:

> Clear explanation, thank you. If the @dfn doesn't create an index entry then maybe add one for teams :)

Thanks!  There was already an “@cindex teams” so it should be good.

Ludo’.

Re: bug#72891: [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Simon Tournier]

Hi Ludo,

As you mentioned elsewhere, this patch deserves the attention of
guix-devel, hence CC: guix-devel. :-)

    [bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.
    Ludovic Courtès <ludo@gnu.org>
    Fri, 30 Aug 2024 12:12:04 +0200
    id:fb9721adfc71b841dcb6a2575539449ce756e401.1725012038.git.ludo@gnu.org
    https://issues.guix.gnu.org/72891
    https://issues.guix.gnu.org/msgid/fb9721adfc71b841dcb6a2575539449ce756e401.1725012038.git.ludo@gnu.org
    https://yhetil.org/guix/fb9721adfc71b841dcb6a2575539449ce756e401.1725012038.git.ludo@gnu.org


Cheers,
simon

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Simon Tournier]

Hi,

On Fri, 30 Aug 2024 at 12:12, Ludovic Courtès <ludo@gnu.org> wrote:

> * doc/contributing.texi (Teams): Define the purpose of teams; provide
> example; clarify membership and team creation.
> (Reviewing the Work of Others): Link to “Teams”.
>
> Change-Id: I5d75f69bc4653eb9da9c1d1f920718238ea83b9d
> ---
>  doc/contributing.texi | 63 ++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 53 insertions(+), 10 deletions(-)

This patch LGTM modulo minor comments.

  ( Aside, I am less and less comfortable to have a manual that collects
    our practises instead of separated documents.  Anyway. :-) )

> +To organize work on Guix, including but not just development efforts,
> +the project has a set of @dfn{teams}.  Each team has its own focus and
> +interests and is the primary contact point for questions and
> +contributions in those areas.  A team's primary mission is to coordinate
> +and review the work of individuals in its scope (@pxref{Reviewing the
> +Work of Others}); it can make decisions within its scope, in agreement
> +with other teams whenever there is overlap or a close connection, and in
> +accordance with other project rules such as seeking consensus.
> +@c TODO: Currently ``consensus-based decision making'' is discussed
> +@c under ``Commit Access''.  Move that elsewhere and refer to it from
> +@c here.

If we are at it.  I think this “section Teams” should be moved to its
own section and not a subsection of “Submitting Patches”.

The “consensus” should also move to its own section.

See v2 for a proposal.


> +As an example, the Python team is responsible for core Python packaging

[...]

> +To list existing teams, run the following command from a Guix checkout:

What is missing between the brackets [...] is a link to “Reviewing the
work of others”.  Somehow, I would add a sentence clarifying “its work”.
For instance, I propose a last sentence in the paragraph:

--8<---------------cut here---------------start------------->8---
As an example, the Python team is responsible for core Python packaging

[...]

the entire community.  Other said, teams provide feedback on patches
touching its scope (@pxref{Reviewing the Work of Others}).
--8<---------------cut here---------------end--------------->8---



Cheers,
simon

[bug#72891] [PATCH v2 1/3] doc: contributing: Move consensus.

[Simon Tournier]

* doc/contributing.texi (Consensus Decision): New section.
Ccommit Access): Move consensus decision to its section.

Change-Id: I7f35b5cea5f7a7a6facbe0ef6f0fdbd98d8a68a7
---
 doc/contributing.texi | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 73f7addbef..46d316294a 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -31,6 +31,7 @@ Contributing
 * Coding Style::                Hygiene of the contributor.
 * Submitting Patches::          Share your work.
 * Tracking Bugs and Changes::   Keeping it all organized.
+* Consensus Decision::          Deciding based on consensus.
 * Commit Access::               Pushing to the official repository.
 * Reviewing the Work of Others::  Some guidelines for sharing reviews.
 * Updating the Guix Package::   Updating the Guix package definition.
@@ -2664,6 +2665,19 @@ Cuirass Build Notifications
 where each RSS entry contains a link to the Cuirass build details page
 of the associated build.
 
+@node Consensus Decision
+@section Consensus Decision
+
+By using consensus, we are committed to finding solutions that everyone
+can live with.  It implies that no decision is made against significant
+concerns and these concerns are actively resolved with proposals that
+work for everyone.  A contributor (which may or may not have commit
+access) wishing to block a proposal bears a special responsibility for
+finding alternatives, proposing ideas/code or explain the rationale for
+the status quo to resolve the deadlock.  To learn what consensus
+decision making means and understand its finer details, you are
+encouraged to read @url{https://www.seedsforchange.org.uk/consensus}.
+
 @node Commit Access
 @section Commit Access
 
@@ -2679,16 +2693,8 @@ Commit Access
 thought of as a ``badge of honor'' but rather as a responsibility a
 contributor is willing to take to help the project.  It is expected from
 all contributors, and even more so from committers, to help build
-consensus and make decisions based on consensus.  By using consensus, we
-are committed to finding solutions that everyone can live with.  It
-implies that no decision is made against significant concerns and these
-concerns are actively resolved with proposals that work for everyone.  A
-contributor (which may or may not have commit access) wishing to block a
-proposal bears a special responsibility for finding alternatives,
-proposing ideas/code or explain the rationale for the status quo to
-resolve the deadlock.  To learn what consensus decision making means and
-understand its finer details, you are encouraged to read
-@url{https://www.seedsforchange.org.uk/consensus}.
+consensus and make decisions based on consensus (@pxref{Consensus
+Decision}).
 
 The following sections explain how to get commit access, how to be ready
 to push commits, and the policies and community expectations for commits

base-commit: 7fa9df431e9423e2b79c8c520de1d0ef7aed910d
-- 
2.45.2

[bug#72891] [PATCH v2 2/3] doc: contributing: Move up section Teams.

[Simon Tournier]

* doc/contributing.texi (Teams): New section.
(Submitting Patches)[Teams]: Move to its own section.

Change-Id: I750f6006e49030dd1e9c93b35652da020b72881a
---
 doc/contributing.texi | 77 ++++++++++++++++++++++---------------------
 1 file changed, 39 insertions(+), 38 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 46d316294a..06edaef77d 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -33,6 +33,7 @@ Contributing
 * Tracking Bugs and Changes::   Keeping it all organized.
 * Consensus Decision::          Deciding based on consensus.
 * Commit Access::               Pushing to the official repository.
+* Teams::                       Teaming up.
 * Reviewing the Work of Others::  Some guidelines for sharing reviews.
 * Updating the Guix Package::   Updating the Guix package definition.
 * Writing Documentation::       Improving documentation in GNU Guix.
@@ -2222,44 +2223,6 @@ Sending a Patch Series
 another cover letter, e.g. for explaining what's changed since the last
 revision, and these changes are necessary.
 
-@node Teams
-@subsection Teams
-@cindex teams
-
-There are several teams mentoring different parts of the Guix source
-code.  To list all those teams, you can run from a Guix checkout:
-
-@example
-$ ./etc/teams.scm list-teams
-id: mentors
-name: Mentors
-description: A group of mentors who chaperone contributions by newcomers.
-members:
-+ Christopher Baines <mail@@cbaines.net>
-+ Ricardo Wurmus <rekado@@elephly.net>
-+ Mathieu Othacehe <othacehe@@gnu.org>
-+ jgart <jgart@@dismail.de>
-+ Ludovic Courtès <ludo@@gnu.org>
-@dots{}
-@end example
-
-You can run the following command to have the @code{Mentors} team put in
-CC of a patch series:
-
-@example
-$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org \
-  --header-cmd='etc/teams.scm cc-mentors-header-cmd' *.patch
-@end example
-
-The appropriate team or teams can also be inferred from the modified
-files.  For instance, if you want to send the two latest commits of the
-current Git repository to review, you can run:
-
-@example
-$ guix shell -D guix
-[env]$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org -2
-@end example
-
 @node Tracking Bugs and Changes
 @section Tracking Bugs and Changes
 
@@ -2904,6 +2867,44 @@ Commit Access
 you're welcome to use your expertise and commit rights to help other
 contributors, too!
 
+@node Teams
+@section Teams
+@cindex teams
+
+There are several teams mentoring different parts of the Guix source
+code.  To list all those teams, you can run from a Guix checkout:
+
+@example
+$ ./etc/teams.scm list-teams
+id: mentors
+name: Mentors
+description: A group of mentors who chaperone contributions by newcomers.
+members:
++ Christopher Baines <mail@@cbaines.net>
++ Ricardo Wurmus <rekado@@elephly.net>
++ Mathieu Othacehe <othacehe@@gnu.org>
++ jgart <jgart@@dismail.de>
++ Ludovic Courtès <ludo@@gnu.org>
+@dots{}
+@end example
+
+You can run the following command to have the @code{Mentors} team put in
+CC of a patch series:
+
+@example
+$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org \
+  --header-cmd='etc/teams.scm cc-mentors-header-cmd' *.patch
+@end example
+
+The appropriate team or teams can also be inferred from the modified
+files.  For instance, if you want to send the two latest commits of the
+current Git repository to review, you can run:
+
+@example
+$ guix shell -D guix
+[env]$ git send-email --to=@var{ISSUE_NUMBER}@@debbugs.gnu.org -2
+@end example
+
 @node Reviewing the Work of Others
 @section Reviewing the Work of Others
 
-- 
2.45.2

[bug#72891] [PATCH v2 3/3] doc: Define the purpose, membership, and creation of teams.

[Simon Tournier]

* doc/contributing.texi (Teams): Define the purpose of teams; provide
example; clarify membership and team creation.
(Reviewing the Work of Others): Link to “Teams”.

Change-Id: Ibefbde1654ac8dd2321eb977fbcd3966b8fb8e01
---
 doc/contributing.texi | 56 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 48 insertions(+), 8 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 06edaef77d..af2c044f71 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2871,8 +2871,51 @@ Teams
 @section Teams
 @cindex teams
 
-There are several teams mentoring different parts of the Guix source
-code.  To list all those teams, you can run from a Guix checkout:
+To organize work on Guix, including but not just development efforts,
+the project has a set of @dfn{teams}.  Each team has its own focus and
+interests and is the primary contact point for questions and
+contributions in those areas.  A team's primary mission is to coordinate
+and review the work of individuals in its scope (@pxref{Reviewing the
+Work of Others}); it can make decisions within its scope, in agreement
+with other teams whenever there is overlap or a close connection, and in
+accordance with other project rules such as seeking consensus
+(@pxref{Consensus Decision}).
+
+As an example, the Python team is responsible for core Python packaging
+matters; it can decide to upgrade core Python packages in a dedicated
+@code{python-team} branch, in collaboration with any team whose scope is
+directly dependent on Python---e.g., the Science team---and following
+branching rules (@pxref{Managing Patches and Branches}).  The
+Documentation team helps review changes to the documentation and can
+initiate overarching documentation changes.  The Translations team
+organizes translation of Guix and its manual and coordinates efforts in
+that area.  The Core team is responsible for the development of core
+functionality and interfaces of Guix; because of its central nature,
+some of its work may require soliciting input from the community at
+large and seeking consensus before enacting decisions that would affect
+the entire community.  Other said, teams provide feedback on patches
+touching its scope (@pxref{Reviewing the Work of Others}).
+
+Teams are defined in the @file{etc/teams.scm} file in the Guix
+repository.  The scope of each team is defined, when applicable, as a
+set of files or as a regular expression matching file names.
+
+@cindex team membership
+Anyone with interest in a team's domain and willing to contribute to its
+work can apply to become a member by contacting current members by
+email; commit access is not a precondition.  Membership is formalized by
+adding the person's name and email address to @file{etc/teams.scm}.
+Members who have not been participating in the team's work for one year
+or more may be removed; they are free to reapply for membership later.
+
+@cindex team creation
+One or more people may propose the creation of a new team by reaching
+out to the community by email at @email{guix-devel@@gnu.org}, clarifying
+the intended scope and purpose.  When consensus is reached on the
+creation of this team, someone with commit access formalizes its
+creation by adding it and its initial members to @file{etc/teams.scm}.
+
+To list existing teams, run the following command from a Guix checkout:
 
 @example
 $ ./etc/teams.scm list-teams
@@ -2880,15 +2923,12 @@ Teams
 name: Mentors
 description: A group of mentors who chaperone contributions by newcomers.
 members:
-+ Christopher Baines <mail@@cbaines.net>
-+ Ricardo Wurmus <rekado@@elephly.net>
-+ Mathieu Othacehe <othacehe@@gnu.org>
-+ jgart <jgart@@dismail.de>
-+ Ludovic Courtès <ludo@@gnu.org>
++ Charlie Smith <charlie@@example.org>
 @dots{}
 @end example
 
-You can run the following command to have the @code{Mentors} team put in
+@cindex mentoring
+You can run the following command to have the Mentors team put in
 CC of a patch series:
 
 @example
-- 
2.45.2

[bug#72891] [PATCH v2 3/3] doc: Define the purpose, membership, and creation of teams.

[pelzflorian (Florian Pelz)]

Hi!  I agree with such additions; just some comments:

Patch v2 1/3:

Simon Tournier <zimon.toutoune@gmail.com> writes:
> * doc/contributing.texi (Consensus Decision): New section.
> Ccommit Access): Move consensus decision to its section.

“Consensus Decision” is a single act of deciding.
I guess lengthy “Consensus Decision Making” is the best
section title.

In the commit message, you wrote C instead of an opening parenthesis.


Patch v2 3/3:

Simon Tournier <zimon.toutoune@gmail.com> writes:
> +large and seeking consensus before enacting decisions that would affect
> +the entire community.  Other said, teams provide feedback on patches
> +touching its scope (@pxref{Reviewing the Work of Others}).

“Other said” is close to a term we use in German, but in English better
say something
from <https://en.wiktionary.org/wiki/Thesaurus:in_other_words>.

Regards,
Florian

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Ludovic Courtès]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> On Fri, 30 Aug 2024 at 12:12, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> +@c TODO: Currently ``consensus-based decision making'' is discussed
>> +@c under ``Commit Access''.  Move that elsewhere and refer to it from
>> +@c here.
>
> If we are at it.  I think this “section Teams” should be moved to its
> own section and not a subsection of “Submitting Patches”.
>
> The “consensus” should also move to its own section.

Yes, I agree (I wanted to minimize changes here so we can focus on just
this one thing).

> See v2 for a proposal.

Nice!

>> +As an example, the Python team is responsible for core Python packaging
>
> [...]
>
>> +To list existing teams, run the following command from a Guix checkout:
>
> What is missing between the brackets [...] is a link to “Reviewing the
> work of others”.  Somehow, I would add a sentence clarifying “its work”.
> For instance, I propose a last sentence in the paragraph:
>
> As an example, the Python team is responsible for core Python packaging
>
> [...]
>
> the entire community.  Other said, teams provide feedback on patches
> touching its scope (@pxref{Reviewing the Work of Others}).

The first paragraph reads:

  A team's primary mission is to coordinate and review the work of
  individuals in its scope (@pxref{Reviewing the Work of Others}); it
  can make decisions within its scope, […]

I don’t think that needs repeating.  The second paragraph is a list of
examples of what the first paragraph describes.

Thanks,
Ludo’.

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Simon Tournier]

Hi Ludo,

On Mon, 09 Sep 2024 at 10:58, Ludovic Courtès <ludo@gnu.org> wrote:

> I don’t think that needs repeating.  The second paragraph is a list of
> examples of what the first paragraph describes.

Well, it was my feedback when reading. :-)

LGTM.  Feel free to use v2 or not.  Let me know if you don’t and I will
resend the split to another patch submission.

Cheers,
simon

[bug#72891] [PATCH v2 3/3] doc: Define the purpose, membership, and creation of teams.

[Maxim Cournoyer]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

> Hi!  I agree with such additions; just some comments:
>
> Patch v2 1/3:
>
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>> * doc/contributing.texi (Consensus Decision): New section.
>> Ccommit Access): Move consensus decision to its section.
>
> “Consensus Decision” is a single act of deciding.
> I guess lengthy “Consensus Decision Making” is the best
> section title.
>
> In the commit message, you wrote C instead of an opening parenthesis.
>
>
> Patch v2 3/3:
>
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>> +large and seeking consensus before enacting decisions that would affect
>> +the entire community.  Other said, teams provide feedback on patches
>> +touching its scope (@pxref{Reviewing the Work of Others}).
>
> “Other said” is close to a term we use in German, but in English better
> say something
> from <https://en.wiktionary.org/wiki/Thesaurus:in_other_words>.

I agree that "Other said" doesn't sound too natural in English (in the
sense that I've never heard it from native speakers -- disclaimer: I'm
not one).  I believe Simon borrowed it from "autrement dit", which is
good French :-).

-- 
Thanks,
Maxim

[bug#72891] [PATCH RFC] doc: Define the purpose, membership, and creation of teams.

[Maxim Cournoyer]

Hello!

Ludovic Courtès <ludo@gnu.org> writes:

> * doc/contributing.texi (Teams): Define the purpose of teams; provide
> example; clarify membership and team creation.
> (Reviewing the Work of Others): Link to “Teams”.
>
> Change-Id: I5d75f69bc4653eb9da9c1d1f920718238ea83b9d

Reviewed-by: Maxim Cournoyer <maxim.cournoyer@gmail>

Thanks for authoring it.  I think the first two v2 patches of moving
things around by Simon would make sense as a follow-up, although I
haven't verified the result.

-- 
Maxim