[parisc-linux] Re: [parisc-linux-cvs] build-tools bame

[parisc-linux] Re: [parisc-linux-cvs] build-tools bame

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

On Tue, 2003-05-13 16:21:02 -0600, Paul Bame <bame@dsl2.external.hp.com>
wrote in message <20030513222102.33F00482D@dsl2.external.hp.com>:
> CVSROOT:	/var/cvs
> Module name:	build-tools
> Changes by:	bame	03/05/13 16:21:02
> 
> Added files:
> 	.              : cvs-mkpatch 
> 
> Log message:
> initial rev -- make patch from modified cvs dir

...as if you had read my thoughts, I'm currently planing a roadmap for
pushing all ports upstream to Linus and looking for what work I could
do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and
comment on it!


Ob, I'm still waiting for your lock to vanish:

cvs server: [08:07:34] waiting for bame's lock in /var/cvs/obsolete/binutils-2.10
cvs server: [08:08:04] waiting for bame's lock in /var/cvs/obsolete/binutils-2.10
cvs server: [08:08:34] waiting for bame's lock in /var/cvs/obsolete/binutils-2.10


Please remove the lock or the whole ./obsolete/ directory.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [parisc-linux] Re: [parisc-linux-cvs] build-tools bame

[Matthew Wilcox]

On Wed, May 14, 2003 at 12:39:02AM +0200, Jan-Benedict Glaw wrote:
> ...as if you had read my thoughts, I'm currently planing a roadmap for
> pushing all ports upstream to Linus and looking for what work I could
> do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and
> comment on it!

Well, it seems like a complete lie to me.

I think pretty much every architecture on your `really small userbase'
list would take issue with being placed there.  In particular, I think
PPC is the second-largest Linux userbase after x86.

The PA-RISC port doesn't have much in the way of tweaks to common drivers.

I don't understand why you say for 2.4:

"Nearly up to date, many patches need to go upstream"

and for 2.5:

"Not really up to date, but not far away; some work needs to be done..."

I don't know whether you're claiming the kernel.org tree is uptodate or
whether our repository is up to date.  Neither statement seems true for
either case.  

-- 
"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: [parisc-linux] Re: [parisc-linux-cvs] build-tools bame

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

On Tue, 2003-05-13 23:50:22 +0100, Matthew Wilcox <willy@debian.org>
wrote in message <20030513225022.GQ29534@parcelfarce.linux.theplanet.co.uk>:
> On Wed, May 14, 2003 at 12:39:02AM +0200, Jan-Benedict Glaw wrote:
> > ...as if you had read my thoughts, I'm currently planing a roadmap for
> > pushing all ports upstream to Linus and looking for what work I could
> > do. Please read it at http://www.lug-owl.de/~jbglaw/linux-ports/ and
> > comment on it!
> 
> I think pretty much every architecture on your `really small userbase'
> list would take issue with being placed there.  In particular, I think
> PPC is the second-largest Linux userbase after x86.

I'm not looking for "mainstream" parts (like current PowerMACs) but for
the ports/boards which are problematic. And some of the rare boards *do*
have problems. For MIPS, even some boards got removed some time ago and
there are more which may follow. So please, don't get me wrong here.
Some boards do work quite good most og the time (taking current port's
source trees), some do not. Simply take it as "PeeCee is less bug prone
than my super-rare MIPS/PPC/whatever eval board".

> The PA-RISC port doesn't have much in the way of tweaks to common drivers.

"Not much" means there are some. These should go upstream at some time,
or we may need to get a better way to deal with specific things. As the
(E)ISA bus in Indigo2 is getting available, there may be some things
that need to get cleaned up in ISA code. Soma counts here...

> I don't understand why you say for 2.4:
> 
> "Nearly up to date, many patches need to go upstream"

Everything synced up (maybe except yesterday's work)?

> and for 2.5:
> 
> "Not really up to date, but not far away; some work needs to be done..."

Well, I think it's basically about accepting or not accepting the fact
that some archs/boards are being developed without syncing "too early"
with upstream. This leads to:

	- I need to have more than one source tree laying around.
	- Unintended breakages show up too late.
	- Unintended conflicts may arise from syncing up later than
	  "now".

For me, I'd like to have _one_ tree which works in all situations
(except yesterday's work...). While whining for that, I'm also asking
for hints what _I_ can do to make this happen. Parisc is even one of the
more "simpler" ports to sync up...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]