FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 07-17-2008, 11:20 AM
"Cody A.W. Somerville"
 
Default MOTU Leadership Teams - Membership Policy

Hello,

*At the last MOTU Meeting, plenty of healthy and constructive discussion occured regarding membership policy in MOTU Leadership Teams. However, it was determined that the issue did not yet have a concrete proposal for any sort of decision making process to move forward with. I have developed the following summary of the different proposals based on the mailing list archives, IRC chat logs, and a summary that Stefan Potrya prepared.

*
*Currently, the MOTU community feels that it is beneficial to delegate certain responsibilities and permissions to a subset of trusted individuals; for example the MOTU Release Team and Universe Stable Release Update Team. Since these bodies represent and act on behalf of MOTU-at-large, it is argued that for these leadership teams to be legitimate that they must accurately reflect the MOTU via an electoral process. Others feel alternative solutions would instead be optimal. Regardless, over the last few releases, the methodology used to populate these teams has been inconsistent. It is desired that a standard practice/policy be adopted.

*
*Initial discussion on this topic in June began with modifying the electoral system we've used in the past (voters vote yes or no for candidates and candidates who have the highest net count would be appointed OR candidates would have to achieve a certain percentage of approval). Strong consensus was reached on all major points except for the actual voting system to be used.

*
** Terms will be in the length of two release cycles which will usually work out to be roughly 12 months.
** Individuals interested in serving on a team will nominate themselves by e-mailing their intentions to ubuntu-motu. The MOTU Council will make a call for nominations 15 days before polls open.

** To allow for new individuals to get involved in the leadership teams and to ensure minimal disruption between terms, only a subset of the team will be up for re-election at the end of each release cycle. This will either be accomplished by holding a second election on the second release this policy is adopted or by designating certain members of first election to serve an extra release cycle.

** If a member if not able to complete their term, they will be able to resign and the runner up in the election will be appointed to serve the remainder of the term. If a runner up is not available, the team may choice to optionally replace the resigning member with an appointment of their choice. If the latter occurs, any MOTU may veto the appointment by filing grievance with the MOTU Council whom will allow the team to either leave the position vacant or call a by-election.

** Normal elections will start at an agreed date relative to a development milestone and polls will remain open until a second agreed date that is also relative to a development milestone. Once polls close, results will become available and a short period to allow for grievances and/or disputes to occur takes place. Finally, a third agreed date, which will also be relative to a development milestone, will mark the normal conclusion with the MOTU council officially announcing results and updating team memberships. If a grievance of dispute arises, the MOTU council will resolve the issue in 15 days of the third date or escalate the issue to the technical board.


*Although a voting system has not been agreed upon yet, two systems which have received a lot of discussion include Single Transferable Vote (used by some governments) and the Schulze method (used by Debian and Wikipedia among others). It is generally agreed that a preferential voting system, where voters would rank their preference of the candidates instead of voting for or against, is best.

*
*An alternative proposal by Emmet Hickory would have members be attached to a "release" and favors replacing team members through a process more
closely related to apprenticeship than any sort of election. The team would define goals for a release, handle freeze exceptions for the release, and then follow the release as the SRU team until the release is no longer supported (all together, roughly terms of 2 years). His full e-mail can be found here: https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.


*1. Do we still agree with the items in the list above or do you prefer Emmet's proposal?
*2. If yes, what voting system should we use? If no, we should work on elaborating Emmet's proposal.
*3. If you're not sure what voting system we should use, you might pick the one you best understand.

*
Cheers,

--
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112
Cell: 506-449-5899

Email: cody@redcow.ca
http://www.redcow.ca

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-17-2008, 01:09 PM
Neal McBurnett
 
Default MOTU Leadership Teams - Membership Policy

On Thu, Jul 17, 2008 at 08:20:36AM -0300, Cody A.W. Somerville wrote:
> * Normal elections will start at an agreed date relative to a development
> milestone and polls will remain open until a second agreed date that is also
> relative to a development milestone. Once polls close, results will become
> available and a short period to allow for grievances and/or disputes to occur
> takes place. Finally, a third agreed date, which will also be relative to a
> development milestone, will mark the normal conclusion with the MOTU council
> officially announcing results and updating team memberships. If a grievance of
> dispute arises, the MOTU council will resolve the issue in 15 days of the third
> date or escalate the issue to the technical board.
>
> Although a voting system has not been agreed upon yet, two systems which have
> received a lot of discussion include Single Transferable Vote (used by some
> governments) and the Schulze method (used by Debian and Wikipedia among
> others). It is generally agreed that a preferential voting system, where voters
> would rank their preference of the candidates instead of voting for or against,
> is best.

