[Meta: This message is being intentionally sent to _both of_ the fossil-users and fossil-dev mailing lists, separately, so as to get the maximum possible feedback and response. I am currently subscribed to both lists and will see any response you send to either of them. You need not cross-post your response to both lists unless you deem it necessary to do so for some reason. You can CC me or not in any response you send to a list. If I've violated list custom by doing this, please flame me off-list.]
[Meta: If you want to skip ahead to what I am proposing / offering to do, go to PROPOSED ACTION ITEM below.] Recently on the fossil-users mailing list, Stephan Beal < sgb...@googlemail.com> started an extensive discussion thread titled "Random thoughts on Fossil v2", which discussed among other things creating a library for core Fossil functionality (I'll refer to it as libfossil2) and one or more user-facing applications which would use this library to provide actual functionality (I'll refer to them collectively as fossil2client). In a response to his original post, I submitted some comments which, among other things, suggested things I thought should be done for such a hypothetical "Fossil v2" so as to make it easier for a Unix / Linux Distribution to package and distribute the library and applications according to the standards and processes they normally use. Some of the things I suggested along this line included: * Fossil2client not requiring or expecting libfossil2 to be compiled / linked into it statically, and that dynamic run-time linking be the expected norm; * The source for fossil2client not having an embedded copy of the source for libfossil2 incorporated within it; * (Unspoken here, but implicit, is that other libraries or sources for libraries, most specifically that for sqlite3, should not be compiled into the fossil2client statically or have a copy of its source incorporated into the source for fossil2client either); * Libfossil2 being implemented in such a way that multiple versions of it can be installed simultaneously on a given system, so that different clients can use different versions of libfossil2 if necessary and all successfully coexist on the system. * Otherwise doing things where possible to make it easier, or at least less difficult / inconvenient, for a Unix / Linux distribution to package and distribute libfossil2 and fossil2client. * In a later response, that "amalgamation builds" not be done or expected to be done. * Also somewhere along here that many of these things might well also apply to the existing fossil (v1) monolithic application, at least insofar as they represented things that Unix / Linux distributions would need to alter and/or undo so as to make that version of fossil conform to whatever their internal standards for the applications they distributed and supported happened to be. In Stephan's response to this, he commented in such a way that it seemed he at least believed that many Unix / Linux distributions wouldn't really care about these things, but would just follow the path of least resistance in terms of generating library and client binaries which they could then distribute to their end-users. I want to emphasize that he did not come across as saying my suggestions were somehow wrong, but that he simply didn't see why anybody would bother doing things other than the easiest or default way as provided by the software as released by the Fossil Project. I believe he is mistaken about this, and that Unix / Linux distributions in general behave in a fashion significantly different than would an individual end-user running on Unix / Linux who was compiling fossil for their own personal or otherwise internal use. I claim they do this because they are acting, albeit generally on a far smaller scale, as an operating system integrator, akin to what Microsoft does for Microsoft Windows or Apple does for MacOS/X, but also on a far larger scale in that they package and directly provide under their own auspices far more software than Microsoft or Apple would ever dream of attempting to directly provide to consumers of Microsoft Windows or MacOS/X. I claim that because of this, Unix / Linux distributions care far more about the uniformity of the software they are accepting responsibility for providing and at least attempting to support because while it costs them more in terms of the effort to initially package a library or application, it ends up saving them much more time down the line in terms of ongoing maintenance and support of the library or application. ***** PROPOSED ACTION ITEM ***** Now, Stephan commented that he was not in a position to go out and find out what sorts of things which could potentially be done by the Fossil Project for a hypothetical fossil v2 (and/or for the existing fossil v1) would or would not be useful to / appreciated by Unix / Linux distributions which were choosing to provide fossil to their end-users. I however am willing to make some effort to do so. I believe it will be of some benefit to the Unix / Linux distributions in general. Further, I believe it will be of benefit to the Fossil Project community and its developers to be educated as to what Unix / Linux distributions need / expect / desire from their upstream software providers (e.g. the people creating the software that the distributions package and distribute to end users), and what sorts of hoops the distributions have to jump through to accomodate software which does not meet their standards (whatever those standards happen to be). However... To do this effectively, I first need some guidance from you all. There are approximately 50 zillion distinct active Linux distributions in the wild, tho only a relative handful of them are of real significance in terms of size of installed userbase, influence on other distributions or significance within the world of computing in general, etc. There's at least a solid handful or two of BSD Unix-derived distributions, tho again they vary in size of userbase, influence, significance, etc. Finally, there are other F/OSS Unix-like or other operating systems out there; the first that come to mind are the competing flavors of Open Solaris (or whatever it's called today). Cygwin might count under this as well; I think there's a F/OSS version of VMS (the one originally developed by DEC); etc. I simply don't have the time or energy to investigate all 50 zillion Linux distributions. While the BSD Unix-derived and other Unix and non-Unix distributions are a much more manageable number, I don't want to bother with ones which the Fossil Project and its primary developers / contributors don't care about, because that seems like a waste of time to me. Therefore: ---> I would like to know what Unix / Linux distributions (and if applicable non-Unix distributions) the Fossil Project cares about, in terms of fossil AS PACKAGED AND DISTRIBUTED BY THE DISTRIBUTION. <--- I am specifically *not* speaking of a distribution just taking and redistributing the pre-compiled fossil binaries as distributed by the Fossil Project itself (I doubt there's any that do so). Instead, I am speaking of a distribution taking the source code to fossil (as said source code is distributed by the Fossil Project as a tarball or whatever), making whatever modifications to the source code the distribution finds necessary to make, compiling and linking the resulting source code to create executable binary files, and then redistributing the resulting executable binary files and/or modified source code to the users of that distribution. I want to know what distributions that do this sort of thing are important to the Fossil Project and its primary developers, in that the Fossil Project would like to make (or at least learn what would make even if the Fossil Project is unwilling / unable to do those changes) that distribution's life easier, would like the distribution to package and distribute fossil if they do not currently do so, and would otherwise like to learn more about the distribution and how the distribution views fossil. This will let me know what I should focus my energy on, at least to begin with. Once I find out from you all what distributions I should focus on, I will seek to find out for you: * How the distribution takes the source to fossil v1 as distributed by The Fossil Project, what modifications if any it makes to the source code, build system, etc, and how it packages and distributes the result to end users (assuming it does in fact distribute fossil, of course); * Any statistics the distribution has on how many of its users use fossil as packaged by the distribution, information on what version of fossil they are currently distributing, how well they seem to be keeping up with past and new releases, etc; * General policies and procedures the distribution has for the applications it packages and distributes, such as for instance policies towards embedded copies of library source code, etc; * Any information the distribution has for its upstreams, as to how the upstream can better and more usefully interact with the distribution, and/or what the distribution can do for the upstream; * Any information available on the normal C compiler used by the distribution for compiling C programs it packages; normally this will be some version of GCC, but some distributions might use alternative C compilers such as clang; * Any sorts of information you all indicate you would like to know or would find of use or interest; * Any other information that looks like it might be of interest or importance. I will make it quite clear in my inquiries that I am NOT speaking, in any way whatsoever, as part of the Fossil Project but solely as an interested bystander not otherwise affiliated with the project. I will make it quite clear that I am NOT committing the Fossil Project to do, or not do, anything whatsoever. I intend to keep you all in the loop in inquiries I send to the maintainer / packager of fossil for various distributions (generally by CCing one of the lists), and (unless you all say otherwise) I will invite the maintainer to contact the Project directly via its mailing lists (would you prefer fossil-users or fossil-dev?) with any response the maintainer cares to make. A few suggestions for distributions the Fossil Project might wish to consider saying "We care about this distribution and its packaging and distribution of fossil" are: * The Debian Project -- http://www.debian.org/ * Ubuntu Linux in its various flavors -- http://www.ubuntu.com/ -- largely derived from Debian but big enough on its own to be considered a first-class distribution, both commercial and non-commercial * The Fedora Project -- http://fedoraproject.org/ -- this is sponsored by Red Hat * Red Hat Enterprise Linux (RHEL), and its derivations CentOS and Scientific Linux (SL) -- http://www.redhat.com/products/enterprise-linux/ , http://www.centos.org/ , https://www.scientificlinux.org/ -- RHEL is commercial, CentOS and SL are non-commercial repackagings and redistributions of RHEL (as allowed by applicable software licenses) * OpenSUSE -- http://www.opensuse.org/en/ -- this is sponsored by Novell * SUSE Linux -- https://www.suse.com/ -- also by Novell, commercial * FreeBSD Project -- http://www.freebsd.org/ -- I believe this is the most popular BSD Unix variant out there, at least as FOSS. So, anyway, that's what I'm offering to do for you all, at least if you want it. Let me know if you do want it, and if so how. Thanks for giving me some of your time by reading this (lengthy, I know) message. I hope you've found it of some use, interest. Be well. Joseph
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
