must-fix list reconciliation

must-fix list reconciliation

[Nick Piggin]

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

Re: must-fix list reconciliation

[Matthew Wilcox]

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

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

Re: must-fix list reconciliation

[Randy.Dunlap]

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

Re: must-fix list reconciliation

[Nick Piggin]

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.

Re: must-fix list reconciliation

[Randy.Dunlap]

On Sat, 04 Oct 2003 08:55:14 +1000 Nick Piggin <piggin@cyberone.com.au> wrote:

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

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

Re: must-fix list reconciliation

[Nick Piggin]

Randy.Dunlap wrote:

>On Sat, 04 Oct 2003 08:55:14 +1000 Nick Piggin <piggin@cyberone.com.au> 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

Re: must-fix list reconciliation

[Randy.Dunlap]

On Sat, 04 Oct 2003 09:18:59 +1000 Nick Piggin <piggin@cyberone.com.au> wrote:

| 
| 
| Randy.Dunlap wrote:
| 
| >On Sat, 04 Oct 2003 08:55:14 +1000 Nick Piggin <piggin@cyberone.com.au> 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

Re: must-fix list reconciliation

[Nick Piggin]

Randy.Dunlap wrote:

>On Sat, 04 Oct 2003 09:18:59 +1000 Nick Piggin <piggin@cyberone.com.au> wrote:
>
>
>| 
>| 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).
>


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

Re: must-fix list reconciliation

[Alex Riesen]

Nick Piggin, Sat, Oct 04, 2003 01:31:14 +0200:
> 
> Well I can be the editor. I obviously would need people to send me updates.
> 

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

Re: must-fix list reconciliation

[Nick Piggin]

Alex Riesen wrote:

>Nick Piggin, Sat, Oct 04, 2003 01:31:14 +0200:
>
>>Well I can be the editor. I obviously would need people to send me updates.
>>
>>
>
>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.

Re: must-fix list reconciliation

[Mike Fedyk]

On Sat, Oct 04, 2003 at 11:54:15AM +0200, Alex Riesen wrote:
> Nick Piggin, Sat, Oct 04, 2003 01:31:14 +0200:
> > 
> > Well I can be the editor. I obviously would need people to send me updates.
> > 
> 
> assuming they don't send you updates, what will you do?
> Can you monitor lkml on regular basis?

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