From mats.d.wichmann at intel.com Mon Oct 18 07:13:48 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 Message-ID: Here's the story for LSB 2.0.1: There's a release candidate out for two-week public review which expires 1100 US-Eastern on Oct 21 (Thurs). There's an ISO meeting (or some meeting) beginning the following Monday, so Nick would like to have the document in ISO's hands Friday at the latest. I'm not clear if this is due to Nick's impending absence so he can't manage the submission during that absence - I think it is; the actual deadline is Oct 31 and it will of course take quite some time to be processed and distributed through ISO. We have pre-approval from the FSG board as long as all we do is editorial (no functional changes) plus add s390 and ppc32. If we think we've stuck to that well enough, we don't have to go back to the FSG board for an additonal approval on this. I think I'd like to conduct a conditional e-mail vote on approval for ISO submission, trying to hold the vote via conference call after the two-week timer expires would seem to squeeze what Nick wants to do a bit too much. So let's have a bit of discussion here if there's any needed and then I can call for this vote. Mats From cyeoh at samba.org Mon Oct 18 17:28:52 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 In-Reply-To: References: Message-ID: <16756.24516.462255.804640@rockhopper.ozlabs.ibm.com> At 2004/10/18 07:13-0700 Wichmann, Mats D writes: > I think I'd like to conduct a conditional e-mail vote on > approval for ISO submission, trying to hold the vote via > conference call after the two-week timer expires would > seem to squeeze what Nick wants to do a bit too much. > > So let's have a bit of discussion here if there's any > needed and then I can call for this vote. Is there a diff available of the changes? (even if its just a list of what was changed, rather than diff output if thats not readable). Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From anderson at netsweng.com Mon Oct 18 17:41:56 2004 From: anderson at netsweng.com (Stuart Anderson) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 In-Reply-To: <16756.24516.462255.804640@rockhopper.ozlabs.ibm.com> References: <16756.24516.462255.804640@rockhopper.ozlabs.ibm.com> Message-ID: On Tue, 19 Oct 2004, Christopher Yeoh wrote: > Is there a diff available of the changes? (even if its just a list of > what was changed, rather than diff output if thats not readable). It might be a bit tedious, but "cvs diff -r LSB_2_0" on the .txt version of the documents (ie LSB-generic.txt) will give you the changes. For the generic book, the changes weren't as hard to read as I thought they might be. Milage may vary on the other books 8-). Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From cyeoh at samba.org Mon Oct 18 17:50:22 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 In-Reply-To: References: <16756.24516.462255.804640@rockhopper.ozlabs.ibm.com> Message-ID: <16756.25806.807250.973618@rockhopper.ozlabs.ibm.com> At 2004/10/18 20:41-0400 Stuart Anderson writes: > On Tue, 19 Oct 2004, Christopher Yeoh wrote: > > > Is there a diff available of the changes? (even if its just a list of > > what was changed, rather than diff output if thats not readable). > > It might be a bit tedious, but "cvs diff -r LSB_2_0" on the .txt version > of the documents (ie LSB-generic.txt) will give you the changes. For the > generic book, the changes weren't as hard to read as I thought they might > be. Milage may vary on the other books 8-). Ok I'll do that. I think we want a summary anyway of the changes when we release. Is it something we can extract out of the cvs logs? Its something we really need to be keeping track of when making changes. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From mats.d.wichmann at intel.com Mon Oct 18 18:12:49 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 Message-ID: >> Is there a diff available of the changes? (even if its just a list of >> what was changed, rather than diff output if thats not readable). > >It might be a bit tedious, but "cvs diff -r LSB_2_0" on the >.txt version >of the documents (ie LSB-generic.txt) will give you the >changes. For the >generic book, the changes weren't as hard to read as I thought >they might >be. Milage may vary on the other books 8-). Hmmm, maybe we should make those available. Otherwise, the tracking bug contains what was requested, and subsequently fixed, although not always the exact wording of the change. http://bugs.linuxbase.org/show_bug.cgi?id=473 From mats.d.wichmann at intel.com Mon Oct 18 18:11:39 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 Message-ID: >> It might be a bit tedious, but "cvs diff -r LSB_2_0" on the >.txt version >> of the documents (ie LSB-generic.txt) will give you the >changes. For the >> generic book, the changes weren't as hard to read as I >thought they might >> be. Milage may vary on the other books 8-). > >Ok I'll do that. I think we want a summary anyway of the changes when >we release. Is it something we can extract out of the cvs logs? Its >something we really need to be keeping track of when making changes. Yes, we need to get much better at producing documentation of changes for each release. From ajosey at rdg.opengroup.org Tue Oct 19 23:03:50 2004 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Approving LSB 2.0.1 In-Reply-To: Wichmann, Mats D's message as of Oct 18, 7:13am. References: Message-ID: <1041020060350.ZM19758@skye.rdg.opengroup.org> hi Mats I diff'd the text versions of lsb-core and as far as I can see the changes appear to be primarily stylistic/shallification for ISO adoption. So I have no objections to the release candidate being put forward. regards Andrew From mats.d.wichmann at intel.com Wed Oct 20 14:52:09 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again Message-ID: So how about those approval votes again? From anderson at netsweng.com Wed Oct 20 17:57:13 2004 From: anderson at netsweng.com (Stuart Anderson) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again In-Reply-To: References: Message-ID: On Wed, 20 Oct 2004, Wichmann, Mats D wrote: > > So how about those approval votes again? I approve!!! Stuart Stuart R. Anderson anderson@netsweng.com Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From cyeoh at samba.org Wed Oct 20 19:13:42 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again In-Reply-To: References: Message-ID: <16759.6998.854591.340279@rockhopper.ozlabs.ibm.com> At 2004/10/20 14:52-0700 Wichmann, Mats D writes: > > So how about those approval votes again? I approve, but I do note that section 4.1 isn't needed anymore as its specified exactly the same in FHS 2.3 (ie there is no longer any need to override the FHS here) Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From heffler at us.ibm.com Thu Oct 21 07:08:58 2004 From: heffler at us.ibm.com (Marvin Heffler) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again In-Reply-To: Message-ID: I approve the official released of LSB 2.0.1. Regards, Marvin Heffler Linux Standard Base IBM Linux Technology Center 11501 Burnet Road, Zip 905-7A017 Austin, TX 78758 (512) 838-0953 T/L 678-0953 lsb-sc-bounces@base3.freestandards.org wrote on 10/20/2004 04:52:09 PM: > > So how about those approval votes again? > > > _______________________________________________ > Lsb-sc mailing list > Lsb-sc@mail.freestandards.org > http://mail.freestandards.org/mailman/listinfo/lsb-sc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20041021/65ab6e4c/attachment.htm From mats.d.wichmann at intel.com Thu Oct 21 07:40:56 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again Message-ID: >At 2004/10/20 14:52-0700 Wichmann, Mats D writes: >> >> So how about those approval votes again? > >I approve, but I do note that section 4.1 isn't needed anymore as >its specified exactly the same in FHS 2.3 (ie there is no longer >any need to override the FHS here) > >Chris Seems like we should file that as a tracker. I'm not too concerned at the moment, as we already have a bit of an ISO issue with normative references that are not themselves at the level of international standards - FHS falls in this category. Nick has hinted that for ISO, we might have to pull more of this material into the spec rather than less. For the future of the LSB, however, we don't want to continue to duplicate material. I'm ready to vote approval as well. I count the current votes as: In Favor: Andrew Josey, Stuart Anderson, Marvin Heffler, Chris Yeoh, Mats Wichmann Opposed: none No vote yet: Matt Taggart So once the clock expires on the review period (as I write this another 35 minutes) I think we're ready to call it released. From mats.d.wichmann at intel.com Thu Oct 21 07:38:46 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] xml subproject Message-ID: I'd like to ask the LSB SC if it's willing to create an XML subproject on an interim/incubator basis. There's been a fair bit of kicking this potato around, the FSG seems to think it belongs under LSB and the LSB thinks it belongs under FSG. Meanwhile, a group of people are ready and willing to work on an apparently useful project if only they can have a home to do so. The sense of urgency now is that there's an XML conference coming up which in early Nov which would be a useful vehicle for the group getting rolling again (there have been some interim fits and starts, nothing permanent), if they had a home. I've enclosed some snips from earlier discussion on this. Note that when Mark tried to pitch this to FSG quite a while back, he was trying to get funded to run it; this is no longer necessary but may be a factor why the FSG is not terribly interested at the moment. It may also not look "big" enough for the FSG right now, I don't know. Comments? We could create this with some guidelines about how it could change status from interim to permament, either under LSB or to propose moving to FSG... or we could just leave it in limbo. Mark Johnson has done a lot of work thinking about how this could work, he even wrote up a possible Process Model, linked here: http://dulug.duke.edu/~mark/lsb/ Mats === 1. Introductory material === I've been working for the past couple years (w/ support from freestandards) to establish an LSB-XML/SGML workgroup tasked with developing an XML (& SGML) module for LSB. However, we've not been successful in forming the workgroup as I was (at the time) seeking salary support for managing such a workgroup. At present I'm able to manage the group w/o any sort of external funding through freestandards. Rationale for Workgroup: The present implementations of XML (policies for file placement, directory structure, and the implementation of the OASIS XML Catalogs spec [1]) on linux systems vary widely, and most are not scalable when considering the installation (and downloading) of XML resources. We need a standard way to register packaged XML resources in the the (as yet unstandardized implementation of) XML Catalog system, as well as a stamdard means to cache XML resources retrieved from the network. What we need is workgroup whose goal is to address the issues I've mentioned (plus other, outstanding issues). Given that all of inquiries I've made to freetandards on this issue have, at present, remain unanswered, I'm hoping someone on this list may be able to provide me with some specific contact info for someone at freestandards.org I, and many others, feel that this is an important issue and that should become part of LSB. Any help here would be appreciated. [1] http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml-cat alogs-1.0_2e.html === 2. Past Proposals === FWIW, I've previously completed the major steps/required documents: FSG102-1 PROBLEM DECLARATION AND SOLUTION ABSTRACT FSG102-2b TECHNICAL GOALS OUTLINE FSG102-3a CORE PARTICIPANTS LIST FSG103-3b TASK OUTLINE The proposal itself [1] addresses the above issues, but needs to updated, since I'm no longer requesting salary support, and my contact info has changed. Also the list of core particpants will likely have changed: [1] http://www.dulug.duke.edu/~mark/fsg/fsg-proposal.pdf FSG103-3c INTERIM WORKGROUP CHAIRPERSON --------------------------------------- For statements of support, see list archives following my RFC: https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2002-April/thread.ht ml FSG103-3d FLESH OUT FURTHER DETAILS ----------------------------------- In addition to the above, I've written a relatively complete draft of a Process Model [2] for the workgroup, the lack of which is one of the main reasons the previous informal attempt failed. [2] http://www.dulug.duke.edu/~mark/lsb-proposal/ Yes, and I do agree with Chris Yeoh who pointed out in a follow-up message that some of the content of the module (file placement & directory structure) should rightfully be contained in the FHS. The resulting WG can identify these bits and make recommendations to the FHS for inclusion in future releases. To summarize, then, all I really need at this point is some sort of go-ahead from FreeStandards to proceed with the formal process of resubmitting the documents, identifying a current list of core participants, and updating the various other components of the workgroup application process. At the very least, we (Dennis Grace & I) could really use either: (a) the password to the current mailing list, or (b) a new list, say , & password so that we may move the subscriber list over from the defunct Duke list and resume the discussion. === 3. Followup email with more details I had a very productive telephone conversation with Jim Zemlin last Friday [Note: this was sent in early August], and we felt it would be a good idea to consider pursuing the formation of the proposed LSB sub-wg. Considering the ubiquitousness of XML for data transport, documentation, config files, etc., and the pivotal role of Linux this century, I feel that it's absolutely essential that LSB contain a module that addresses the implementation of XML (and SGML, to a lesser degree) on LSB systems. XML has now become the wrapper of choice that truly makes data portability a reality, and is being widely adopted in the enterprise and by developers - not to mention DocBook XML as the de facto standard for software documentation. But enough propaganda, what follows are some of the issues that need to be addressed. The major problem areas that such a module would address are: - an XML catalogs [1] implementation standard ------------------------------------------- XML Catalogs provide a means to locate XML resources on the local filesystem, even if they are identified by external URLs, for example. At this point I believe that only Debian has an implementation that will scale as the proliferation of XML resources leads to large-scale installation of XML resources on local machines, yet even Debian's model [2] (which I helped develop) is incomplete. Another component that will be related to the XML catalog system is the local caching of resources retrieved from the network, and their registration in the catalog system. - Standard for caching retrieved resources ---------------------------------------- This was pointed out above in the context of XML catalogs, but it merits serious attention in its own right. - Standards for Filesystem Installation Location & Directory Structures --------------------------------------------------------------------- The function of the group on this topic would be to reach an informed consensus to then pass to the FHS for inclusion in their next revision. - Standards (or Recommendations) for Packaging Tools for Catalog Registration ------------------------------------------------------------------------ --- Currently, this is a major PITA and is keeping many XML resources from being packaged. The catalog registration process needs to be standardized and tools (or interfaces) need to be defined that simplify the packaging of XML resources. (I feel the pain first-hand, as I package for both Debian & Red Hat.) In addition, there are smaller items like naming conventions of config files, and naming/version-numbering conventions for packages. I look forward to hearing from you and hope we can all move forward in establishing an XML/SGML module of LSB. BTW, you're not supposed to be reading this - you're on vacation:-) Cheers, Mark [1]http://www.oasis-open.org/committees/download.php/4952/wd-entity-xml- catalogs-1.0_2e.html [2]http://debian-xml-sgml.alioth.debian.org/xml-policy P.S. Below my signature I've pasted in some content from a previous proposal to freestandards, although it repeats much of what I've said above, it's a bit more organized and may be useful to you when communicating with others about this potential LSB sub-WG. -- ____________________________________________________________ Mark Johnson Debian XML/SGML: Home Page: GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242 ---------------=====================---------------- b. Technical Goals: =================== * Content of Proposed Specification ----------------------------------- The primary goal is to develop a complete, well-designed, cross-distribution implementable component of the LSB specification that focuses on SGML, XML, and related standards and tools. The proposed standard/subspecification should include (but is not limited to) policies relating to: - directory layout and naming conventions for SGML and XML base infrastructure files and directories - directory layout/naming conventions and file placement for standard XML/SGML resources such as stylesheets (DSSSL & XSL), DTDs, and other schema-related packages. - TR9401:1997[3] catalog[1] implementation for both XML and SGML resources, such as XML & SGML DTDs and DSSSL stylesheets. This standard has been in widespread use for some time now and is successfully implemented on most Linux distributions. - XML Catalog implementation: This OASIS specification [viii] is relatively new and has not yet been successfully implemented by all major Linux distributions. The proposed sub-spec will address and standardize a number of issues related to this specification. Examples here are catalog naming conventions, filesystem placement, and interfaces for registering/deregistering XML-related resources as are typically implemented in package installation scripts. - suggested assignment of PUBLIC identifiers (for TR9401 catalogs) and SYSTEM identifiers (for XML catalogs) to resources such as stylesheets and DTDs when none are provided by the distributor/developer of such resources. - caching mechanisms for resources retrieved non-locally (i.e. from the network) - XML catalog registration/deregistration mechanisms for cached resources - configuration files: naming conventions, filesystem locations, and a suitable definition so that packagers/developers can determine what files are even eligible for configuration file status. - naming and version-based numbering schemes for packages, including a policy regarding cumulative schema-related packages. For example, the Debian 'docbook' package contains SGML versions numbering from 2.0 to 4.1.2, while RedHat uses a combination of cumulation and separate packages for different versions. ---------------=====================---------------- From taggart at carmen.fc.hp.com Thu Oct 21 11:29:05 2004 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again In-Reply-To: References: Message-ID: <20041021182905.868A337D1E@carmen.fc.hp.com> "Wichmann, Mats D" writes... > I count the current votes as: > In Favor: Andrew Josey, Stuart Anderson, Marvin Heffler, > Chris Yeoh, Mats Wichmann > Opposed: none > No vote yet: Matt Taggart Approve. -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From cyeoh at samba.org Thu Oct 21 17:34:47 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] xml subproject In-Reply-To: References: Message-ID: <16760.21927.544799.626390@rockhopper.ozlabs.ibm.com> At 2004/10/21 07:38-0700 Wichmann, Mats D writes: > > I'd like to ask the LSB SC if it's willing to > create an XML subproject on an interim/incubator > basis. There's been a fair bit of kicking this > potato around, the FSG seems to think it belongs > under LSB and the LSB thinks it belongs under > FSG. Meanwhile, a group of people are ready and > willing to work on an apparently useful project > if only they can have a home to do so. I think its a good idea to start it off as a subproject. If everything works out well, eventually it can just move it to the FSG as its own workgroup. At least it will give them a a framework to start work within. And if nothing ends up happening (like seems to be happening with packaging), then there wasn't a lot of wasted effort on the FSG's part. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From cyeoh at samba.org Thu Oct 21 17:43:41 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] LSB 2.0.1 again In-Reply-To: References: Message-ID: <16760.22461.596729.704667@rockhopper.ozlabs.ibm.com> At 2004/10/21 07:40-0700 Wichmann, Mats D writes: > > Seems like we should file that as a tracker. I'll submit a bug report. > I'm not too concerned at the moment, as we already > have a bit of an ISO issue with normative > references that are not themselves at the level > of international standards - FHS falls in this > category. Nick has hinted that for ISO, we might > have to pull more of this material into the spec > rather than less. > > For the future of the LSB, however, we don't want > to continue to duplicate material. Yes, I'd like to if at all possible, avoid duplicating information. And it will be a pain for the LSB to have to resync with FHS when it gets updated, especially if there are language changes which aren't reflected in the FHS. Duplication can be a bit confusing for the reader, because they start looking for what the differences are between the two documents and can't find any. Anyone want to volunteer to help cleanup the wording in the FHS? Its possible I could push for a new release which doesn't change anything except tighten the language. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From gk4 at swbell.net Fri Oct 22 08:07:48 2004 From: gk4 at swbell.net (George Kraft) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] xml subproject In-Reply-To: <16760.21927.544799.626390@rockhopper.ozlabs.ibm.com> References: <16760.21927.544799.626390@rockhopper.ozlabs.ibm.com> Message-ID: <1098457668.4733.27.camel@gkraft4.austin.ibm.com> Shouldn't "xml" follow the new LSB "module" approach? The FSG should parent it, and the LSB consume it when it is ready. I don't think the LSB has resources to take on new responsibilities to mentor a new subproject which does not directly impact runtime compatibility of applications. The LSB needs to focus on C++, ISO, desktop APIs, test suite expansion, and most importantly ISV adoption. My 2 cents. :-) Why isn't this an enhancement to the FHS? :-) George (gk4) From cyeoh at samba.org Sat Oct 23 19:53:34 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] xml subproject In-Reply-To: <1098457668.4733.27.camel@gkraft4.austin.ibm.com> References: <16760.21927.544799.626390@rockhopper.ozlabs.ibm.com> <1098457668.4733.27.camel@gkraft4.austin.ibm.com> Message-ID: <16763.6446.748647.838223@gargle.gargle.HOWL> At 2004/10/22 10:07-0500 George Kraft writes: > Shouldn't "xml" follow the new LSB "module" approach? The FSG > should parent it, and the LSB consume it when it is ready. I don't > think the LSB has resources to take on new responsibilities to > mentor a new subproject which does not directly impact runtime > compatibility of applications. The LSB needs to focus on C++, ISO, > desktop APIs, test suite expansion, and most importantly ISV adoption. > My 2 cents. :-) > > Why isn't this an enhancement to the FHS? :-) There is definitely a component which should be submitted to the FHS for inclusion. However, from previous descriptions there are also interfaces and tools which need to be standardised. And these parts do not belong in the FHS. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia