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 > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 01-04-2012, 04:21 AM
Michael Stahnke
 
Default Plans for EL4 End of Life

So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).*

What are the plans for EPEL 4?*

The way I see we have a few options:


1.* We stop putting new content in EPEL4 and take down the EPEL mirror (thus really end-of-lifeing EPEL 4)
2.* We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates

3.* We keep allow people to add content to EPEL4 due to things like extended support
4.* Some other option I haven't though about yet.


I like 1 the best, because it only helps enforce lifecycle planning.* And when I worked in big enterprise, I needed all the help I could get to be able to move systems.* * Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.




Any discussion or suggestions welcome.


[1] https://access.redhat.com/support/policy/updates/errata/

stahnma




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 05:46 AM
Toshio Kuratomi
 
Default Plans for EL4 End of Life

On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke wrote:
> So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and
> thus triggering CentOS, and I imagine Oracle, Scientific et al).
>
> What are the plans for EPEL 4?
>
> The way I see we have a few options:
>
> 1. We stop putting new content in EPEL4 and take down the EPEL mirror (thus
> really end-of-lifeing EPEL 4)
> 2. We stop putting in new content, and leave the mirrors, thus allowing those
> who haven't migrated to ahve some sort of package options, with no option for
> updates
> 3. We keep allow people to add content to EPEL4 due to things like extended
> support
> 4. Some other option I haven't though about yet.
>
Kind of a hybrid between 1) and 2) => Stop putting new content into EPEL4.
Move current EPEL4 repositories to archives.fedoraproject.org. This shows
that we're EOLing support for EPEL4 and also allows mirrors to opt out of
carrying it but still lets people who are desperate to keep their
RHEL/Centos4 boxes running a chance to benefit from the software that we
built.

OTOH, I may be being selfish -- in Fedora Infrastructure we've long since
moved away from RHEL4 (we're 3/4 of the way through migratin from RHEL5 to
RHEL6 as well). I have a python module that's needed for running fedpkg on
top of RHEL4 and if we drop EPEL4, I don't have to support that (and the
python-2.3 compatibility that it entails) anymore.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 08:35 AM
Karel Volný
 
Default Plans for EL4 End of Life

Dne Út 3. ledna 2012 22:46:41, Toshio Kuratomi napsal(a):
> On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke
wrote:
> > So, we have about 60 days until EL4 goes to End of Life
> > from Red Hat[1] (and thus triggering CentOS, and I imagine
> > Oracle, Scientific et al).
> >
> > What are the plans for EPEL 4?
> >
> > The way I see we have a few options:
> >
> > 1. We stop putting new content in EPEL4 and take down the
> > EPEL mirror (thus really end-of-lifeing EPEL 4)
> > 2. We stop putting in new content, and leave the mirrors,
> > thus allowing those who haven't migrated to ahve some sort
> > of package options, with no option for updates
> > 3. We keep allow people to add content to EPEL4 due to
> > things like extended support
> > 4. Some other option I haven't though about yet.
> >
> > I like 1 the best, because it only helps enforce lifecycle
> > planning.

planning is a nice thing, but ... what if you are stuck with some
hardware that works with the old software only, for example?

> > And when I worked in big enterprise, I needed all
> > the help I could get to be able to move systems.

was it big enough to create its own software support team (I do
not mean helpdesk but real developers) because it was way cheaper
than to adapt to vendor's lifecycles?
- why do you think that Red Hat created the EUS option?

> > Plus it allows our maintainers to focus effort on 5/6
> > enhancements and fixes.

see below

> Kind of a hybrid between 1) and 2) => Stop putting new content
> into EPEL4. Move current EPEL4 repositories to
> archives.fedoraproject.org. This shows that we're EOLing
> support for EPEL4 and also allows mirrors to opt out of
> carrying it but still lets people who are desperate to keep
> their RHEL/Centos4 boxes running a chance to benefit from the
> software that we built.
>
> OTOH, I may be being selfish -- in Fedora Infrastructure we've
> long since moved away from RHEL4 (we're 3/4 of the way through
> migratin from RHEL5 to RHEL6 as well). I have a python module
> that's needed for running fedpkg on top of RHEL4 and if we
> drop EPEL4, I don't have to support that (and the python-2.3
> compatibility that it entails) anymore.

and if we do not drop EPEL4, what forces you to support the
module?

- I thought we are talking about volunteer project ...

