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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-14-2010, 04:19 PM
Thilo Bangert
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

Richard Freeman <rich0@gentoo.org> said:
> On 08/14/2010 10:29 AM, Markos Chandras wrote:
> > So do I. Fixing your package and you don't even bother to send a
> > *ready to go* patch upstream seems like a bit rude to me as well.
> > Perhaps, we do have a complete different point of view in this one.
> > Recent example is Ch*-Thanh Christopher Nguyễn who thanked me for
> > fixing his package, asked me to attach the patch so *he* can send it
> > upstream. I thought that was the *default* policy. Anyway. I should
> > talk to each maintainer separately when I fix his package. Seems to
> > me is the best approach
>
> My two cents. In my opinion, whether a commit is good or not depends
> on whether it left Gentoo as a whole in better or worse shape than
> before it was made.
>
> Here it sounds like we had QA problems before the commit, and no QA
> problems after the commit. Maybe the maintainer has some work to do
> now, but he had it to do anyway, and the maintainers have less work to
> do now than they did before the patches were made.
>
> Now, if he had broken something due to a sloppy commit I'd be more
> concerned.
>
> Many hands make for lighter work. The best way to have many hands is
> to make individual tasks easier. 1+1+1+1+1 is going to happen faster
> than 3+2, since nobody ever gets around to doing 3.
>
> If we give devs an ultimatum like "fix it all or don't fix anything"
> guess which one they'll pick?

exactly. maybe the maintainer has to do some catch up work, but thats ok.
the aim is to improve the tree and not for QA to do the work of the
maintainer.

perhaps there is a lesson here though: if the bug isnt closed as soon as
the patch has hit the tree, but its subject changed to 'push QA patch
upstream', then it is clear what is left to do.

>
> Rich
 
Old 08-14-2010, 04:26 PM
Thilo Bangert
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

> So you want me to force everyone to update the package just to respect
> the LDFLAGS.

yes. IIRC it has been stated on this list before, that a change which
changes the resulting binary always needs to be done in a revbump.

> Why, since until recently, nobody gave a crap about this
> kind of QA issues?

Thats a bad excuse!

>
> Please provide a patch for devmanual to make it more clear.

Good idea. Any takers?

thanks
kind regards

Thilo
 
Old 08-14-2010, 05:00 PM
Markos Chandras
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote:
> > On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote:
> > > On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
> > > > > - If you are not in cc of the gentoo bug nor in the herd alias, please cc
> > > > > yourself on the bug.
> > > > > - Please close the bugs, even the dupes (and apply previous point to the dupes
> > > > > too).
> > > > > - That way you'll be able to quickly fix (apparently, I didn't check) obvious
> > > > > mistakes [1].
> > > > > - You'll have to do a rev. bump for *FLAGS respect, please also check if you
> > > > > can avoid it by doing a version bump instead.
> > > > Well not always. If something is on ~testing then I don't think I should
> > > > "spam" the tree with revbumps. Stable users are my first priority so
> > >
> > > Stable may be more critical, but we support ~testing as well. How do you
> > > expect your changes to be tested before landing on stable if you don't
> > > revbump the packages, allowing them to reach our users?
> > I expect arch testers to do a pretty good testing before they mark them
> > stable. Seems like I am the only one who fixes such issues without revbump.
> > Strange, cvs log must be lying...
> >
> > Now lets see
> >
> > http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> >
> > "Ebuilds should have their -rX incremented whenever a change is made which will
> > make a **substantial** difference to what gets installed by the package — by
> > substantial, we generally mean "something for which many users would want to
> > upgrade". This is usually for bugfixes."
> >
> > Seems like it is up to maintainer's discretion to decide what it is
> > substantial change and what it is not. Many users wont be directly affected from my changes. It is not like not
> > respect CXX, CXXFLAGS after all.
> >
> > "Simple compile fixes do not warrant a revision bump; this is because they do
> > not affect the installed package for users who already managed to compile it.
> > Small documentation fixes are also usually not grounds for a new revision."
> >
> > So you want me to force everyone to update the package just to respect the
> > LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA
> > issues?
> >
> >
> > Please provide a patch for devmanual to make it more clear. If it is
> > already clear maybe I am that stupid after all.
> >
> > In any case, I will keep doing what I do because you didn't convince me so far
> > that my changes need a revbump. If arch testers fail to do proper testing
> > thats really *REALLY* not my fault. Testing is testing and I can't do a
> > revbump for every little piece of shit I fix everytime.
>
> Does respecting LDFLAGS change the installed files in any way? yes.
> Will users benefit from your change if you don't revbump? No.
>
> I think that chain of logic is enough to warrant a revbump and it is
> covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
>
> It's merely a cp, why are you making such a fuss about it? You're doing
> a good job already, we're just pointing out ways to make it even better
>
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway.

