> 2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: > >> > > >> > I don't like the idea of changing "UI" (e.g. command line options that > >> > might be used by some users) without very well-thought reasoning. > >> > >> This is not an UI. AFAIK, this script is not shipped to the user. I > >> don't even see what a user could do with it. > >> > >> > > > > Well, the Perl script _is_ shipped in the official release > > My bad. I only checked the debian packages, none of them include a > file named checksize.pl. > I just checked the official release, it actually include the whole > source tree. Does that mean we can't change any argument of the shell > or perl scripts or any target of the Makefiles? > Of course not. > > > > >> > > >> > In the particular case of "padsize" vs. "maxsize" (options / parameters > >> > of the Perl script), there used to be a separate use of them. Although > >> > there _seems_ to be no use for having both of them simultaneously at > >> > this time _for a normal build of Syslinux_, we cannot discard / > >> > disregard the possibility that some script in some distro might want to > >> > take advantage of each of them independently, especially for some > >> > debugging situation (e.g. some buggy / old BIOS). > >> > > >> > Another potential (hypothetical) use-case might be some "bootable USB > >> > tool" making use of some/many/all parts of the Syslinux code. Let's not > >> > forget that some distros are still using older versions of Syslinux > >> > (even v. 3.xx), and (unnecessarily) changing command line options makes > >> > the updates (unnecessarily) more difficult, generally speaking. > >> > >> Keeping some legacy in the compilation chain for a potential usage > >> we're not even aware about seems a bit insane. If someone play with > >> the syslinux's internal compilation process, he is probably aware that > >> it may change completely on every single commit. We just do not > >> support this usage. > >> > > > > The example I gave (moving the location of binary files) could also be > > included in such category; > No. > I specified "in the compilation chain". Because this script is only > this: one tool used to build the binaries. Same would go for the > following files: > - efi/wrapper.c > - lzo/prepcore.c > - core/lstadjust.pl > - utils/bin2hex.pl > - **/*.pl > > They're all just some custom tools when a single shell line in the > Makefiles would be too clumsy. > > > > Best regards, > CelelibiI seem to be failing to express my point clearly. I'll try one last time. My comments were generic, not specific to the patch, nor to the Perl script. Previous proposed patches (before the one about the checksize.pl script) sent by Nico don't seem to have interaction with external factors (although, there was at least one factor that was taken in consideration in a later commit, after I brought it up in irc #syslinux). If I am not mistaken, dependencies (e.g. mtools) and (root) privileges were not changed in prior proposed patches, neither parameters used in scripts nor user input. Being part of the arguments of the current normal procedures for building Syslinux (whether in use or not), or some optional script, or some file location, are some of the many examples in which there is some kind of interaction (between scripts, users, third-party tools...). The proposed patch for the checksize.pl script changes the potential arguments. In the current context of these comments, which are _generic_, I do not care whether the code is improved, nor whether the optional parameter that was eliminated was not being normally used in the current building steps. The only thing I am focusing on in my present comments is that there is some kind of interaction, and that it is being changed. The assumption that "something is not really being used so let's simplify it by eliminating it from the code" is frequently not evaluated to its fullest, and finding that such elimination was not %100 adequate usually takes a lot of effort, including from common users testing the results. When the elimination of code affects some kind of interaction, the effects are even more difficult to predict, and therefore the eventual correction needs even more resources. Instead of "elimination", the action could had been any kind of change related to any kind of interaction, and the main point of my comments would have been the same. I am going to say it again: this is a generic comment, not specific to the patch nor to this Perl script in particular. Some code that is "so clear that it can be improved in a certain manner" for one developer at a certain time / moment might not be so. I can give many examples, including a very recent one in the Syslinux development, but that's besides my point. Considering that: _ Nico is new to the code; and that, _ there are very few developers that actually have enough experience with different (use) cases with the storage-related installers in Syslinux; and that, _ beta testers in Syslinux are also very few; then... ... I decided to comment about what _I_ consider a potential interaction. I am well aware that developers might have a different point of view, and therefore I express this concern of mine _now_. For instance, if someone would had expressed similar concerns when the binaries where moved to the "bios/" sub-directory, _perhaps_ the negative comments and strong complaints (and many, many problems) such move caused (and still causes) _might_ had been re-evaluated. Maybe the resulting decision would had been the same, or maybe not, or maybe the move would had been much better communicated, or maybe package maintainers would had been consulted for suggestions, or... There are other cases of interaction changes that brought some degree of headaches; the "offset" parameter or the use of "-i" for installers are just 2 of them, which I mention because they are clear examples. Other examples were seemingly not so clear at the time, but impact they had. I took this opportunity to express a _generic_ comment / concern, and I do it when it might count for something, before it might be too late. We are all genius after the fact, right? Whether this particular suggested patch could have a minor impact, a greater one, or none at all, is not my main point. After all, the main Syslinux's developers will decide. So, the replies to my comments are being "too-specific", related only to the specific patch, or to the specific current use of the script, as if I had made my comments in direct relation to the particular patch. I don't think I expressed it in such way, and I clearly mentioned the "generality" of my comments several times in all my posts in this email thread. The patch was only a trigger, an excuse, an oportunity. I think I'm done with the matter. Regards, Ady.> _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux >
2015-11-20 12:50 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>:> >> 2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: >> >> > >> >> > I don't like the idea of changing "UI" (e.g. command line options >> >> > that >> >> > might be used by some users) without very well-thought reasoning. >> >> >> >> This is not an UI. AFAIK, this script is not shipped to the user. I >> >> don't even see what a user could do with it. >> >> >> >> >> > >> > Well, the Perl script _is_ shipped in the official release >> >> My bad. I only checked the debian packages, none of them include a >> file named checksize.pl. >> I just checked the official release, it actually include the whole >> source tree. Does that mean we can't change any argument of the shell >> or perl scripts or any target of the Makefiles? >> Of course not. >> >> > >> >> > >> >> > In the particular case of "padsize" vs. "maxsize" (options / >> >> > parameters >> >> > of the Perl script), there used to be a separate use of them. >> >> > Although >> >> > there _seems_ to be no use for having both of them simultaneously at >> >> > this time _for a normal build of Syslinux_, we cannot discard / >> >> > disregard the possibility that some script in some distro might want >> >> > to >> >> > take advantage of each of them independently, especially for some >> >> > debugging situation (e.g. some buggy / old BIOS). >> >> > >> >> > Another potential (hypothetical) use-case might be some "bootable >> >> > USB >> >> > tool" making use of some/many/all parts of the Syslinux code. Let's >> >> > not >> >> > forget that some distros are still using older versions of Syslinux >> >> > (even v. 3.xx), and (unnecessarily) changing command line options >> >> > makes >> >> > the updates (unnecessarily) more difficult, generally speaking. >> >> >> >> Keeping some legacy in the compilation chain for a potential usage >> >> we're not even aware about seems a bit insane. If someone play with >> >> the syslinux's internal compilation process, he is probably aware that >> >> it may change completely on every single commit. We just do not >> >> support this usage. >> >> >> > >> > The example I gave (moving the location of binary files) could also be >> > included in such category; >> No. >> I specified "in the compilation chain". Because this script is only >> this: one tool used to build the binaries. Same would go for the >> following files: >> - efi/wrapper.c >> - lzo/prepcore.c >> - core/lstadjust.pl >> - utils/bin2hex.pl >> - **/*.pl >> >> They're all just some custom tools when a single shell line in the >> Makefiles would be too clumsy. >> >> >> >> Best regards, >> Celelibi > > > I seem to be failing to express my point clearly. I'll try one last > time. > > My comments were generic, not specific to the patch, nor to the Perl > script.I understand your recurring point "don't break the UI". But it's not applicable here because it's not an UI. Regards, Celelibi
On Fri, Nov 20, 2015 at 2:09 PM, Celelibi via Syslinux <syslinux at zytor.com> wrote:> 2015-11-20 12:50 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: > > > >> 2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: > >> >> > > >> >> > I don't like the idea of changing "UI" (e.g. command line options > >> >> > that > >> >> > might be used by some users) without very well-thought reasoning. > >> >> > >> >> This is not an UI. AFAIK, this script is not shipped to the user. I > >> >> don't even see what a user could do with it. > >> >> > >> >> > >> > > >> > Well, the Perl script _is_ shipped in the official release > >> > >> My bad. I only checked the debian packages, none of them include a > >> file named checksize.pl. > >> I just checked the official release, it actually include the whole > >> source tree. Does that mean we can't change any argument of the shell > >> or perl scripts or any target of the Makefiles? > >> Of course not. > >> > >> > > >> >> > > >> >> > In the particular case of "padsize" vs. "maxsize" (options / > >> >> > parameters > >> >> > of the Perl script), there used to be a separate use of them. > >> >> > Although > >> >> > there _seems_ to be no use for having both of them simultaneously > at > >> >> > this time _for a normal build of Syslinux_, we cannot discard / > >> >> > disregard the possibility that some script in some distro might > want > >> >> > to > >> >> > take advantage of each of them independently, especially for some > >> >> > debugging situation (e.g. some buggy / old BIOS). > >> >> > > >> >> > Another potential (hypothetical) use-case might be some "bootable > >> >> > USB > >> >> > tool" making use of some/many/all parts of the Syslinux code. Let's > >> >> > not > >> >> > forget that some distros are still using older versions of Syslinux > >> >> > (even v. 3.xx), and (unnecessarily) changing command line options > >> >> > makes > >> >> > the updates (unnecessarily) more difficult, generally speaking. > >> >> > >> >> Keeping some legacy in the compilation chain for a potential usage > >> >> we're not even aware about seems a bit insane. If someone play with > >> >> the syslinux's internal compilation process, he is probably aware > that > >> >> it may change completely on every single commit. We just do not > >> >> support this usage. > >> >> > >> > > >> > The example I gave (moving the location of binary files) could also be > >> > included in such category; > >> No. > >> I specified "in the compilation chain". Because this script is only > >> this: one tool used to build the binaries. Same would go for the > >> following files: > >> - efi/wrapper.c > >> - lzo/prepcore.c > >> - core/lstadjust.pl > >> - utils/bin2hex.pl > >> - **/*.pl > >> > >> They're all just some custom tools when a single shell line in the > >> Makefiles would be too clumsy. > >> > >> > >> > >> Best regards, > >> Celelibi > > > > > > I seem to be failing to express my point clearly. I'll try one last > > time. > > > > My comments were generic, not specific to the patch, nor to the Perl > > script. > > I understand your recurring point "don't break the UI". But it's not > applicable here because it's not an UI. > > > Regards, > CelelibiYes, it IS a UI. The reason it's a UI is because *every* function and option exposed on the command line IS the "user interface". Debugging switches, arcane and deprecated functionality... EVERYTHING. It DOES NOT MATTER whether it's part of your "production" or merely support code inside the project. It was suggested that no new use cases or goals for the Syslinux project be invented. I'm telling you: it's too late, your customers have already done that without your permission! I can guarantee that for every weird switch or piece of functionality in an executable, there's SOMEONE out there that's used (or abused!) it and depends on it working the way it does. And if you change or remove it without warning, it will break whatever they're doing. My personal opinion is that the audience that uses Syslinux tends to be more clever and investigative than "normal". To me, this means that you need to be even more cautious before you change ANYTHING that might affect them because someone's probably used it in some twisted nasty unexpected way. I believe that Ady has already suggested that various changes made in the past -- that were made with good intentions, remember! -- had negative effects. (Ady, if I'm misinterpreting your meaning, please yell at me!). Ideally, a project should have a standard way of dealing with proposed changes that would affect ANY existing behavior. Maybe it's a timeline for deprecating what's current and then eventually making the proposed change. Or some way to warn your "customers" that something's gonna change soon. Maybe you make the change but also support an older version with the behavior intact so your users have a chance to adapt. Maybe you just create documentation in big letters that says what's subject to change without warning and what's not so they know if they're on shaky ground or not. I know that I've earlier seen on this list instances of people that said they're still using older Syslinux versions because there was some change in later versions that affected them badly and they didn't have a chance to adapt. I don't know what's right for the project, as I'm not a developer on it. I do know that manpower is short -- a reason to be even more cautious because the resources that have to deal with "why did you break this?" complaints are already stretched thin. I've worked on other software, and learned the hard way that people are endlessly creative and WILL use something you've created in unexpected ways, and when you change something you know "that nobody still uses" or "it's internal" or "it's undocumented", you will find that "nobody" on the phone calling you one day to yell at you, probably sooner than later. One of the differentiators between a private project with very few close-knit users and a public project with many disparate users is the way change control is handled. What you do affects other people. A motto I've always tried to follow is: "No bad surprises!" Don't abuse your customers by unexpectedly changing behavior without warning -- even for "internal-only" executables. OK, I've jumped off my soap box. I'll go back to lurking again. If I've said anything wrong or offensive, feel free to say so (heh, I don't think I can stop you).