I'd prefer 3 - depending on what is meant by "adding content":
bugfixes? - yes, if there's someone willing to take care
new packages? - no, unless someone is really desperate (then he
can create his own repo, for sure, but why not to allow him to
use the existing EPEL infrastructure, are we short on hardware
resources?)

K.

--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol@jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."_______________________________________ ________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 08:55 AM
Manuel Wolfshant
 
Default Plans for EL4 End of Life

On 01/04/2012 07:21 AM, Michael Stahnke wrote:
So, we have about 60 days until EL4 goes to End of Life from Red
Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific
et al).


What are the plans for EPEL 4?

The way I see we have a few options:

1. We stop putting new content in EPEL4 and take down the EPEL mirror
(thus really end-of-lifeing EPEL 4)
2. We stop putting in new content, and leave the mirrors, thus
allowing those who haven't migrated to ahve some sort of package
options, with no option for updates
3. We keep allow people to add content to EPEL4 due to things like
extended support

4. Some other option I haven't though about yet.

I am for a combination of 2 and 3. I am 100% sure that even after RHEL4
goes end of life, many functional systems that are now running on RHEL4
will be preserved, even if there would be no new deployments. I see no
reason to force them to stop using EPEL[*].
OTOH I do agree with Toshi's idea to migrate the repository to
archives.f.o and allowing the public mirrors to opt-out.




I like 1 the best, because it only helps enforce lifecycle planning.
And when I worked in big enterprise, I needed all the help I could get
to be able to move systems.
Help as in "look, I want you to migrate, here is an argument you can use
to convince your management and all the people who provide software for
you: I'll cut access to the optional packages that you might wish to use" ??



Plus it allows our maintainers to focus effort on 5/6 enhancements
and fixes.

I'd say it is up to maintainers to decide.
FWIW, I know of an idiotic ( and niche ) medical application which still
relies on Sybase 7 and the developers blindly refuse to support it on
anything but RHEL 4. Or Windows (where they do use Sybase 9...). And no,
I could not persuade the users of that application to ditch the
application and use something decent and written in this century.


[*] assuming they do use it, of course

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 03:09 PM
Michael Stahnke
 
Default Plans for EL4 End of Life

2012/1/4 Karel Volný <kvolny@redhat.com>

Dne Út 3. ledna 2012 22:46:41, Toshio Kuratomi napsal(a):

> On Tue, Jan 03, 2012 at 09:21:31PM -0800, Michael Stahnke

wrote:

> > So, we have about 60 days until EL4 goes to End of Life

> > from Red Hat[1] (and thus triggering CentOS, and I imagine

> > Oracle, Scientific et al).

> >

> > What are the plans for EPEL 4?

> >

> > The way I see we have a few options:

> >

> > 1. *We stop putting new content in EPEL4 and take down the

> > EPEL mirror (thus really end-of-lifeing EPEL 4)

> > 2. *We stop putting in new content, and leave the mirrors,

> > thus allowing those who haven't migrated to ahve some sort

> > of package options, with no option for updates

> > 3. *We keep allow people to add content to EPEL4 due to

> > things like extended support

> > 4. *Some other option I haven't though about yet.

> >

> > I like 1 the best, because it only helps enforce lifecycle

> > planning.



planning is a nice thing, but ... what if you are stuck with some

hardware that works with the old software only, for example?

Well the hardware that won't run something newer is probably approaching 10 years old at this point.* It's probably time for an upgrade, or virtualization.




> > And when I worked in big enterprise, I needed all

> > the help I could get to be able to move systems. *



was it big enough to create its own software support team (I do

not mean helpdesk but real developers) because it was way cheaper

than to adapt to vendor's lifecycles?
Yes it was large enough, but that wasn't a good option.* Moving on a planned schedule, though difficult is often the cheapest and best solution.*


- why do you think that Red Hat created the EUS option?
Because people can't write software that doesn't break API/ABI, and to penalize them for that, Red Hat can charge more? * We had 4,000 RHEL systems and never bought that once.

*



> > Plus it allows our maintainers to focus effort on 5/6

> > enhancements and fixes.



see below



> Kind of a hybrid between 1) and 2) => Stop putting new content

> into EPEL4. Move current EPEL4 repositories to

> archives.fedoraproject.org. *This shows that we're EOLing

> support for EPEL4 and also allows mirrors to opt out of

> carrying it but still lets people who are desperate to keep

> their RHEL/Centos4 boxes running a chance to benefit from the

> software that we built.

>

> OTOH, I may be being selfish -- in Fedora Infrastructure we've

> long since moved away from RHEL4 (we're 3/4 of the way through

> migratin from RHEL5 to RHEL6 as well). *I have a python module

> that's needed for running fedpkg on top of RHEL4 and if we

> drop EPEL4, I don't have to support that (and the python-2.3

> compatibility that it entails) anymore.



and if we do not drop EPEL4, what forces you to support the

module?

When you put something into EPEL, you are more-or-less agreeing to attempt to support it throughout the life of the operating systems EPEL is tracking.* If we stop tracking EPEL4, people who have been trying to keep compatibility with E4, and back port fixes, etc will get a significant amount of time (in some cases) back.***




- I thought we are talking about volunteer project ...


It is.* It's also primarily in use by business customers this is why planning and communication is key.

*


I'd prefer 3 - depending on what is meant by "adding content":

bugfixes? - yes, if there's someone willing to take care

new packages? - no, unless someone is really desperate (then he

can create his own repo, for sure, but why not to allow him to

use the existing EPEL infrastructure, are we short on hardware

resources?)



K.



--

Karel Volný

QE BaseOs/Daemons Team

Red Hat Czech, Brno

tel. +420 532294274

(RH: +420 532294111 ext. 8262074)

xmpp kavol@jabber.cz

:: "Never attribute to malice what can

:: *easily be explained by stupidity."
_______________________________________________

epel-devel-list mailing list

epel-devel-list@redhat.com

https://www.redhat.com/mailman/listinfo/epel-devel-list




_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 03:10 PM
Michael Stahnke
 
Default Plans for EL4 End of Life

On Wed, Jan 4, 2012 at 1:55 AM, Manuel Wolfshant <wolfy@nobugconsulting.ro> wrote:

On 01/04/2012 07:21 AM, Michael Stahnke wrote:


So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and thus triggering CentOS, and I imagine Oracle, Scientific et al).



What are the plans for EPEL 4?



The way I see we have a few options:



1. *We stop putting new content in EPEL4 and take down the EPEL mirror (thus really end-of-lifeing EPEL 4)

2. *We stop putting in new content, and leave the mirrors, thus allowing those who haven't migrated to ahve some sort of package options, with no option for updates

3. *We keep allow people to add content to EPEL4 due to things like extended support

4. *Some other option I haven't though about yet.




I am for a combination of 2 and 3. I am 100% sure that even after RHEL4 goes end of life, many functional systems that are now running on RHEL4 will be preserved, even if there would be no new deployments. I see no reason to force them to stop using EPEL[*].


OTOH I do agree with Toshi's idea to migrate the repository to archives.f.o and allowing the public mirrors to opt-out.
I like the archives proposal as well.*








I like 1 the best, because it only helps enforce lifecycle planning. *And when I worked in big enterprise, I needed all the help I could get to be able to move systems. *


Help as in "look, I want you to migrate, here is an argument you can use to convince your management and all the people who provide software for you: I'll cut access to the optional packages that you might wish to use" ??

It would just be another data point.* We tried to plan our life cycles of technologies as the OS went into the data center.*








*Plus it allows our maintainers to focus effort on 5/6 enhancements and fixes.


I'd say it is up to maintainers to decide.

FWIW, I know of an idiotic ( and niche ) medical application which still relies on Sybase 7 and the developers blindly refuse to support it on anything but RHEL 4. Or Windows (where they do use Sybase 9...). And no, I could not persuade the users of that application to ditch the application and use something decent and written in this century.





[*] assuming they do use it, of course



_______________________________________________

epel-devel-list mailing list

epel-devel-list@redhat.com

https://www.redhat.com/mailman/listinfo/epel-devel-list



_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 05:35 PM
Stephen John Smoogen
 
Default Plans for EL4 End of Life

On 3 January 2012 22:21, Michael Stahnke <mastahnke@gmail.com> wrote:
> So, we have about 60 days until EL4 goes to End of Life from Red Hat[1] (and
> thus triggering CentOS, and I imagine Oracle, Scientific et al).
>
> What are the plans for EPEL 4?
>
> The way I see we have a few options:
>
> 1.Â* We stop putting new content in EPEL4 and take down the EPEL mirror (thus
> really end-of-lifeing EPEL 4)
> 2.Â* We stop putting in new content, and leave the mirrors, thus allowing
> those who haven't migrated to ahve some sort of package options, with no
> option for updates
> 3.Â* We keep allow people to add content to EPEL4 due to things like extended
> support
> 4.Â* Some other option I haven't though about yet.
>
>
> I like 1 the best, because it only helps enforce lifecycle planning.Â* And
> when I worked in big enterprise, I needed all the help I could get to be
> able to move systems.Â* Â* Plus it allows our maintainers to focus effort on
> 5/6 enhancements and fixes.
>
>
>
> Any discussion or suggestions welcome.
>

