Keith M Wesolowski wrote: > On Thu, Mar 08, 2007 at 04:03:19AM +0100, Roland Mainz wrote: > > Grumpf... I explained that earlier. Short: The patches generated from > > the upstream sources will no longer apply and we would need to create a > > bullet-proof way to handle "missing" files (which will not be easy > > Am I correct in thinking that your concerns around removing these > files are entirely a result of a belief that the structure of the code > should be optimised for bulk upgrades from an external source base?
No, that's not the only reason (and I would not call this "bulk upgrades" since they contain lots of manual work&&testing to make sure the result is working correctly (e.g. most of the update work is testing, testing, testing until you get rabies when someone uses the "t..."-word ... =:-) )). For example: If we remove the "feature probes" (which build the majority of the "possibly (maybe) unused files"-list) - how can I refresh the generated file "in place" and create a patch for upstream ? The only solution in this case would be to patch the generated file, test this, then fetch the upstream sources, try to fix the probe, then try to reproduce the results with the native built system, make a patch from that and provide this to upstream (e.g. five extra steps and twice the testing work compared to use the probes directly, e.g. the result would be very messy and definately not very productive). BTW: And yes, I expect that we'll update ksh93 in OS/Net very often because we will likely get many new consumers (and therefore may find lots of bugs) and some feature work (like DTrace support) will go through upstream, too (e.g. develop+test in branch, provide to upstream and the final work will appear with the next update in OS/Net (remeber we do not want to fork() the ksh93 sources...)). > It does also seem that there are several separate issues here - for > example, we already have the DTrace Test Suite in ON (and other tests > as well), which is not normally referenced during a build but which is > absolutely relevant to the source *that is built and delivered*. Can we use this precedent for the iffe feature probe scripts ? > Clearly, including in the gate tools which are used only for testing > is an acceptable practice within reason. But I'd like to be sure I'm > understanding the origin of your strong opposition to removing files > such as makefiles which are in no way related to the binaries that are > actually delivered by building your project's bits. My opposition comes from the lessons we learned during the original prototype that something like "... hey, cool... that looks unused - lets remove it..." is a quick&&cheap way to shoot yourself into your toes and noticing it only after some time when your shoes have been filled up with blood and start leaking on the floor. Removing files will only costs us time. Lots of time. Being a volunteer I really like to spend my free time at development of ksh93+followup projects and not finding new innovative ways to add new bugs (and spend even more time to bandage my toes). The Makefiles are only a tiny piece of code but I really fear the _precedent_ generated with a removal or renaming. (Unfortunately (well, maybe not _that_ unfortunately since we've started exploiting this argumentation path for ourselves... ;-/ )) it seems that much of the jutification for changes/additions in OS/Net must be based on either a) a precedent or b) a very very convincing reason and that makes the whole thing look like a dance through a minefield (TM-46). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
