[GIT PATCH] split up feature-removal-schedule.txt

[GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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.

Re: [GIT PATCH] split up feature-removal-schedule.txt

[David Miller]

From: Greg KH <gregkh@suse.de>
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 <davem@davemloft.net>

Thanks for doing this work.

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Joe Perches]

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?

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Randy Dunlap]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Joe Perches]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Linus Torvalds]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Linus Torvalds]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> 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).

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Andrew Morton]

On Wed, 13 Feb 2008 10:13:42 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> 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.

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Randy Dunlap]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Adrian Bunk]

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

Re: split up feature-removal-schedule.txt

[KOSAKI Motohiro]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Pekka Pietikainen]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Greg KH]

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

Re: [GIT PATCH] split up feature-removal-schedule.txt

[Jeff Garzik]

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...