>
>
> BTW, archs do the final testing, but much testing is done by the users
> themselves, who report the bugs that get fixed before the packages get a
> STABLEREQ bug
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected or
not. I wouldn't do it either. This
>
> > >
> > > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > > revbumps in the first place
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
> > >
> > > > unless something is on stable branch, I fix it as it is. I don't want to
> > > > version bump anything because I don't want to mess with anyones
> > > > packages. I only do QA fixing. If you have problem touching your
> > > > packages just say it
> > > > >
> > > > > A.
> > > > >
> > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > >
> > > > --
> > > > Markos Chandras (hwoarang)
> > > > Gentoo Linux Developer
> > > > Web: http://hwoarang.silverarrow.org
> > >
> > > --
> > > Alex Alexander -=- wired
> > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > www.linuxized.com
> >
> >
> >
> > --
> > Markos Chandras (hwoarang)
> > Gentoo Linux Developer
> > Web: http://hwoarang.silverarrow.org
> > Key ID: 441AC410
> > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
>
>
>
> --
> Alex Alexander -=- wired
> Gentoo Linux Developer -=- Council / Qt / KDE / more
> www.linuxized.com



--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
 
Old 08-14-2010, 05:06 PM
Markos Chandras
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote:
> > So you want me to force everyone to update the package just to respect
> > the LDFLAGS.
>
> yes. IIRC it has been stated on this list before, that a change which
> changes the resulting binary always needs to be done in a revbump.
List? Really? I use devmanual for ebuild development not list archives.
>
> > Why, since until recently, nobody gave a crap about this
> > kind of QA issues?
>
> Thats a bad excuse!
Yet it is true. The tree is flood with such packages. So my assumption is
correct. Maintainers didn't and still don't give a crap about this QA issue,
other they wouldn't commit broken packages in the first place
>
> >
> > Please provide a patch for devmanual to make it more clear.
>
> Good idea. Any takers?
>
> thanks
> kind regards
>
> Thilo



--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
 
Old 08-14-2010, 05:21 PM
Alex Alexander
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
> On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> > Does respecting LDFLAGS change the installed files in any way? yes.
> > Will users benefit from your change if you don't revbump? No.
> >
> > I think that chain of logic is enough to warrant a revbump and it is
> > covered by the devmanual since the change affects the installed package.
> No it doesn't. If it was that clear we wouldn't debated over this over and
> over. The cvs logs and you will see that other devs are fixing the package
> without revbump.

The fact that others do what you do doesn't automatically make it right.

> >
> > It's merely a cp, why are you making such a fuss about it? You're doing
> > a good job already, we're just pointing out ways to make it even better
> >
> Cause I don't like users to compile the same damn package over and over. -r1
> for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
> reason or not? It is not like I introduce huge patches with bugfixes etc. My
> fixes are QA fixes not *serious* bugfixes anyway.
> Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
> there isn't much for users to test anyway. Either you respect the bloody flags
> or not. I don't do blindly commits. I try to test the packages in multiple
> chroots anyway.

All your fixes are important else you wouldn't be doing them.

I still don't understand why you don't want to revbump.

Your changes may not affect program features but they do fix hidden
issues. Issues that might help users later (for example, rebuilding a
package with --as-needed may reduce revdep-rebuilds in the future).

You can always try to reduce revbumps by doing all the things you
mentioned together, if possible.

In any case, unless we're talking about openoffice or kdelibs, revbumps
don't really cost so much anymore.

> >
> >
> > BTW, archs do the final testing, but much testing is done by the users
> > themselves, who report the bugs that get fixed before the packages get a
> > STABLEREQ bug
> Most of these bugs don't come from users but from Diego. Why? Because users
> don't bother reading the build.log and see if all their flags are respected or
> not. I wouldn't do it either. This

I never said users report these specific bugs. But they will test *your*
revbumps and may report other problems you didn't hit.

> > > > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > > > revbumps in the first place
> I am not convinced yet that this kind of QA fixes require a revbump. As I
> said, commit an actual patch, assigned to QA and if the rest of the members
> agree on that I am willing to change my policy.

Now you're just being stubborn. I'm pretty sure your mentor told you "any
change to installed files warrants a revbump"

Do we really need bureaucracy to enforce a commonly followed but not
documented policy?