I've been active in voting method discussions for a few decades now.
If we go with elections, my advice is to go with either Approval
Voting or Range Voting. One benefit of them is the focus on
"supporting" folks (rather than a competition among folks), which can
contribute to a feeling of consensus.

http://en.wikipedia.org/wiki/Approval_voting
http://bcn.boulder.co.us/government/approvalvote/center.html
http://en.wikipedia.org/wiki/Range_voting

I'm not sure why STV is on the list since it is for party voting - do
we have parties in MOTU now? I mean besides the great festive
gatherings that Daniel organizes? ;-)

The ranked methods like IRV (and STV) and Schulze suffer from
increased complexity and confusion, and the risk of counter-intuitive
results. E.g. with IRV it is possible that raising the rank of a
winning candidate on some ballots, which originally had ranked that
candidate last, could counter-intuitively result in the winning
candidate becoming a loser. See

http://en.wikipedia.org/wiki/Instant-runoff_voting
http://en.wikipedia.org/wiki/Schulze_method
http://en.wikipedia.org/wiki/Single_transferable_vote

> An alternative proposal by Emmet Hickory would have members be attached to a
> "release" and favors replacing team members through a process more
> closely related to apprenticeship than any sort of election. The team would
> define goals for a release, handle freeze exceptions for the release, and then
> follow the release as the SRU team until the release is no longer supported
> (all together, roughly terms of 2 years). His full e-mail can be found here:
> https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.

Make that https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.html

Neal McBurnett http://mcburnett.org/neal/

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-18-2008, 02:23 AM
"Cody A.W. Somerville"
 
Default MOTU Leadership Teams - Membership Policy

On Thu, Jul 17, 2008 at 10:09 AM, Neal McBurnett <neal@bcn.boulder.co.us> wrote:



On Thu, Jul 17, 2008 at 08:20:36AM -0300, Cody A.W. Somerville wrote:

> ** Normal elections will start at an agreed date relative to a development

> milestone and polls will remain open until a second agreed date that is also

> relative to a development milestone. Once polls close, results will become

> available and a short period to allow for grievances and/or disputes to occur

> takes place. Finally, a third agreed date, which will also be relative to a

> development milestone, will mark the normal conclusion with the MOTU council

> officially announcing results and updating team memberships. If a grievance of

> dispute arises, the MOTU council will resolve the issue in 15 days of the third

> date or escalate the issue to the technical board.

>

> *Although a voting system has not been agreed upon yet, two systems which have

> received a lot of discussion include Single Transferable Vote (used by some

> governments) and the Schulze method (used by Debian and Wikipedia among

> others). It is generally agreed that a preferential voting system, where voters

> would rank their preference of the candidates instead of voting for or against,

> is best.



I've been active in voting method discussions for a few decades now.

If we go with elections, my advice is to go with either Approval

Voting or Range Voting. *One benefit of them is the focus on

"supporting" folks (rather than a competition among folks), which can

contribute to a feeling of consensus.



*http://en.wikipedia.org/wiki/Approval_voting

*http://bcn.boulder.co.us/government/approvalvote/center.html

*http://en.wikipedia.org/wiki/Range_voting




I don't know if I agree with that. The reason why I feel a preferential system, in particular STV, is a good fit for us is because you never vote against someone like you would in approval voting (by not voting) - you simply express your preference of one candidate over another. I feel this is mandatory because it should be a requirement to becoming a MOTU that you *could* be able to fill these roles. As for range voting, that is a plausible idea but both range voting and approval voting are classed as single seat (ie. used to elect single individual) system whereas STV is a multi-member system.


*I'm not sure why STV is on the list since it is for party voting - do

we have parties in MOTU now? *I mean besides the great festive

gatherings that Daniel organizes? *;-)
Single Transferable Vote is *not* for party voting. Infact, it *explicitly* ensures votes are for candidates and not parties. STV is on the list because is a preferential voting system designed to minimize wasted votes and provide proportional representation.



*



The ranked methods like IRV (and STV) and Schulze suffer from

increased complexity and confusion, and the risk of counter-intuitive

results. *E.g. with IRV it is possible that raising the rank of a