I would like to "vote" for option 1 with an updated epel-4 release
that points to archives location. The reason is the following:

1) The Builders will not have access to EUS and so will effectively be
building at 4.9 forever.
2) Building stuff for EL-4 is becoming harder and harder and extending
the lifetime that maintainers who signed up to EOL is now 4 years
longer. That means either removing stuff from EPEL or finding another
maintainer (effectively doing the same).




--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." Â*—James Stewart as Elwood P. Dowd

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-04-2012, 05:39 PM
Kevin Fenzi
 
Default Plans for EL4 End of Life

On Tue, 3 Jan 2012 22:46:41 -0800
Toshio Kuratomi <a.badger@gmail.com> wrote:

> Kind of a hybrid between 1) and 2) => Stop putting new content into
> EPEL4. Move current EPEL4 repositories to
> archives.fedoraproject.org. This shows that we're EOLing support for
> EPEL4 and also allows mirrors to opt out of carrying it but still
> lets people who are desperate to keep their RHEL/Centos4 boxes
> running a chance to benefit from the software that we built.

I like this plan.

kevin
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-05-2012, 11:33 AM
Karel Volný
 
Default Plans for EL4 End of Life

Dne St 4. ledna 2012 08:09:31, Michael Stahnke napsal(a):
> > planning is a nice thing, but ... what if you are stuck
> > with some hardware that works with the old software only,
> > for example?
> Well the hardware that won't run something newer is probably
> approaching 10 years old at this point. It's probably time
> for an upgrade, or virtualization.

LOL, I got a bit amused trying to imagine how are you
virtualizing a large scale CNC machine ... :-)

well, I have no clue what are the real usages of RHEL4+EPEL

but I just don't like the attitude

it has bitten me just a few weeks ago - why should I buy a new
printer when the twelve years old one is in perfect shape, it
provides a good quality, and the price per page ratio is the
lowest in its class?

I'd rather pay the price of the new printer to someone to fix the
driver to work with new kernel than to throw away the old one,
trashing the Earth with another piece of waste

> > > > And when I worked in big enterprise, I needed all
> > > > the help I could get to be able to move systems.
> > > >
> >
> > was it big enough to create its own software support team
> > (I do not mean helpdesk but real developers) because it
> > was way cheaper than to adapt to vendor's lifecycles?
>
> Yes it was large enough, but that wasn't a good option. Moving
> on a planned schedule, though difficult is often the cheapest
> and best solution.

now you say "is often" - and what about the rest of cases (e.g.
my experience is different, or the managers in my previous
company just couldn't do the math ...)?

will supporting them negatively affect the majority? - I don't
think so

will supporting them cost us more than it would cost them if we
dropped the support? - don't know ... but as we are talking about
moving things to archive, i.e. eating the same disk space, just
under another directory, I doubt our costs would be significant
in comparison

...
> > and if we do not drop EPEL4, what forces you to support the
> > module?
>
> When you put something into EPEL, you are more-or-less agreeing
> to attempt to support it throughout the life of the operating
> systems EPEL is tracking. If we stop tracking EPEL4, people
> who have been trying to keep compatibility with E4, and back
> port fixes, etc will get a significant amount of time (in some
> cases) back.

this does not answer my question

okay, you "agreed to attempt" - now what?

> > - I thought we are talking about volunteer project ...
> >
> It is. It's also primarily in use by business customers this
> is why planning and communication is key.

so, wouldn't it be better to communicate with these customers and
present some resume rather then push everyone's selfish agenda on
this list?

K.

--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol@jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."_______________________________________ ________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-05-2012, 04:32 PM
Toshio Kuratomi
 
Default Plans for EL4 End of Life

On Thu, Jan 05, 2012 at 01:33:31PM +0100, Karel Volný wrote:
>
> but I just don't like the attitude
>
> it has bitten me just a few weeks ago - why should I buy a new
> printer when the twelve years old one is in perfect shape, it
> provides a good quality, and the price per page ratio is the
> lowest in its class?
>
> I'd rather pay the price of the new printer to someone to fix the
> driver to work with new kernel than to throw away the old one,
> trashing the Earth with another piece of waste
>
There's two differences that I can see:

* We're only talking about throwing away support here. If people can still
get the old packages on archives.fp.o, we're really just saying that we
don't support the software anymore (with updates, handling of bug reports,
etc). The product is still available for those who want it.
* The product we're throwing out is software, not hardware. So there's no
physical waste when abandoning it.