> > > > > unless something is on stable branch, I fix it as it is. I don't want to
> > > > > version bump anything because I don't want to mess with anyones
> > > > > packages. I only do QA fixing. If you have problem touching your
> > > > > packages just say it
> > > > > >
> > > > > > A.
> > > > > >
> > > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > > >
> > > > > --
> > > > > Markos Chandras (hwoarang)
> > > > > Gentoo Linux Developer
> > > > > Web: http://hwoarang.silverarrow.org
> > > >
> > > > --
> > > > Alex Alexander -=- wired
> > > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > > www.linuxized.com
> > >
> > >
> > >
> > > --
> > > Markos Chandras (hwoarang)
> > > Gentoo Linux Developer
> > > Web: http://hwoarang.silverarrow.org
> > > Key ID: 441AC410
> > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
> >
> >
> >
> > --
> > Alex Alexander -=- wired
> > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > www.linuxized.com
>
>
>
> --
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> Web: http://hwoarang.silverarrow.org
> Key ID: 441AC410
> Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410



--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
 
Old 08-14-2010, 05:34 PM
Markos Chandras
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 08:21:15PM +0300, Alex Alexander wrote:
> On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
> > On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> > > Does respecting LDFLAGS change the installed files in any way? yes.
> > > Will users benefit from your change if you don't revbump? No.
> > >
> > > I think that chain of logic is enough to warrant a revbump and it is
> > > covered by the devmanual since the change affects the installed package.
> > No it doesn't. If it was that clear we wouldn't debated over this over and
> > over. The cvs logs and you will see that other devs are fixing the package
> > without revbump.
>
> The fact that others do what you do doesn't automatically make it right.
It means that there is something wrong with documentation
>
> > >
> > > It's merely a cp, why are you making such a fuss about it? You're doing
> > > a good job already, we're just pointing out ways to make it even better
> > >
> > Cause I don't like users to compile the same damn package over and over. -r1
> > for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
> > reason or not? It is not like I introduce huge patches with bugfixes etc. My
> > fixes are QA fixes not *serious* bugfixes anyway.
> > Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
> > there isn't much for users to test anyway. Either you respect the bloody flags
> > or not. I don't do blindly commits. I try to test the packages in multiple
> > chroots anyway.
>
> All your fixes are important else you wouldn't be doing them.
>
> I still don't understand why you don't want to revbump.
Cause I already said that I consider my changes trivial so the only actual
testing could be performed when the package is about to get stabilized
>
> Your changes may not affect program features but they do fix hidden
> issues. Issues that might help users later (for example, rebuilding a
> package with --as-needed may reduce revdep-rebuilds in the future).
>
> You can always try to reduce revbumps by doing all the things you
> mentioned together, if possible.
No cause I am not the maintainer so I fix whatever gets reported on bugzilla
and assigned to QA.
>
> In any case, unless we're talking about openoffice or kdelibs, revbumps
> don't really cost so much anymore.
Not if you own a single core CPU
>
> > >
> > >
> > > BTW, archs do the final testing, but much testing is done by the users
> > > themselves, who report the bugs that get fixed before the packages get a
> > > STABLEREQ bug
> > Most of these bugs don't come from users but from Diego. Why? Because users
> > don't bother reading the build.log and see if all their flags are respected or
> > not. I wouldn't do it either. This
>
> I never said users report these specific bugs. But they will test *your*
> revbumps and may report other problems you didn't hit.
>
> > > > > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > > > > revbumps in the first place
> > I am not convinced yet that this kind of QA fixes require a revbump. As I
> > said, commit an actual patch, assigned to QA and if the rest of the members
> > agree on that I am willing to change my policy.
>
> Now you're just being stubborn. I'm pretty sure your mentor told you "any
> change to installed files warrants a revbump"
Pretty sure this rule is not that strict.
>
> Do we really need bureaucracy to enforce a commonly followed but not
> documented policy?
So document this policy to point stubborn maintainers to it