winning candidate on some ballots, which originally had ranked that

candidate last, could counter-intuitively result in the winning

candidate becoming a loser. *See



*http://en.wikipedia.org/wiki/Instant-runoff_voting

*http://en.wikipedia.org/wiki/Schulze_method

*http://en.wikipedia.org/wiki/Single_transferable_vote
Yes, this is called the monotonicity criterion. IRV and STV both fail this criterion but Schulze method does not. However, I don't think we need to get caught up in weird corner cases due to the scale and nature of the elections we'll be holding.


*



> *An alternative proposal by Emmet Hickory would have members be attached to a

> "release" and favors replacing team members through a process more

> closely related to apprenticeship than any sort of election. The team would

> define goals for a release, handle freeze exceptions for the release, and then

> follow the release as the SRU team until the release is no longer supported

> (all together, roughly terms of 2 years). His full e-mail can be found here:

> https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.



Make that *https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.html



Neal McBurnett * * * * * * * * http://mcburnett.org/neal/



--

Ubuntu-motu mailing list

Ubuntu-motu@lists.ubuntu.com

Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu



--
Cody A.W. Somerville
Software Engineer
Red Cow Marketing & Technologies, Inc.
Office: 506-458-1290
Toll Free: 1-877-733-2699
Fax: 506-453-9112



Cell: 506-449-5899
Email: cody@redcow.ca
http://www.redcow.ca

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-18-2008, 06:58 AM
Luca Falavigna
 
Default MOTU Leadership Teams - Membership Policy

Cody A.W. Somerville ha scritto:
* To allow for new individuals to get involved in the leadership teams
and to ensure minimal disruption between terms, only a subset of the
team will be up for re-election at the end of each release cycle. This
will either be accomplished by holding a second election on the second
release this policy is adopted or by designating certain members of
first election to serve an extra release cycle.