> > > > > And when I worked in big enterprise, I needed all
> > > > > the help I could get to be able to move systems.
> > > > >
> > >
> > > was it big enough to create its own software support team
> > > (I do not mean helpdesk but real developers) because it
> > > was way cheaper than to adapt to vendor's lifecycles?
> >
> > Yes it was large enough, but that wasn't a good option. Moving
> > on a planned schedule, though difficult is often the cheapest
> > and best solution.
>
> now you say "is often" - and what about the rest of cases (e.g.
> my experience is different, or the managers in my previous
> company just couldn't do the math ...)?
>
> will supporting them negatively affect the majority? - I don't
> think so
>
> will supporting them cost us more than it would cost them if we
> dropped the support? - don't know ... but as we are talking about
> moving things to archive, i.e. eating the same disk space, just
> under another directory, I doubt our costs would be significant
> in comparison
>
The true cost is in manpower for whoever has to maintain the packages,
fix bugs, update software, etc. EPEL is based on the idea that it costs us
less to collectively package software than it does for individuals to
package the same software separately so in absolute numbers, you're probably
right that our costs are lower than theirs.

However, our manpower comes from volunteers who need to consider what
they're doing as fun whereas their manpower comes from paid employees who
need to be convinced that their employers are doing what's most beneficial
for the company. Maintaining software that doesn't run on any machines that
I have deployed and whose core software is so old is much less fun than
maintaining software for the latest releases. When you contrast this with
someone who is being paid to maintain a RHEL4 machine and needs the software
being packaged to run on that machine. I think the relative cost for us
becomes much higher.

Note that there are other options here. In Fedora, the decision was an "all
packages or no packages" approach. A group could work on a Fedora Legacy to
extend the EOL date only if they maintained all packages for a longer
period. In RHEL4 itself, it appears that Red Hat is going to select
a subset of packages that may receive updates. Other packages will not
(even if the package has a security flaw). I suppose that we could follow
that model if less than the whole set of EPEL contributors wanted to
continue on with EPEL4. However, doing this might mean that you also had to
allocate manpower to do rel-eng tasks related to building, signing, and
pushing updates; document which packages the EPEL4 group was willing to
continue maintainance on; pick up the slack on each others packages if
someone stops contributing to EPEL4; etc.

> ...
> > > and if we do not drop EPEL4, what forces you to support the
> > > module?
> >
> > When you put something into EPEL, you are more-or-less agreeing
> > to attempt to support it throughout the life of the operating
> > systems EPEL is tracking. If we stop tracking EPEL4, people
> > who have been trying to keep compatibility with E4, and back
> > port fixes, etc will get a significant amount of time (in some
> > cases) back.
>
> this does not answer my question
>
> okay, you "agreed to attempt" - now what?
>
I suppose the next question is how long did you/I/we "agree to attempt"?

I agreed to go until EOL; not to the end of extended life. But I don't see
that canonified on the EPEL wiki and policy pages... so it must have just
been what we talked about on the mailing lists back in 2006 and 2007.

> > > - I thought we are talking about volunteer project ...
> > >
> > It is. It's also primarily in use by business customers this
> > is why planning and communication is key.
>
> so, wouldn't it be better to communicate with these customers and
> present some resume rather then push everyone's selfish agenda on
> this list?
>
Well... what I see is that we're determining if there's manpower here to
support EPEL4 past EOL. If there isn't manpower, our message is "EPEL will
not be supporting RHEL4 after RHEL4's End of Production date, Feb 29, 2012."

If there is manpower, I suppose the message changes.

Since our users aren't paying us, figuring out what our non-contributing
user's needs are, while nice to know, is not very rewarding. The "selfish
agenda" that you speak of is much more important to this equation -- it's
the expression of whether we feel we're being paid enough to continue to do
the work that we do in EPEL4.

-Toshio
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 10:38 AM.

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