must-fix list reconciliation

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?

Thanks,
Nick

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.

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 ;-)

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

On Fri, 3 Oct 2003 12:34:37 +0100 Matthew Wilcox <[email protected]> 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.
| 
| 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 ;-)

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?

--
~Randy

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.

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.

If it ends up going into a source tree, I can be the editor / maintainer.

On Sat, 04 Oct 2003 08:55:14 +1000 Nick Piggin <[email protected]> wrote:

| Randy.Dunlap wrote:
| 
| >On Fri, 3 Oct 2003 12:34:37 +0100 Matthew Wilcox <[email protected]> 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.

I don't quite see how they belong in the kernel source tree, although I don't mind... That's not where I would expect to find the list, though. I would expect it more on kernel.org e.g.

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

One editor if it's in a "file" vs. being in a 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.

of only must-fix and not should-fix??
I wouldn't want to see should-fix abandoned.

--
~Randy

snip

I don't know what the criteria is. It would help lazy people send patches. If its in the tree they might, if they have to check if they've got the newest version and download it from somewhere else, they won't.

I was thinking it could become a criteria (obviously with exceptions) for feature / code freezes. I don't know what Linus or Andrew or anyone else think about this though.

snip

Well if its on the wiki you still need a janitor at least. The shouldfix list there is beginning to look like peoples' personal todo lists.

snip

No, both

On Sat, 04 Oct 2003 09:18:59 +1000 Nick Piggin <[email protected]> wrote:

| 
| 
| Randy.Dunlap wrote:
| 
| >On Sat, 04 Oct 2003 08:55:14 +1000 Nick Piggin <[email protected]> wrote:
| >
| >
| snip
| 
| >| 
| >| 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.
| >
| >I don't quite see how they belong in the kernel source tree,
| >although I don't mind...  That's not where I would expect to find
| >the list, though.  I would expect it more on kernel.org e.g.
| >
| 
| I don't know what the criteria is. It would help lazy people send 
| patches. If
| its in the tree they might, if they have to check if they've got the newest
| version and download it from somewhere else, they won't.
| 
| I was thinking it could become a criteria (obviously with exceptions) for
| feature / code freezes. I don't know what Linus or Andrew or anyone else 
| think about this though.
| 
| 
| snip
| 
| >
| >| 
| >| Yes, and even easier if there was just one editor.
| >| eg. there 2 drivers/acpi sections in the mustfix list on wiki.
| >
| >One editor if it's in a "file" vs. being in a wiki.
| >
| 
| Well if its on the wiki you still need a janitor at least. The shouldfix 
| list
| there is beginning to look like peoples' personal todo lists.
| 
| >
| >| 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.
| >| 
| >
| snip
| 
| >| 
| >| If it ends up going into a source tree, I can be the editor / maintainer.
| >
| >of only must-fix and not should-fix??
| >I wouldn't want to see should-fix abandoned.
| >
| 
| No, both

OK, I don't really care where it is.
If you are willing to keep it updated, you get to choose where it lives (IMO).

--
~Randy

Well I can be the editor. I obviously would need people to send me updates.

Nick Piggin, Sat, Oct 04, 2003 01:31:14 +0200:

assuming they don't send you updates, what will you do? Can you monitor lkml on regular basis?

Well yeah, but often people don't say "this change fixes this". But things gradually get fixed. I can get every entry assigned a name, and ask them how its going from time to time.

His activity there can be seen by the number of posts (97 in the last 4 weeks), so that may give you an idea... :)