Again, I'm at http://www10.software.ibm.com/developerworks/opensource/linux390/april2004_r ecommended.shtml, and in the 'kernel downloads for the "April 2004 stream":' section, I only see links for the full patches as you describe them: linux-2.6.5-s390-base-april2004.tar.gz (MD5) linux-2.6.5-s390-01-april2004.tar.gz (MD5) xipfs612.gz + xipfs622.gz (from: linuxvm.org/patches/index.html) linux-2.6.5-s390-02-april2004.tar.gz (MD5) linux-2.6.5-s390-03-april2004.tar.gz (MD5) Single threaded workqueue patch (from: linux.bkbits.net:8080/linux-2.5/) linux-2.6.5-s390-04-april2004.tar.gz (MD5) linux-2.6.5-s390-05-april2004.tar.gz (MD5)
Apparently I need to go somewhere else to find the per-patch tarballs. Where is that? The current version may very well be "Linus' BK head," but that's not where everyone gets told to go to for Linux/390 patches. Publish some documentation on how to retrieve that and I probably won't be bothering the list much more in the future. If I can find all the pieces to this puzzle, then I'll publish the patches against the current version, as I find time to do them. It would be nicer if they came from the developerWorks site, but oh well. Mark Post -----Original Message----- From: Ulrich Weigand [mailto:[EMAIL PROTECTED] Sent: Friday, July 16, 2004 10:03 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Linux 2.6.7 Patch Status (LONG) Mark Post wrote: > Ummm, no. When you unpack linux-2.6.5-s390-04-april2004.tar.gz, you > get two files, linux-2.6.5-s390-04-april2004.diff, and .readme. Well, yes, but that is the *full* patch. Specifically in order to make back-and-forth porting easier, however, we always provide a *per-problem* (or per-feature as may be) break-up of the big patch into multiple small patches. This can be downloaded by clicking on the *second* 'Download' button; the one with 'per problem' next to it (as I wrote below). > Moreover, there is no way to look at the 47,000 lines of patches in > those files and determine which lines belong to The kerntypes patch > The multicast notifier patch > The zfcp module_exit vs. lun/port object kfree patch > The shared-IPv6-card patch > The lost-dirty-bit fix Very true; and indeed exactly the reason why we provide per-problem patches ;-) > I just want some way of checking which version of a source code module > is considered by the developers to be current. From there, I can > figure out what the 2.6.7 (or whatever) version is supposed to look > like when I'm done. I don't need to see IBM OCO code, or unreleased > features, etc., etc. The 'current' version is the one in Linus' current Bitkeeper head. > If things are to the point where it is feasible (and you make it sound > like it is), I think it may be time to start publishing patch sets > against what ever version is current from kernel.org, and not keep > putting them out against 2.6.5 (or what ever milestone release has > been set). _That_ would make things a lot easier. Our current procedure is to produce patches against Bitkeeper head (ready for inclusion), and backport them (if appropriate) to apply against our developerWorks service stream. We do not generate additional backports against other official kernel releases, because that would be a lot of additional work. Either use the service stream, wait for inclusion in the next official release, or backport yourself ... Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED] ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
