From: Nick Piggin <piggin@cyberone.com.au>
To: "Randy.Dunlap" <rddunlap@osdl.org>, Matthew Wilcox <willy@debian.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: must-fix list reconciliation
Date: Sat, 04 Oct 2003 08:55:14 +1000 [thread overview]
Message-ID: <3F7DFE52.9010400@cyberone.com.au> (raw)
In-Reply-To: <20031003083640.61dcf517.rddunlap@osdl.org>
Randy.Dunlap wrote:
>On Fri, 3 Oct 2003 12:34:37 +0100 Matthew Wilcox <willy@debian.org> wrote:
>
>| On Fri, Oct 03, 2003 at 07:19:51PM +1000, Nick Piggin wrote:
>| > Hi everyone,
>| > As you might or might not know, the must-fix / should-fix lists have been
>| > inadvertently forked. We are merging them again, so please don't update
>| > the wiki until we have worked out what to do with them. This should be a
>| > day or two at most.
>| >
>| > I had the idea that maybe we could put them into the source tree, and
>| > encourage people to keep them up to date by making them become criteria
>| > for the feature and code freeze. Comments?
>|
>| I'm a little disappointed that after I spent time converting them into
>| the wiki form, you're now proposing abandoning them again. This seems
>| like a retrograde step.
>|
>
To be honest I don't really like the wiki. I'd rather changes go through
lkml where its easier to discuss them and keep up with them. Thats just my
preference though. I don't know what anyone else thinks.
>
>| What I'd be more interested in doing is combining the must- and should-
>| fix lists. As a first pass, just put all the must-fix items on the
>| should-fix list at pri 4. One of the things I did was delete the things
>| that appeared on both lists. This would obviously be easier if they
>| were in one list ;-)
>
Yes, and even easier if there was just one editor.
eg. there 2 drivers/acpi sections in the mustfix list on wiki.
I'd like to keep the 2 lists seperate. The must-fix list is concise and easy
to scan the whole thing. I guess this isn't a problem if there is one
editor.
>Agreed on that. I think the location is not the problem (whether
>source tree or wiki), it's just an extra step to keep them updated,
>and having no owner (or _many_ owners) often doesn't work.
>Is one of you (or the two of you) willing to be the owner/editor?
>
If it ends up going into a source tree, I can be the editor / maintainer.
next prev parent reply other threads:[~2003-10-03 22:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 9:19 must-fix list reconciliation Nick Piggin
2003-10-03 11:34 ` Matthew Wilcox
2003-10-03 15:36 ` Randy.Dunlap
2003-10-03 22:55 ` Nick Piggin [this message]
2003-10-03 23:02 ` Randy.Dunlap
2003-10-03 23:18 ` Nick Piggin
2003-10-03 23:18 ` Randy.Dunlap
2003-10-03 23:31 ` Nick Piggin
2003-10-04 9:54 ` Alex Riesen
2003-10-05 2:43 ` Nick Piggin
2003-10-05 5:12 ` Mike Fedyk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3F7DFE52.9010400@cyberone.com.au \
--to=piggin@cyberone.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.