Pasi Kärkkäinen wrote:
On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
Great.
I made to minor adaption. I added a link to the Status page to my warning in
before the kernel log by feature page. And I also mentioned that at the time
the page was last updated the latest kernel version was 4.7. Yes, thats some
extra work to update the kernel version, but I think its beneficial to
explicitely mention the kernel version the page talks about. Everyone who
updates the page can update the version within a second.
Hmm.. that will still leave people wondering "but I'm running Linux 4.4, not 4.7, I
wonder what the status of feature X is.."
Should we also add a column for kernel version, so we can add "feature X is known to
be OK on Linux 3.18 and later".. ?
Or add those to "notes" field, where applicable?
-- Pasi
I think a separate column would be the best solution. For example
archiving the status page pr. kernel version (as I suggested) will lead
to issues too. For example if something appears to be just fine in 4.6
is found to be horribly broken in for example 4.10 the archive would
still indicate that it WAS ok at that time even if it perhaps was not.
Then you have regressions - something that worked in 4.4 may not work in
4.9, but I still think the best idea is to simply label the status as ok
/ broken since 4.x as those who really want to use a broken feature
probably would to research to see if this used to work , besides if
something that used to work goes haywire it should be fixed quickly :)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