Apparently I pissed a lot people off so I will siege my QA fixes for now.
Apparently I need a break
>
> > > > > > unless something is on stable branch, I fix it as it is. I don't want to
> > > > > > version bump anything because I don't want to mess with anyones
> > > > > > packages. I only do QA fixing. If you have problem touching your
> > > > > > packages just say it
> > > > > > >
> > > > > > > A.
> > > > > > >
> > > > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > > > >
> > > > > > --
> > > > > > Markos Chandras (hwoarang)
> > > > > > Gentoo Linux Developer
> > > > > > Web: http://hwoarang.silverarrow.org
> > > > >
> > > > > --
> > > > > Alex Alexander -=- wired
> > > > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > > > www.linuxized.com
> > > >
> > > >
> > > >
> > > > --
> > > > Markos Chandras (hwoarang)
> > > > Gentoo Linux Developer
> > > > Web: http://hwoarang.silverarrow.org
> > > > Key ID: 441AC410
> > > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
> > >
> > >
> > >
> > > --
> > > Alex Alexander -=- wired
> > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > www.linuxized.com
> >
> >
> >
> > --
> > Markos Chandras (hwoarang)
> > Gentoo Linux Developer
> > Web: http://hwoarang.silverarrow.org
> > Key ID: 441AC410
> > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
>
>
>
> --
> Alex Alexander -=- wired
> Gentoo Linux Developer -=- Council / Qt / KDE / more
> www.linuxized.com



--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
 
Old 08-14-2010, 05:35 PM
Harald van Dijk
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
> > So you want me to force everyone to update the package just to respect
> > the LDFLAGS.
>
> yes. IIRC it has been stated on this list before, that a change which
> changes the resulting binary always needs to be done in a revbump.

If that's true, that doesn't make sense. Take one extreme case: let's
say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
But the majority of people using gcc don't even turn on java support,
those that do have a working libgcj already, and gcc can easily take
hours to build. Should you revbump?

There are always exceptions. Maybe you don't consider LDFLAGS support
in general one of those exceptions, but clearly some others do. You
can't just tell them "there are no exceptions" when there are, you need
to explain why this isn't a valid reason to make an exception.
My impression, too, is that few people care enough about LDFLAGS support
to want to rebuild packages for it, so I would not have bumped either,
but I'm willing to be convinced I'm wrong.
 
Old 08-14-2010, 05:43 PM
Alex Alexander
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On Sat, Aug 14, 2010 at 08:34:13PM +0300, Markos Chandras wrote:
> > > said, commit an actual patch, assigned to QA and if the rest of the members
> > > agree on that I am willing to change my policy.
> >
> > Now you're just being stubborn. I'm pretty sure your mentor told you "any
> > change to installed files warrants a revbump"
> Pretty sure this rule is not that strict.
> >
> > Do we really need bureaucracy to enforce a commonly followed but not
> > documented policy?
> So document this policy to point stubborn maintainers to it
>
> Apparently I pissed a lot people off so I will siege my QA fixes for now.
> Apparently I need a break

I'm pretty sure you didn't piss off anyone.

We're having a conversation about something, we're not fighting
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
 
Old 08-14-2010, 06:35 PM
Duncan
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

Markos Chandras posted on Sat, 14 Aug 2010 20:00:40 +0300 as excerpted:

> Cause I don't like users to compile the same damn package over and over.
> -r1 for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is
> that a good reason or not? It is not like I introduce huge patches with
> bugfixes etc. My fixes are QA fixes not *serious* bugfixes anyway.
> Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted
> and there isn't much for users to test anyway. Either you respect the
> bloody flags or not. I don't do blindly commits. I try to test the
> packages in multiple chroots anyway.

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently). The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.

Better the few at a time, even if some of them end up being bumped and
built twice as a result, than the multiple hundred at once.

So I'm not going to get into who's right or wrong vs. current policy, but
that's my perspective as a user. For LDFLAGS respecting changes at least,
please do the rev-bumps, as the cost of failing to do so, thus triggering
a mass update when a base lib changes, far exceeds that of dealing with
them on a trickle-in basis, even if a few do end up updated twice as a
result.

Thanks. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 08-14-2010, 06:51 PM
Richard Freeman
 
Default gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

On 08/14/2010 02:35 PM, Duncan wrote:

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently). The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.


Interesting - I was looking at it in the opposite way.

Not having as-needed means that I /might/ have to rebuild that one
package unnecessarily at some point in the future - if it isn't upgraded
first for some other reason.


Rev-bumping the build means that I /will/ have to rebuild that one
package for certain - right now.


I think we can all at least agree that this is a gray area as far as the
INTENT of the (apparently unwritten) policy goes.


I would like to echo Markos's comment that having policies written down,
if only to point stubborn maintainers to them, would be helpful. The
other reason to have them written is so that they go through some kind
of review, and there is some way of challenging them if they no longer
make sense.


In any case, I think we're making a pretty big deal about a pretty small
issue - we can probably all afford to think about this a little more and
move on...


Rich
 

Thread Tools




All times are GMT. The time now is 09:35 PM.

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