Having new blood in key teams is important, but what if no volunteers
are available? Current members need to play the role again. Attracting
more people is the key here IMHO, members should be able to generate
interest, this can be achieved by preparing regular reports (e.g.
https://wiki.ubuntu.com/TeamReports), this can provide guidance to
prospective members too.


An alternative proposal by Emmet Hickory would have members be attached
to a "release" and favors replacing team members through a process more
closely related to apprenticeship than any sort of election. The team
would define goals for a release, handle freeze exceptions for the
release, and then follow the release as the SRU team until the release
is no longer supported (all together, roughly terms of 2 years). His
full e-mail can be found here:
https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.


I think this proposal won't fit well. Developers usually have
development branch installed. Being able to review, sponsor and
eventually test updates for stable releases can be hard if people lack
hardware/VMs when doing SRUs.
Also, it can be hard to approve SRUs targeted for two or more stable
releases: bugs must receive ACK from two different groups (one by people
for Ubuntu X.xx and one by people for Ubuntu Y.yy).
Knowledge of release goals is important, but given that regression
potential must be low anyway, I think there is no need to be fully aware
of release goals while doing SRUs, they should have been completed
before release or targeted for the next release.


Regards,

--
. '`. Luca Falavigna
: :' : Ubuntu MOTU Developer
`. `'` Debian Maintainer
`- GPG Key: 0x86BC2A50

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-25-2008, 09:30 PM
"Emmet Hikory"
 
Default MOTU Leadership Teams - Membership Policy

Cody A.W. Somerville wrote:
> Currently, the MOTU community feels that it is beneficial to delegate
> certain responsibilities and permissions to a subset of trusted individuals;
> for example the MOTU Release Team and Universe Stable Release Update Team.
> Since these bodies represent and act on behalf of MOTU-at-large, it is
> argued that for these leadership teams to be legitimate that they must
> accurately reflect the MOTU via an electoral process. Others feel
> alternative solutions would instead be optimal. Regardless, over the last
> few releases, the methodology used to populate these teams has been
> inconsistent. It is desired that a standard practice/policy be adopted.

This topic was again discussed at the 25th July MOTU Meeting.
Please find below a summary of one of the proposed mechanisms by which
team members might be selected.

For each of the MOTU-SRU and MOTU Release teams, a maximum size (e.g.
5 or 7) is selected. Note that the selected time values are
arbitrary, and may be adjusted if required.

Any MOTU with interest in joining a key team may apply to me a member
of that team by sending mail to ubuntu-motu@lists.ubuntu.com
indicating their desire to join the team, and outlining their
qualifications to be on the team.

This is followed by a discussion period of one week where any MOTU is
able to ask questions about the application. If during this period,
any MOTU strongly disagrees that the candidate is qualified to join
the team, the candidate is rejected, and must wait at least two months
to reapply.

If the acceptance of a candidate would push the team oversize, a
multicandidate election is held, with a number of winners equal to the
maximum size of the team selected from the current members and any new
applications. This election may be delayed if there are multiple open
applications at one time (apologies to those who may have to wait to
join a team in this instance).

Any current member may resign at any time, if they are no longer
active in the team. Any MOTU may call for resignation of a team
member if they are perceived as inactive or unsuitable in some way.
In the case where a resignation is requested, there is a two week
period of discussion. If the request has not been withdrawn and the
member has not resigned at the end of the discussion period, the issue
will be resolved by MOTU Council using the dispute resolution process.

Please note that if this model is selected, there will be a need
to determine a voting system to handle the case where there are too
many applicants.

--
Emmet HIKORY

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-25-2008, 11:14 PM
Scott Kitterman
 
Default MOTU Leadership Teams - Membership Policy

On Friday 25 July 2008 17:30, Emmet Hikory wrote:
> Cody A.W. Somerville wrote:
> > Currently, the MOTU community feels that it is beneficial to delegate
> > certain responsibilities and permissions to a subset of trusted
> > individuals; for example the MOTU Release Team and Universe Stable
> > Release Update Team. Since these bodies represent and act on behalf of
> > MOTU-at-large, it is argued that for these leadership teams to be
> > legitimate that they must accurately reflect the MOTU via an electoral
> > process. Others feel alternative solutions would instead be optimal.
> > Regardless, over the last few releases, the methodology used to populate
> > these teams has been inconsistent. It is desired that a standard
> > practice/policy be adopted.
>
> This topic was again discussed at the 25th July MOTU Meeting.
> Please find below a summary of one of the proposed mechanisms by which
> team members might be selected.
>
> For each of the MOTU-SRU and MOTU Release teams, a maximum size (e.g.
> 5 or 7) is selected. Note that the selected time values are
> arbitrary, and may be adjusted if required.
>
> Any MOTU with interest in joining a key team may apply to me a member
> of that team by sending mail to ubuntu-motu@lists.ubuntu.com
> indicating their desire to join the team, and outlining their
> qualifications to be on the team.
>
> This is followed by a discussion period of one week where any MOTU is
> able to ask questions about the application. If during this period,
> any MOTU strongly disagrees that the candidate is qualified to join
> the team, the candidate is rejected, and must wait at least two months
> to reapply.
>
> If the acceptance of a candidate would push the team oversize, a
> multicandidate election is held, with a number of winners equal to the
> maximum size of the team selected from the current members and any new
> applications. This election may be delayed if there are multiple open
> applications at one time (apologies to those who may have to wait to
> join a team in this instance).
>
> Any current member may resign at any time, if they are no longer
> active in the team. Any MOTU may call for resignation of a team
> member if they are perceived as inactive or unsuitable in some way.
> In the case where a resignation is requested, there is a two week
> period of discussion. If the request has not been withdrawn and the
> member has not resigned at the end of the discussion period, the issue
> will be resolved by MOTU Council using the dispute resolution process.
>
> Please note that if this model is selected, there will be a need
> to determine a voting system to handle the case where there are too
> many applicants.
>
I think this is an interesting approach. A few questions:

Is there a maximum term before one must stand for election again or is it
until one quits/some MOTU asks to have you out?

Is there some minimum before one can re-apply if one is not accepted (I see
DoS potential in the approach without such a rule)?

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-25-2008, 11:26 PM
"Nathan Handler"
 
Default MOTU Leadership Teams - Membership Policy

On Fri, Jul 25, 2008 at 6:14 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
> Is there some minimum before one can re-apply if one is not accepted (I see
> DoS potential in the approach without such a rule)?

Scott,

"If during this period, any MOTU strongly disagrees that the candidate
is qualified to join
the team, the candidate is rejected, and must wait at least two months
to reapply."

So to answer your question, the minimum is 2 months.

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-25-2008, 11:50 PM
Scott Kitterman
 
Default MOTU Leadership Teams - Membership Policy

On Fri, 25 Jul 2008 18:26:03 -0500 "Nathan Handler"
<nathan.handler@gmail.com> wrote:
>On Fri, Jul 25, 2008 at 6:14 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
>> Is there some minimum before one can re-apply if one is not accepted (I
see
>> DoS potential in the approach without such a rule)?
>
>Scott,
>
>"If during this period, any MOTU strongly disagrees that the candidate
>is qualified to join
>the team, the candidate is rejected, and must wait at least two months
>to reapply."
>
>So to answer your question, the minimum is 2 months.

Right. Missed that. Thanks.

Scott K

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-26-2008, 12:30 AM
Stefan Potyra
 
Default MOTU Leadership Teams - Membership Policy

Hi,

as I've been quite puzzled by the mail in the first place, I'd thought I make
it a little bit more clear what was discussed during the meeting and what was
Emmet's action to take after the meeting (i.e. to write a proposal).

On Friday 25 July 2008 23:30:00 Emmet Hikory wrote:
> Cody A.W. Somerville wrote:
> > Currently, the MOTU community feels that it is beneficial to delegate
> > certain responsibilities and permissions to a subset of trusted
> > individuals; for example the MOTU Release Team and Universe Stable
> > Release Update Team. Since these bodies represent and act on behalf of
> > MOTU-at-large, it is argued that for these leadership teams to be
> > legitimate that they must accurately reflect the MOTU via an electoral
> > process. Others feel alternative solutions would instead be optimal.
> > Regardless, over the last few releases, the methodology used to populate
> > these teams has been inconsistent. It is desired that a standard
> > practice/policy be adopted.
>
> This topic was again discussed at the 25th July MOTU Meeting.
> Please find below a summary of one of the proposed mechanisms by which
> team members might be selected.

To clear up: below is Emmet's proposal:

>
> For each of the MOTU-SRU and MOTU Release teams, a maximum size (e.g.
> 5 or 7) is selected. Note that the selected time values are
> arbitrary, and may be adjusted if required.
>
> Any MOTU with interest in joining a key team may apply to me a member
> of that team by sending mail to ubuntu-motu@lists.ubuntu.com
> indicating their desire to join the team, and outlining their
> qualifications to be on the team.
>
> This is followed by a discussion period of one week where any MOTU is
> able to ask questions about the application. If during this period,
> any MOTU strongly disagrees that the candidate is qualified to join
> the team, the candidate is rejected, and must wait at least two months
> to reapply.
>
> If the acceptance of a candidate would push the team oversize, a
> multicandidate election is held, with a number of winners equal to the
> maximum size of the team selected from the current members and any new
> applications. This election may be delayed if there are multiple open
> applications at one time (apologies to those who may have to wait to
> join a team in this instance).
>
> Any current member may resign at any time, if they are no longer
> active in the team. Any MOTU may call for resignation of a team
> member if they are perceived as inactive or unsuitable in some way.
> In the case where a resignation is requested, there is a two week
> period of discussion. If the request has not been withdrawn and the
> member has not resigned at the end of the discussion period, the issue
> will be resolved by MOTU Council using the dispute resolution process.
>
> Please note that if this model is selected, there will be a need
> to determine a voting system to handle the case where there are too
> many applicants.
>
> --
> Emmet HIKORY

Cheers,
Stefan.


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-26-2008, 01:48 AM
Luca Falavigna
 
Default MOTU Leadership Teams - Membership Policy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Emmet Hikory ha scritto:
> This is followed by a discussion period of one week where any MOTU is
> able to ask questions about the application. If during this period,
> any MOTU strongly disagrees that the candidate is qualified to join
> the team, the candidate is rejected, and must wait at least two months
> to reapply.

If I understand this rigth, a single MOTU can veto a candidate.
Shouldn't this be granted only if several MOTUs disagree with the
application? Having a single person blocking a election can lead to
deadlocks: if I'm against a given candidate, he/she won't be able to be
elected as long as I oppose to it.
I think this will never happen in real world, though.

Regards,

- --
. '`. Luca Falavigna
: :' : Ubuntu MOTU Developer
`. `'` Debian Maintainer
`- GPG Key: 0x86BC2A50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIioKAnXjXEYa8KlARApmCAJ9vMHkNwDJyArJvSzV04h qSeJWk7ACfViY/
/zzRCE1q7k0N9QcL6CLQaxI=
=0Ymx
-----END PGP SIGNATURE-----

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 

Thread Tools




All times are GMT. The time now is 01:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org