In the big "linux-next" series of emails, David Miller suggested that
the feature-removal-schedule file be broken up into little pieces, as it
is causing merge problems for different trees.
This changeset does just that. Turns out that this makes things more
readable, as it's easier to look at a list of filenames for things than
picking through a 300 line text file.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
thanks,
greg k-h
--------
Documentation/feature-removal-schedule.txt | 308 ----------
Documentation/feature-removal-schedule/README | 16
Documentation/feature-removal-schedule/acpi-procfs | 6
Documentation/feature-removal-schedule/b43_support_for_old_firmware | 6
Documentation/feature-removal-schedule/bcm43xx-wireless-driver | 6
Documentation/feature-removal-schedule/dev-power.power_state | 10
Documentation/feature-removal-schedule/eepro100-driver | 4
Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers | 4
Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks | 7
Documentation/feature-removal-schedule/ieee80211-softmac | 5
Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL | 9
Documentation/feature-removal-schedule/libata-spindown-warning | 15
Documentation/feature-removal-schedule/netfilter-rules | 29
Documentation/feature-removal-schedule/old_ncr54c9_driver | 6
Documentation/feature-removal-schedule/pcmcia-control-ioctl | 14
Documentation/feature-removal-schedule/ppc-arch-include-directories | 10
Documentation/feature-removal-schedule/proc-acpi-button | 5
Documentation/feature-removal-schedule/proc-acpi-event | 5
Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 | 7
Documentation/feature-removal-schedule/sk98lin-driver | 5
Documentation/feature-removal-schedule/solaris_syscall_support | 8
Documentation/feature-removal-schedule/sys_sysctl | 32 +
Documentation/feature-removal-schedule/uevent_PHYSDEV | 7
Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports | 7
Documentation/feature-removal-schedule/vfl1-ioctls | 16
Documentation/feature-removal-schedule/vm_ops.nopage | 6
26 files changed, 245 insertions(+), 308 deletions(-)
---------------
Greg Kroah-Hartman (1):
Split up feature-removal-schedule.txt into individual files.
From: Greg KH <[email protected]>
Date: Tue, 12 Feb 2008 23:02:15 -0800
> In the big "linux-next" series of emails, David Miller suggested that
> the feature-removal-schedule file be broken up into little pieces, as it
> is causing merge problems for different trees.
>
> This changeset does just that. Turns out that this makes things more
> readable, as it's easier to look at a list of filenames for things than
> picking through a 300 line text file.
>
> Please pull from:
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
Acked-by: David S. Miller <[email protected]>
Thanks for doing this work.
On Tue, 2008-02-12 at 23:04 -0800, David Miller wrote:
> > In the big "linux-next" series of emails, David Miller suggested that
> > the feature-removal-schedule file be broken up into little pieces, as it
> > is causing merge problems for different trees.
I suggest the same for MAINTAINERS
I'd prefer a Maintainers subdirectory.
I have such a tree. Anyone want it?
Hi Greg
> In the big "linux-next" series of emails, David Miller suggested that
> the feature-removal-schedule file be broken up into little pieces, as it
> is causing merge problems for different trees.
>
> This changeset does just that. Turns out that this makes things more
> readable, as it's easier to look at a list of filenames for things than
> picking through a 300 line text file.
Excellent!
thank you for good job.
- kosaki
On Tue, Feb 12, 2008 at 11:02:15PM -0800, Greg KH wrote:
> This changeset does just that. Turns out that this makes things more
> readable, as it's easier to look at a list of filenames for things than
> picking through a 300 line text file.
Hmm.. While you're at it, would it make sense to encode the "When"
into the filename? Like 2010-09-sys_sysctl or 2.6.26-feature-X.
Requires renaming when something is given more time to live, though.
On the positive side, I think it'd help in keeping these current. 2.6.24
has e.g.
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
If the date/release has been reached and the feature hasn't been removed
either more time is added or the feature gets removed.
>
> Documentation/feature-removal-schedule.txt | 308 ----------
> Documentation/feature-removal-schedule/README | 16
> Documentation/feature-removal-schedule/acpi-procfs | 6
> Documentation/feature-removal-schedule/b43_support_for_old_firmware | 6
> Documentation/feature-removal-schedule/bcm43xx-wireless-driver | 6
> Documentation/feature-removal-schedule/dev-power.power_state | 10
> Documentation/feature-removal-schedule/eepro100-driver | 4
> Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers | 4
> Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks | 7
64? ;)
> Documentation/feature-removal-schedule/ieee80211-softmac | 5
> Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL | 9
> Documentation/feature-removal-schedule/libata-spindown-warning | 15
> Documentation/feature-removal-schedule/netfilter-rules | 29
> Documentation/feature-removal-schedule/old_ncr54c9_driver | 6
> Documentation/feature-removal-schedule/pcmcia-control-ioctl | 14
> Documentation/feature-removal-schedule/ppc-arch-include-directories | 10
> Documentation/feature-removal-schedule/proc-acpi-button | 5
> Documentation/feature-removal-schedule/proc-acpi-event | 5
> Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 | 7
> Documentation/feature-removal-schedule/sk98lin-driver | 5
> Documentation/feature-removal-schedule/solaris_syscall_support | 8
> Documentation/feature-removal-schedule/sys_sysctl | 32 +
> Documentation/feature-removal-schedule/uevent_PHYSDEV | 7
> Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports | 7
> Documentation/feature-removal-schedule/vfl1-ioctls | 16
> Documentation/feature-removal-schedule/vm_ops.nopage | 6
> 26 files changed, 245 insertions(+), 308 deletions(-)
>
> ---------------
>
> Greg Kroah-Hartman (1):
> Split up feature-removal-schedule.txt into individual files.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Greg KH wrote:
> In the big "linux-next" series of emails, David Miller suggested that
> the feature-removal-schedule file be broken up into little pieces, as it
> is causing merge problems for different trees.
>
> This changeset does just that. Turns out that this makes things more
> readable, as it's easier to look at a list of filenames for things than
> picking through a 300 line text file.
>
> Please pull from:
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
>
> thanks,
>
> greg k-h
>
> --------
>
> Documentation/feature-removal-schedule.txt | 308 ----------
> Documentation/feature-removal-schedule/README | 16
> Documentation/feature-removal-schedule/acpi-procfs | 6
> Documentation/feature-removal-schedule/b43_support_for_old_firmware | 6
> Documentation/feature-removal-schedule/bcm43xx-wireless-driver | 6
> Documentation/feature-removal-schedule/dev-power.power_state | 10
> Documentation/feature-removal-schedule/eepro100-driver | 4
> Documentation/feature-removal-schedule/i2c-i810_i2c-prosavage_i2c-savage4_drivers | 4
> Documentation/feature-removal-schedule/i386-x86_65-bzImage-symlinks | 7
> Documentation/feature-removal-schedule/ieee80211-softmac | 5
> Documentation/feature-removal-schedule/kernel_thread_EXPORT_SYMBOL | 9
> Documentation/feature-removal-schedule/libata-spindown-warning | 15
> Documentation/feature-removal-schedule/netfilter-rules | 29
> Documentation/feature-removal-schedule/old_ncr54c9_driver | 6
> Documentation/feature-removal-schedule/pcmcia-control-ioctl | 14
> Documentation/feature-removal-schedule/ppc-arch-include-directories | 10
> Documentation/feature-removal-schedule/proc-acpi-button | 5
> Documentation/feature-removal-schedule/proc-acpi-event | 5
> Documentation/feature-removal-schedule/rc80211-simple-rate-control-for-mac80211 | 7
> Documentation/feature-removal-schedule/sk98lin-driver | 5
> Documentation/feature-removal-schedule/solaris_syscall_support | 8
> Documentation/feature-removal-schedule/sys_sysctl | 32 +
> Documentation/feature-removal-schedule/uevent_PHYSDEV | 7
> Documentation/feature-removal-schedule/unused_EXPORT_SYMBOL_exports | 7
> Documentation/feature-removal-schedule/vfl1-ioctls | 16
> Documentation/feature-removal-schedule/vm_ops.nopage | 6
> 26 files changed, 245 insertions(+), 308 deletions(-)
>
> ---------------
>
> Greg Kroah-Hartman (1):
> Split up feature-removal-schedule.txt into individual files.
I'd say use the shorter 'feature-removal' for the dir name.
Otherwise ACK...
On Tue, 12 Feb 2008 23:22:02 -0800 Joe Perches wrote:
> On Tue, 2008-02-12 at 23:04 -0800, David Miller wrote:
> > > In the big "linux-next" series of emails, David Miller suggested that
> > > the feature-removal-schedule file be broken up into little pieces, as it
> > > is causing merge problems for different trees.
>
> I suggest the same for MAINTAINERS
>
> I'd prefer a Maintainers subdirectory.
>
> I have such a tree. Anyone want it?
I'd prefer that neither of them be split up...
The merge problems for either of them should be trivial.
---
~Randy
On Tue, Feb 12, 2008 at 11:22:02PM -0800, Joe Perches wrote:
> On Tue, 2008-02-12 at 23:04 -0800, David Miller wrote:
> > > In the big "linux-next" series of emails, David Miller suggested that
> > > the feature-removal-schedule file be broken up into little pieces, as it
> > > is causing merge problems for different trees.
>
> I suggest the same for MAINTAINERS
Why, is it a merge problem for you?
I've merged lots of new entries into it over the years, and never had a
problem with it, but that just might be me...
thanks,
greg k-h
On Wed, Feb 13, 2008 at 12:30:14PM +0200, Pekka Pietikainen wrote:
> On Tue, Feb 12, 2008 at 11:02:15PM -0800, Greg KH wrote:
> > This changeset does just that. Turns out that this makes things more
> > readable, as it's easier to look at a list of filenames for things than
> > picking through a 300 line text file.
>
> Hmm.. While you're at it, would it make sense to encode the "When"
> into the filename? Like 2010-09-sys_sysctl or 2.6.26-feature-X.
Well why stop there? Why not put the name of the person and the full
description also in the file? :)
Seriously, a simple grep works fine here.
> Requires renaming when something is given more time to live, though.
> On the positive side, I think it'd help in keeping these current. 2.6.24
> has e.g.
>
> What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
> When: November 2005
>
> If the date/release has been reached and the feature hasn't been removed
> either more time is added or the feature gets removed.
This has already been discussed a number of times on lkml before, please
see those threads.
thanks,
greg k-h
On Wed, 2008-02-13 at 08:59 -0800, Greg KH wrote:
> > I suggest the same for MAINTAINERS
> Why, is it a merge problem for you?
$ git-log --pretty=oneline --name-only | \
grep -vP "[a-fA-F0-9]{40,40}\s" | sort | uniq -c | sort -rbn
541 MAINTAINERS
506 kernel/sched.c
374 drivers/scsi/libata-core.c
343 include/linux/sched.h
340 include/linux/libata.h
327 drivers/net/tg3.c
327 drivers/net/sky2.c
309 mm/page_alloc.c
304 drivers/ata/libata-core.c
296 Makefile
MAINTAINERS is the most frequently patched file
It's not kept in alphabetic order
It's not easy to find the appropriate maintainer for a specific file
I'd like to add file patterns to MAINTAINERS entries
On Wed, Feb 13, 2008 at 09:33:15AM -0800, Joe Perches wrote:
> On Wed, 2008-02-13 at 08:59 -0800, Greg KH wrote:
> > > I suggest the same for MAINTAINERS
> > Why, is it a merge problem for you?
>
> $ git-log --pretty=oneline --name-only | \
> grep -vP "[a-fA-F0-9]{40,40}\s" | sort | uniq -c | sort -rbn
> 541 MAINTAINERS
> 506 kernel/sched.c
> 374 drivers/scsi/libata-core.c
> 343 include/linux/sched.h
> 340 include/linux/libata.h
> 327 drivers/net/tg3.c
> 327 drivers/net/sky2.c
> 309 mm/page_alloc.c
> 304 drivers/ata/libata-core.c
> 296 Makefile
>
> MAINTAINERS is the most frequently patched file
But does it cause merge conflicts? The size of it lends itself to no
real conflicts that I have run into over time, but others might have had
problems, that's why I'm asking.
> It's not kept in alphabetic order
You can send patches to fix this :)
> It's not easy to find the appropriate maintainer for a specific file
git does a better job of this at times :)
> I'd like to add file patterns to MAINTAINERS entries
I thought we had gone over this before...
thanks,
greg k-h
On Wed, 13 Feb 2008, Joe Perches wrote:
>
> MAINTAINERS is the most frequently patched file
Almost all of them merge perfectly, with no problems what-so-ever. And the
merge conflicts, when they happen, are generally really trivial, and never
cause any subtle run-time bugs even if they were to happen.
So in that sense, I think both MAINTAINERS and the deprecation schedule
are totally uninteresting. Yes, they have merge conflicts. But those merge
conflicts are really really easy to handle.
Linus
On Wed, 13 Feb 2008, Linus Torvalds wrote:
>
> So in that sense, I think both MAINTAINERS and the deprecation schedule
> are totally uninteresting. Yes, they have merge conflicts. But those merge
> conflicts are really really easy to handle.
That, btw, includes "automatic merges" for something like a Linux-next
tree. It's easy to just make something that says: if the merge fails, try
to fix up these xyz files by just committing them with merge error markers
and all".
That's fine for testing, exactly because it has no coding impact (and then
when a _real_ merge happens, you have a human that actually resolves it).
The git script would be something like
UNIMPORTANT_LIST=MAINTAINERS \
Documentation/feature-removal-schedule.txt \
...
git pull ... ||
git add $UNIMPORTANT_LIST &&
git commit -m "Trivially conflicting merge"
which basically says: if the pull fails (leaving a conflicted tree), try
to just "git add" the files on the unimportant list as-is, and then try to
commit the merge that way instead.
Git if nothing if not scriptable, and things like this are *trivial*.
Linus
On Wed, 13 Feb 2008 10:13:42 -0800 (PST)
Linus Torvalds <[email protected]> wrote:
>
>
> On Wed, 13 Feb 2008, Joe Perches wrote:
> >
> > MAINTAINERS is the most frequently patched file
>
> Almost all of them merge perfectly, with no problems what-so-ever. And the
> merge conflicts, when they happen, are generally really trivial, and never
> cause any subtle run-time bugs even if they were to happen.
>
> So in that sense, I think both MAINTAINERS and the deprecation schedule
> are totally uninteresting. Yes, they have merge conflicts. But those merge
> conflicts are really really easy to handle.
>
yup. I'll often get conflicts and rejects in those files from the git
trees which I don't even bother fixing.
Linus Torvalds <[email protected]> writes:
> On Wed, 13 Feb 2008, Linus Torvalds wrote:
>>
>> So in that sense, I think both MAINTAINERS and the deprecation schedule
>> are totally uninteresting. Yes, they have merge conflicts. But those merge
>> conflicts are really really easy to handle.
>
> That, btw, includes "automatic merges" for something like a Linux-next
> tree. It's easy to just make something that says: if the merge fails, try
> to fix up these xyz files by just committing them with merge error markers
> and all".
>
> That's fine for testing, exactly because it has no coding impact (and then
> when a _real_ merge happens, you have a human that actually resolves it).
> ...
> Git if nothing if not scriptable, and things like this are *trivial*.
You can also use "union" low-level merge driver for such files
via gitattributes(5).
On Wed, Feb 13, 2008 at 10:13:42AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Feb 2008, Joe Perches wrote:
> >
> > MAINTAINERS is the most frequently patched file
>
> Almost all of them merge perfectly, with no problems what-so-ever. And the
> merge conflicts, when they happen, are generally really trivial, and never
> cause any subtle run-time bugs even if they were to happen.
>
> So in that sense, I think both MAINTAINERS and the deprecation schedule
> are totally uninteresting. Yes, they have merge conflicts. But those merge
> conflicts are really really easy to handle.
Yes, they are easy to handle, but for trees that have to deal with these
merge issues all the time, they are a pain (hit this one again today.)
It takes a few minutes to fix up the resolution by hand (using either
git or quilt), as we do want the new addition to be in the file, so by
splitting it up, it makes our (the sub-tree maintainers) lives easier.
I've never had a problem with the MAINTAINERS file, as it is pretty big
and conflicts for me seem to never happen, but the feature-removal file
does cause problems as it changes over time and things need to get added
and removed.
Also, there are already remants of a bad-merge in that file, which
somehow sneaked through.
Yes, these files can not cause kernel bugs, but they are semi-important
to at least get correct. So I'd ask you to reconsider for the
feature-removal stuff at the very least.
If you do, the git tree is still there at:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
to pull from :)
thanks,
greg k-h
On Tue, 19 Feb 2008 11:07:45 -0800 Greg KH wrote:
> On Wed, Feb 13, 2008 at 10:13:42AM -0800, Linus Torvalds wrote:
> >
> >
> > On Wed, 13 Feb 2008, Joe Perches wrote:
> > >
> > > MAINTAINERS is the most frequently patched file
> >
> > Almost all of them merge perfectly, with no problems what-so-ever. And the
> > merge conflicts, when they happen, are generally really trivial, and never
> > cause any subtle run-time bugs even if they were to happen.
> >
> > So in that sense, I think both MAINTAINERS and the deprecation schedule
> > are totally uninteresting. Yes, they have merge conflicts. But those merge
> > conflicts are really really easy to handle.
>
> Yes, they are easy to handle, but for trees that have to deal with these
> merge issues all the time, they are a pain (hit this one again today.)
> It takes a few minutes to fix up the resolution by hand (using either
> git or quilt), as we do want the new addition to be in the file, so by
> splitting it up, it makes our (the sub-tree maintainers) lives easier.
>
> I've never had a problem with the MAINTAINERS file, as it is pretty big
> and conflicts for me seem to never happen, but the feature-removal file
> does cause problems as it changes over time and things need to get added
> and removed.
>
> Also, there are already remants of a bad-merge in that file, which
> somehow sneaked through.
>
> Yes, these files can not cause kernel bugs, but they are semi-important
> to at least get correct. So I'd ask you to reconsider for the
> feature-removal stuff at the very least.
>
> If you do, the git tree is still there at:
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
>
> to pull from :)
Alternatively, since they are easy to fix, I'll volunteer to fix them
(after notified of problems :). (and not split up the file)
---
~Randy
On Tue, Feb 19, 2008 at 11:34:22AM -0800, Randy Dunlap wrote:
> On Tue, 19 Feb 2008 11:07:45 -0800 Greg KH wrote:
>
> > On Wed, Feb 13, 2008 at 10:13:42AM -0800, Linus Torvalds wrote:
> > >
> > >
> > > On Wed, 13 Feb 2008, Joe Perches wrote:
> > > >
> > > > MAINTAINERS is the most frequently patched file
> > >
> > > Almost all of them merge perfectly, with no problems what-so-ever. And the
> > > merge conflicts, when they happen, are generally really trivial, and never
> > > cause any subtle run-time bugs even if they were to happen.
> > >
> > > So in that sense, I think both MAINTAINERS and the deprecation schedule
> > > are totally uninteresting. Yes, they have merge conflicts. But those merge
> > > conflicts are really really easy to handle.
> >
> > Yes, they are easy to handle, but for trees that have to deal with these
> > merge issues all the time, they are a pain (hit this one again today.)
> > It takes a few minutes to fix up the resolution by hand (using either
> > git or quilt), as we do want the new addition to be in the file, so by
> > splitting it up, it makes our (the sub-tree maintainers) lives easier.
> >
> > I've never had a problem with the MAINTAINERS file, as it is pretty big
> > and conflicts for me seem to never happen, but the feature-removal file
> > does cause problems as it changes over time and things need to get added
> > and removed.
> >
> > Also, there are already remants of a bad-merge in that file, which
> > somehow sneaked through.
> >
> > Yes, these files can not cause kernel bugs, but they are semi-important
> > to at least get correct. So I'd ask you to reconsider for the
> > feature-removal stuff at the very least.
> >
> > If you do, the git tree is still there at:
> > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
> >
> > to pull from :)
>
> Alternatively, since they are easy to fix, I'll volunteer to fix them
> (after notified of problems :). (and not split up the file)
Well, the problem is that when someone sends me a patch, I have to do
the fixups by hand (same goes for Jeff), in order for you, or anyone
else to even be able to see the patch show up anywhere.
That's why having this split up will help make the sub-tree maintainers
lives easier, it's not an issue for Andrew and Linus, as usually the
problem is all fixed up by the time the patch makes it there :)
thanks,
greg k-h
On Tue, Feb 19, 2008 at 11:49:10AM -0800, Greg KH wrote:
> On Tue, Feb 19, 2008 at 11:34:22AM -0800, Randy Dunlap wrote:
> > On Tue, 19 Feb 2008 11:07:45 -0800 Greg KH wrote:
> >
> > > On Wed, Feb 13, 2008 at 10:13:42AM -0800, Linus Torvalds wrote:
> > > >
> > > >
> > > > On Wed, 13 Feb 2008, Joe Perches wrote:
> > > > >
> > > > > MAINTAINERS is the most frequently patched file
> > > >
> > > > Almost all of them merge perfectly, with no problems what-so-ever. And the
> > > > merge conflicts, when they happen, are generally really trivial, and never
> > > > cause any subtle run-time bugs even if they were to happen.
> > > >
> > > > So in that sense, I think both MAINTAINERS and the deprecation schedule
> > > > are totally uninteresting. Yes, they have merge conflicts. But those merge
> > > > conflicts are really really easy to handle.
> > >
> > > Yes, they are easy to handle, but for trees that have to deal with these
> > > merge issues all the time, they are a pain (hit this one again today.)
> > > It takes a few minutes to fix up the resolution by hand (using either
> > > git or quilt), as we do want the new addition to be in the file, so by
> > > splitting it up, it makes our (the sub-tree maintainers) lives easier.
> > >
> > > I've never had a problem with the MAINTAINERS file, as it is pretty big
> > > and conflicts for me seem to never happen, but the feature-removal file
> > > does cause problems as it changes over time and things need to get added
> > > and removed.
> > >
> > > Also, there are already remants of a bad-merge in that file, which
> > > somehow sneaked through.
> > >
> > > Yes, these files can not cause kernel bugs, but they are semi-important
> > > to at least get correct. So I'd ask you to reconsider for the
> > > feature-removal stuff at the very least.
> > >
> > > If you do, the git tree is still there at:
> > > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/
> > >
> > > to pull from :)
> >
> > Alternatively, since they are easy to fix, I'll volunteer to fix them
> > (after notified of problems :). (and not split up the file)
>
> Well, the problem is that when someone sends me a patch, I have to do
> the fixups by hand (same goes for Jeff), in order for you, or anyone
> else to even be able to see the patch show up anywhere.
>
> That's why having this split up will help make the sub-tree maintainers
> lives easier, it's not an issue for Andrew and Linus, as usually the
> problem is all fixed up by the time the patch makes it there :)
I'm not sure whether it's feasible, but there's a tricky alternative
solution:
Adding or removing entries must not add or remove any empty or dash lines.
With this rule, all other entries would be outside of the context of
patches touching feature-removal-schedule.txt...
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed