All of lore.kernel.org
 help / color / mirror / Atom feed
* keep in sync with -mm tree?
@ 2005-11-08  2:35 Coywolf Qi Hunt
  2005-11-08  2:50 ` Andrew Morton
  0 siblings, 1 reply; 7+ messages in thread
From: Coywolf Qi Hunt @ 2005-11-08  2:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux

Hello,

We can always keep in sync with the current Linus tree through his git
tree. But from where can we keep in sync with the current -mm tree?
ie, when somethings added to -mm, how do we get that too?

The only way now seems to check the mm-commits list. Is it possible to
expose akpm's working folder somewhere for convenience?
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
  2005-11-08  2:35 keep in sync with -mm tree? Coywolf Qi Hunt
@ 2005-11-08  2:50 ` Andrew Morton
  2005-11-08  3:15   ` Paul Jackson
  0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2005-11-08  2:50 UTC (permalink / raw)
  To: Coywolf Qi Hunt; +Cc: linux-kernel

Coywolf Qi Hunt <coywolf@gmail.com> wrote:
>
> Hello,
> 
> We can always keep in sync with the current Linus tree through his git
> tree. But from where can we keep in sync with the current -mm tree?
> ie, when somethings added to -mm, how do we get that too?

You can't.  The patches in -mm spend 90% of their time in an untested,
often-doesn't-compile state.  It's only in the 24-48 hours preceding a
release that I actually start build- and run-time testing it all.

> The only way now seems to check the mm-commits list. Is it possible to
> expose akpm's working folder somewhere for convenience?

Well I suppose I could upload stuff to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ daily.  Then it's
trivial to install mm-of-the-day as a quilt series.

<does crontab -e>

Let me know how it goes..

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
  2005-11-08  2:50 ` Andrew Morton
@ 2005-11-08  3:15   ` Paul Jackson
  2005-12-02  3:22     ` Coywolf Qi Hunt
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Jackson @ 2005-11-08  3:15 UTC (permalink / raw)
  To: Andrew Morton; +Cc: coywolf, linux-kernel

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ 

Cool - thanks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
       [not found] ` <56rSs-mJ-3@gated-at.bofh.it>
@ 2005-11-08  8:26   ` Reuben Farrelly
  2005-11-08  8:39     ` Andrew Morton
  2005-11-09  0:27     ` Paul Jackson
  0 siblings, 2 replies; 7+ messages in thread
From: Reuben Farrelly @ 2005-11-08  8:26 UTC (permalink / raw)
  To: Andrew Morton, Linux Kernel

On 8/11/2005 4:00 p.m., Andrew Morton wrote:
> Coywolf Qi Hunt <coywolf@gmail.com> wrote:
>> Hello,
>>
>> We can always keep in sync with the current Linus tree through his git
>> tree. But from where can we keep in sync with the current -mm tree?
>> ie, when somethings added to -mm, how do we get that too?
> 
> You can't.  The patches in -mm spend 90% of their time in an untested,
> often-doesn't-compile state.  It's only in the 24-48 hours preceding a
> release that I actually start build- and run-time testing it all.

Would it be at all useful if a small (and for feedback purposes only possibly 
known) subset of users were to give the -mm releases a basic compile and build 
before a proper -mm is released?  ie in the 24 hours preceding a formal -mm 
release, to shake out the most obvious brown paper bag problems?  I know -mm 
is a testbed but still, it must surely be better if the big bulk of those 
(unknown number x) people who try it don't need to further patch it to get it 
to at least build.  It also allows comments like "EDAC is known to not compile 
on i386 with SMP, we are bugging Alan already about it" to be clearly stated 
at the time it is released.

Personally I seem to have my share of compile, symbol and oopses that are 
fairly obvious and are visible within 5 mins of booting up, and I'd be willing 
to spare 15 mins once every couple of weeks or so to do a primitive regression 
test on this and report back.  I can build on i386 and possibly x86_64 if need be.

Andrew, what do you think?

>> The only way now seems to check the mm-commits list. Is it possible to
>> expose akpm's working folder somewhere for convenience?
> 
> Well I suppose I could upload stuff to
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ daily.  Then it's
> trivial to install mm-of-the-day as a quilt series.
> 
> <does crontab -e>
> 
> Let me know how it goes..

Last time I tried a broken-out- tarball I ended up watching a heap of fuzzy 
apply's then a part of the patch which was entirely rejected, leaving only the 
first half of the broken-out mm patch applied and my tree in a busted half 
patched state.  Not terribly surprising, but at that point I wasn't sure 
whether the feedback was useful or not...  (and sure enough the next day 40 
more patches were applied so I figure it wasn't 8) ).

reuben

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
  2005-11-08  8:26   ` Reuben Farrelly
@ 2005-11-08  8:39     ` Andrew Morton
  2005-11-09  0:27     ` Paul Jackson
  1 sibling, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2005-11-08  8:39 UTC (permalink / raw)
  To: Reuben Farrelly; +Cc: linux-kernel, Coywolf Qi Hunt

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>

Please retain the cc line.

> On 8/11/2005 4:00 p.m., Andrew Morton wrote:
> > Coywolf Qi Hunt <coywolf@gmail.com> wrote:
> >> Hello,
> >>
> >> We can always keep in sync with the current Linus tree through his git
> >> tree. But from where can we keep in sync with the current -mm tree?
> >> ie, when somethings added to -mm, how do we get that too?
> > 
> > You can't.  The patches in -mm spend 90% of their time in an untested,
> > often-doesn't-compile state.  It's only in the 24-48 hours preceding a
> > release that I actually start build- and run-time testing it all.
> 
> Would it be at all useful if a small (and for feedback purposes only possibly 
> known) subset of users were to give the -mm releases a basic compile and build 
> before a proper -mm is released?  ie in the 24 hours preceding a formal -mm 
> release, to shake out the most obvious brown paper bag problems?  I know -mm 
> is a testbed but still, it must surely be better if the big bulk of those 
> (unknown number x) people who try it don't need to further patch it to get it 
> to at least build.  It also allows comments like "EDAC is known to not compile 
> on i386 with SMP, we are bugging Alan already about it" to be clearly stated 
> at the time it is released.
> 
> Personally I seem to have my share of compile, symbol and oopses that are 
> fairly obvious and are visible within 5 mins of booting up, and I'd be willing 
> to spare 15 mins once every couple of weeks or so to do a primitive regression 
> test on this and report back.  I can build on i386 and possibly x86_64 if need be.
> 
> Andrew, what do you think?

Maybe.  I'll take a look at uploading a nightly rollup as well.

> >> The only way now seems to check the mm-commits list. Is it possible to
> >> expose akpm's working folder somewhere for convenience?
> > 
> > Well I suppose I could upload stuff to
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ daily.  Then it's
> > trivial to install mm-of-the-day as a quilt series.
> > 
> > <does crontab -e>
> > 
> > Let me know how it goes..
> 
> Last time I tried a broken-out- tarball I ended up watching a heap of fuzzy 
> apply's then a part of the patch which was entirely rejected, leaving only the 
> first half of the broken-out mm patch applied and my tree in a busted half 
> patched state.

That would be atypicel ;)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
  2005-11-08  8:26   ` Reuben Farrelly
  2005-11-08  8:39     ` Andrew Morton
@ 2005-11-09  0:27     ` Paul Jackson
  1 sibling, 0 replies; 7+ messages in thread
From: Paul Jackson @ 2005-11-09  0:27 UTC (permalink / raw)
  To: Reuben Farrelly; +Cc: akpm, linux-kernel

reuben wrote:
> Last time I tried a broken-out- tarball I ended up watching a heap of fuzzy 
> apply's then a part of the patch which was entirely rejected,

Usually when I see that, it is because I did not religiously get
the exact right 2.6.*-rc* version as a base for the broken-out
patch set.


-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: keep in sync with -mm tree?
  2005-11-08  3:15   ` Paul Jackson
@ 2005-12-02  3:22     ` Coywolf Qi Hunt
  0 siblings, 0 replies; 7+ messages in thread
From: Coywolf Qi Hunt @ 2005-12-02  3:22 UTC (permalink / raw)
  To: Paul Jackson; +Cc: Andrew Morton, linux-kernel

2005/11/8, Paul Jackson <pj@sgi.com>:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/
>
> Cool - thanks.

I find that it is something being there when we don't need, and
missing when we do need. I suggest to let users pull from instead of
akpm push it there. It's a script invoked by users.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-12-02  3:22 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-08  2:35 keep in sync with -mm tree? Coywolf Qi Hunt
2005-11-08  2:50 ` Andrew Morton
2005-11-08  3:15   ` Paul Jackson
2005-12-02  3:22     ` Coywolf Qi Hunt
     [not found] <56rz6-8re-25@gated-at.bofh.it>
     [not found] ` <56rSs-mJ-3@gated-at.bofh.it>
2005-11-08  8:26   ` Reuben Farrelly
2005-11-08  8:39     ` Andrew Morton
2005-11-09  0:27     ` Paul Jackson

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.