From taggart at carmen.fc.hp.com Thu Jun 2 14:08:00 2005 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Updating lsbinstall vote again In-Reply-To: References: Message-ID: <20050602210800.514E737D6F@carmen.fc.hp.com> "Wichmann, Mats D" writes... > 1: keep in 3.0 > 2: keep, reduced functionality > 3: drop from 3.0 > > > Matt: no vote yet I vote #3. There are too many issues to add it to the official part of the spec (the main one being the ISO process). I support the consensus achieved on the lsb-futures conference call today to put lsbinstall in an Informative Addendum and have it be part of the document, but not required for runtime implementors or certification. -- Matt Taggart Open Source & Linux Organization R&D taggart@fc.hp.com Hewlett-Packard From mats.d.wichmann at intel.com Thu Jun 2 15:24:59 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Updating lsbinstall vote again Message-ID: >> 1: keep in 3.0 >> 2: keep, reduced functionality >> 3: drop from 3.0 >> >> >> Matt: no vote yet > >I vote #3. I'm going to go with the same conclusion. The updated vote then is: Nick: option 3 Stuart: no vote Chris: option 3 Marvin: option 3 Matt: option 3 Andrew: option 3 Mats: option 3 What I'd then like to propose is that while lsbinstall is not part of LSB 3 in the sense of being required of distributions or able to be depended on by applications, that it be published as part of LSB 3 as an informative annex indicating intended future direction, and that we continue the dialog that has recently been very productive. It has clearly indicated that there are problems at many levels that a tool like lsbinstall can help abstract, and that the problem space is not limited to individual ISVs - apparently the ad-hoc manner in which many of these issues are addressed by various implementors makes it hard to deploy large-scale installations, which in turn makes an inhibitor for distros to sell such installations, so everybody shares in the pain. We will need to find ways to broaden the audience for such a discussion, and while I jokingly criticised that suggestion earlier, perhaps this is a task the dormant packaging group could actually tackle. There are additional implications. 1. While we would prefer to make some things more abstract through the use of lsbinstall, we are not able to do so for LSB 3, and will likely need to make a few more explicit instead, just to provide a way forward. Those areas, such as the directories /etc/init.d and /etc/cron.d and others, should clearly be flagged as likely to disappear from a future version of the specification. 2. As we will be knowingly delivering a specification that makes it hard for applications to certify if they need to touch "lsbinstall areas", we will need to work with FSG to see if the certification program can be accomodating of situations where an application is "ready to certify except for ...". This is not an ideal situation by any means, but excess rigor in certification in this environment would not seem to be productive. If this seems to be on track, I'd appreciate help refining the above text for wider dissemination. -- mats From nick at usenix.org Thu Jun 2 17:52:34 2005 From: nick at usenix.org (Nick Stoughton) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Updating lsbinstall vote again In-Reply-To: References: Message-ID: <1117759953.3573.12405.camel@collie> I have a private version of the specification ready for checkin that addresses most of the issues here. You can find it at http://www.msbit.com:82/LSB/booksets/LSB-Core-generic/LSB-Core-generic/book1.html In particular, this version does the following: 1. The FHS section of execenv is extended; see .../etc.html this specifies the additional directories, and gives a warning note that a future version might do away with these if lsbinstall can be finished. It also specifies the namespace rules used elsewhere into a single place 2. The sysinit chapter refers back to these namespace rules. For example, see .../sysinit.html#CRONJOBS. These sections also contain notes warning that these directories may not be specified in future releases, and pointing to the future directions annex. 3. There's an informative annex added with lsbinstall in its current state. This is structured so as to make it easy to add other things we want to advertise, but I'm not suggesting we do for 3.0 (e.g. we could list out all 325 of the 'Defered' library interfaces ...). This annex starts at .../future-directions-annex.html I'd appreciate feedback ... More comments in-line below. On Thu, 2005-06-02 at 15:24, Wichmann, Mats D wrote: > >> 1: keep in 3.0 > >> 2: keep, reduced functionality > >> 3: drop from 3.0 > >> > >> > >> Matt: no vote yet > > > >I vote #3. > > I'm going to go with the same conclusion. > The updated vote then is: > > > Nick: option 3 > Stuart: no vote > Chris: option 3 > Marvin: option 3 > Matt: option 3 > Andrew: option 3 > Mats: option 3 > > What I'd then like to propose is that while > lsbinstall is not part of LSB 3 in the sense > of being required of distributions or able to be > depended on by applications, that it be published > as part of LSB 3 as an informative annex > indicating intended future direction, and that > we continue the dialog that has recently been > very productive. Yes, and it remains essential that we finish and release the sample implementation. I have not mentioned the sample imp in the annex, but perhaps I should add that. > It has clearly indicated that > there are problems at many levels that a tool > like lsbinstall can help abstract, and that the > problem space is not limited to individual > ISVs - apparently the ad-hoc manner in which > many of these issues are addressed by various > implementors makes it hard to deploy large-scale > installations, which in turn makes an inhibitor > for distros to sell such installations, so everybody > shares in the pain. We will need to find ways to > broaden the audience for such a discussion, and > while I jokingly criticised that suggestion earlier, > perhaps this is a task the dormant packaging group > could actually tackle. Is this dormant group populated with a different set of people? If so, they should certainly be involved. But, if as I suspect, it is the same group of people that are currently working on it, I don't actually see what this means. It has been particularly helpful to have Russ Herrold on the IRC and recent calls, and if there's more like him, please wake them up! > > There are additional implications. > > 1. While we would prefer to make some things > more abstract through the use of lsbinstall, > we are not able to do so for LSB 3, and will > likely need to make a few more explicit instead, > just to provide a way forward. Those areas, > such as the directories /etc/init.d and > /etc/cron.d and others, should clearly be flagged > as likely to disappear from a future version > of the specification. > I hope that my proposed text (see above) is enough...but if it needs to be stronger, give me the words. > 2. As we will be knowingly delivering a specification > that makes it hard for applications to certify if > they need to touch "lsbinstall areas", we will > need to work with FSG to see if the certification > program can be accomodating of situations where an > application is "ready to certify except for ...". > This is not an ideal situation by any means, but > excess rigor in certification in this environment > would not seem to be productive. > I believe that this is essential. It will also help us to ensure that the sample lsbinstall tool (and spec) is good enough to meet the needs of these apps. It is all very well trying to guess what apps want to do, but there's no substitute for real-world experience. And I cannot see the FSG refusing to certify an app that wants it because of these faults in the spec. However, we should probably work with the certification authority to come up with some policy they can easily apply to recognize these cases. > > If this seems to be on track, I'd appreciate > help refining the above text for wider dissemination. > > -- mats -- Nick Stoughton USENIX/FSG Standards Liaison nick@usenix.org (510) 388 1413 From ajosey at rdg.opengroup.org Thu Jun 2 22:33:29 2005 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Updating lsbinstall vote again In-Reply-To: Wichmann, Mats D's message as of Jun 2, 3:24pm. References: Message-ID: <1050603053329.ZM26075@skye.rdg.opengroup.org> On Jun 2, 3:24pm in "RE: [Lsb-sc] Updatin", Wichmann, Mats D wrote: > 2. As we will be knowingly delivering a specification > that makes it hard for applications to certify if > they need to touch "lsbinstall areas", we will > need to work with FSG to see if the certification > program can be accomodating of situations where an > application is "ready to certify except for ...". > This is not an ideal situation by any means, but > excess rigor in certification in this environment > would not seem to be productive. > "Accomodating" ultimately needs some words somewhere, since we cannot make adhoc decisions on the fly for certification. Can we spell out exactly what this means for application conformance?. It sounds like we won't be able to get binary portability across an architecture where platforms have different system files/locations. I do not think this is something we caught up to now with LSB 2.0 apart from having the vendor test the app on two platforms plus the SI. What happens in the SI if an application tries to install information into a system level facility such as inetd? thanks Andrew From mats.d.wichmann at intel.com Fri Jun 3 05:40:43 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Updating lsbinstall vote again Message-ID: >On Jun 2, 3:24pm in "RE: [Lsb-sc] Updatin", Wichmann, Mats D wrote: >> 2. As we will be knowingly delivering a specification >> that makes it hard for applications to certify if >> they need to touch "lsbinstall areas", we will >> need to work with FSG to see if the certification >> program can be accomodating of situations where an >> application is "ready to certify except for ...". >> This is not an ideal situation by any means, but >> excess rigor in certification in this environment >> would not seem to be productive. >> > >"Accomodating" ultimately needs some words somewhere, since we >cannot make adhoc decisions on the fly for certification. Can >we spell out exactly what this means for application >conformance?. It sounds like we won't be able to get >binary portability across an architecture where platforms >have different system files/locations. I do not think >this is something we caught up to now with LSB 2.0 apart >from having the vendor test the app on two platforms >plus the SI. What happens in the SI if an application >tries to install information into a system level facility >such as inetd? We didn't test for any of this before. Now with pkgchk, there's a complaint if any non-FHS path appears in the list of installed files. I don't think we've yet learned how to reach into the postinstall scripts as well, but that's also possible - it requires more work certainly. This is not a fully formed idea, although it's something we've talked about before. It would have to be very carefully done - I don't mean we'd accommodate apps where the unspecified element is known incompatible across distributions, but rather ones where it's believed compatible. I'm not even sure there are such cases. From mats.d.wichmann at intel.com Fri Jun 10 06:52:34 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Steering Committee items for Portland Meeting Message-ID: We haven't really used the LSB Steering Committee much. Maybe that's a good thing (perhaps workgroup consensus is generally a better way to proceed than SC votes, but there's some stuff I'd like to work through with you all. I currently cut down the SC meeting to two hours and slotted it in to Thursday morning. I'm worried about time needed for non-LSB3 things, including this, so we might need to either start early (maybe 8am instead of 9am) or move this to a "dinner meeting" - although the latter wouldn't let us be on the phone if Andrew or Chris was available to call in. To give some advance notice, here are some of the things I want to look at. 0. Role: Does the steering committee want to steer, or only serve as a charter-mandated entity for certain formal approvals? 1. Consent List: Propose creating and maintaining a new list for technical specification decisions. People seemed to like this idea last time it was broached, but I haven't acted on it yet (there's an empty link on the workgroup page at http://www.linuxbase.org/policy If added, who has the authority to place items on this list? Is this a subgroup matter (possibly including futures), workgroup matter, steering committee, Items for retroactive consent list addition (in future, if the use of this list is approved, decisions need to be made and documented here _before_ they are implemented) * any moved policies * LSB 2 will be divided into modules lsb-core and lsb-graphics; implementations will need to provide both modules to be considered LSB conforming * LSB 2 will include a separate C++ module, with the ABI and library versioning based on that of gcc 3.3. implementations will need to provide lsb-c++ to be considered LSB conforming * LSB 3 will include a separate C++ module, with the ABI and library versioning based on that of gcc 3.4 implementations will need to provide lsb-c++ to be considered LSB conforming * LSB 3 will include the new library librt in lsb-core * LSB 3 will include the new library libXi in lsb-graphics * LSB 3 will include an informative annex describing intended future directions, which will include a draft specification for lsbinstall 2. LSB Policy 004: Propose move this - as a purely technical decision - to the new Consent List. 3. LSB Policy 007: Proposed changes: add x86_64 dynamic linker. Document that the version number must change for each LSB major release. Propose move to consent list. 4. LSB Policy 005: I'm seeking better wording without changing the intent of this policy. No proposal yet. 5. LSB Policy 006: I'm seeking better wording without changing the intent of this policy. No proposal yet. 6. LSB Policy 008: We never got through a previous proposal on this. The dilemma is that this policy talks about certification, and certification is an FSG matter, not an LSB matter. I believe what was proposed last time was that the LSB will provide active support for two major releases (we didn't seem to agree on a time overlap and if any, what it should be). If someone was in the pipeline when support would otherwise have expired, they could petition. We need to encourage FSG to come up with their own policy on how long certification will be available. 7. Charter review When producing the workgroup charter we added some provisions which we're not following. The main one I'm worried about is meetings. We said we wouldn't conduct more than two meetings a year, we've now stopped having full "everybody come and we'll report on status" meetings at Linux World like we used to, and gone to technical working sessions which we may hold more than twice. The two-per-year limitation was to keep people from being excluded by excess travel. Meanwhile, we've found in practice that it's important to get together and work through things simply as part of the challenge keeping a completely distributed team moving forward. Any suggestions what we could/shold do here? 8. Relationship to FSG This has gotten a little unfocused. I want to get the sense of the SC how we should work moving forward. This is a discussion item and I don't want to influence it too much by posting a summary here, but I definitely have opinions. Questions to consider are basically, who sets priorities, decides on features, sets release dates and release criteria? One example of how it's gotten blurred which may be useful to see what I'm asking about: the decision to submit LSB as a candidate ISO specification was not made in the LSB workgroup. However, a great deal of work and more importantly, an implied adjustment of priorities, came into LSB as a result. FSG has funded much of this work by retaining Nick, but almost every serious decision that we make these days now has a component of "what impact does this have on ISO". Dates for things we do are now to some extent at least influenced by coordination with ISO related schedules. I may have some more items after further thought, I keep getting distracted from doing this stuff. From mats.d.wichmann at intel.com Fri Jun 10 15:35:31 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Another SC policy proposal Message-ID: I want to get on record an intent not to carry certification waivers across multiple releases. So although I don't have wording, I want to propose that for inclusion in the policies. One cycle is enough for a fix to propagate to everywhere it needs to, or else we've specified something that upstream disagrees with, and ought not to have. You guessed it - I'm unhappy about the LI18NUX situation where we've specified behavior that still has not been implemented upstream. -- mats From ajosey at rdg.opengroup.org Fri Jun 10 22:18:18 2005 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Another SC policy proposal In-Reply-To: Wichmann, Mats D's message as of Jun 10, 3:35pm. References: Message-ID: <1050611051818.ZM18719@skye.rdg.opengroup.org> hi Mats I think your primarily concerned with INTs , since the other classifications are TSD (which is test suite release specific) and CSD (certification system). In general is something was a TSD and did not get fixed in an updated release of the test suite then the TSD would get reissued on application for the update release. We have one CSD right now which covers the situation of there not being enough runtime platforms for an application to test on. I think that would carry forward too. regards Andrew On Jun 10, 3:35pm in "[Lsb-sc] Another SC ", Wichmann, Mats D wrote: > > I want to get on record an intent not to > carry certification waivers across multiple > releases. So although I don't have wording, > I want to propose that for inclusion in > the policies. > > One cycle is enough for a fix to propagate > to everywhere it needs to, or else we've > specified something that upstream disagrees > with, and ought not to have. > > You guessed it - I'm unhappy about the > LI18NUX situation where we've specified > behavior that still has not been implemented > upstream. > > -- mats > > > > > > _______________________________________________ > Lsb-sc mailing list > Lsb-sc@mail.freestandards.org > http://mail.freestandards.org/mailman/listinfo/lsb-sc >-- End of excerpt from Wichmann, Mats D From ajosey at rdg.opengroup.org Fri Jun 10 22:29:52 2005 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Steering Committee items for Portland Meeting In-Reply-To: Wichmann, Mats D's message as of Jun 10, 6:52am. References: Message-ID: <1050611052952.ZM18750@skye.rdg.opengroup.org> Mats Some quick comments.. On Jun 10, 6:52am in "[Lsb-sc] Steering Co", Wichmann, Mats D wrote: > 0. Role: > Does the steering committee want to steer, or only serve as a > charter-mandated entity for certain formal approvals? > I think the SC is a level above the technical development of the specification and comes into play for policy and formal approval. > 1. Consent List: > Propose creating and maintaining a new list for technical specification > decisions. People seemed to like this idea last time it was broached, > but I haven't acted on it yet (there's an empty link on the workgroup > page at http://www.linuxbase.org/policy > > If added, who has the authority to place items on this list? Is this > a subgroup matter (possibly including futures), workgroup matter, > steering committee, > In general the Consent list is useful to show that key decisions were made intentionally and visibly. Probably allow any workgroup member to propose an item be added and then get the SC to approve/disapprove regards Andrew From cyeoh at samba.org Tue Jun 14 18:22:09 2005 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] Steering Committee items for Portland Meeting In-Reply-To: References: Message-ID: <17071.33473.171853.12760@gargle.gargle.HOWL> At 2005/6/10 06:52-0700 Wichmann, Mats D writes: > > To give some advance notice, here are some of the things > I want to look at. > > 0. Role: > Does the steering committee want to steer, or only serve as a > charter-mandated entity for certain formal approvals? I think it should only get involved for formal approvals and situations where a reasonable consensus cannot be reached. > 1. Consent List: > Propose creating and maintaining a new list for technical specification > decisions. People seemed to like this idea last time it was broached, > but I haven't acted on it yet (there's an empty link on the workgroup > page at http://www.linuxbase.org/policy > > If added, who has the authority to place items on this list? Is this > a subgroup matter (possibly including futures), workgroup matter, > steering committee, I think the consent list would be a very useful resource. Perhaps any subgroups could add things to the list, which could then be marked as approved by the SC (but this last step is really only a rubber stamp to ensure some sanity checking). > Items for retroactive consent list addition (in future, if the use of > this list is approved, decisions need to be made and documented here > _before_ they are implemented) FWIW for specification related ones, I think it also makes sense to include non-normative text inline with the specification (where appropriate). Often when people read specs they don't know about things like consent lists (or where to find them). > > 2. LSB Policy 004: > Propose move this - as a purely technical decision - to the new Consent > List. Agreed. > 3. LSB Policy 007: > Proposed changes: add x86_64 dynamic linker. Document that the version > number must change for each LSB major release. Propose move to consent > list. Do we need to make the version number bump compulsory? (Though I suspect in practice if there is a year between releases it will be necessary anyway). > > 4. LSB Policy 005: > I'm seeking better wording without changing the intent of this policy. > No proposal yet. What about a list of approved licenses under which we would accept code or documentation. FWIW I think it would be much better where possible to get copyright assignment to the FSG. There are circumstances under which it is necessary to change licensing terms (eg ask some of the Linux documentation people about the problems they have with old documentation and they can't reach the original authors). Similar problems if someone external was breaking the licensing terms and the copyright holder was no longer contactable. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From mats.d.wichmann at intel.com Thu Jun 16 22:11:41 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] DRAFT minutes of 16 June meeting Message-ID: DRAFT These are the draft minutes of the SC meeting, please email me corrections if any before I publish the final minutes (does anyone want the final minutes to go elsewhere than the lsb-sc mailing list? lsb-sc does not have open membership, but I believe anyone can see the archives if they wish, although they're not likely to know to go look) LSB Steering Committee Actions, June 16, 2005 The LSB Steering Committee met June 16 2005 in Hillsboro, OR. Present were Mats Wichmann (LSB Chair), Andrew Josey (test subproject lead- by phone), Stuart Anderson (spec subproject lead), Marvin Heffler (tools subproject lead), Nick Stoughton (at-large member) Five of the seven members were present, constituting a quorum. In informal discussion, the SC confirmed that it wished to continue the current situation of encouraging workgroup consensus as the primary decision making mechanism, to make formal approvals where required by charter, to resolve deadlocks and disputes which prevent forward progress, and to act as a sanity-check on workgroup decisions; and not to assume an active driving role on technical issues. Agreed to create and maintain a Consent List to document decisions of the LSB Workgroup. The list should be maintained regularly, to make sure previously made decisions are still appropriate. Changes should be documented as a new decision modifying or rescinding an older decision; entries should not be removed in order to maintain history. Some entries in the LSB Workgroup Policies document are properly consent list entries. Agreed to move "004 Util-linux versus Shadow-utils" and "007 Architecture specific runtime loaders". The latter needs to be followed up with the LSB 2 list (which added x86_64) and the LSB 3 list. These are new items, not changes to 007. In addition, past decisions will be added to the initial Consent List as they are identified (the Chair had enumerated a partial list in email prior to the meeting, and these was all deemed appropriate to add). Policies "005 Specification Intellectual Property" and "006 Subject Matter Intellectual Property" have some issues with imprecise and informal wording - they don't provide precise enough guidance on how the workgroup should act. The Chair is directed to work on a proposal for amended wording, and coordinate with the FSG. "008 Certification close for releases" came up for discussion again. The current policy, which was enacted in response to the several LSB 1.x releases, is somewhat obsoleted by the change in direction to not roll the certification program on minor version releases, plus the realization that it's not the LSB workgroup's call when an FSG certification program ends. Change the title to "Certification Support". Remove the mention of minor numbers. Change from a time-based policy to supporting the current and previous major release. Approved by voice vote. On the workgroup charter, the current meeting guideline looks inconsistent with how the workgroup has been acting. There was not a change made, instead the Chair is directed to propose wording to address these desired changes: 1. the current meeting section should be modified to reflect "plenary meetings" (possibly define this term) 2. an additional section should be added do indicate working sessions of the type that have been held at various times may also occur A new policy was proposed (motion Anderson, second Stoughton) that LSB major version releases will be made no more often than every 18 months. Carried by voice vote. The Chair will add a Rationale indicating that this policy is based on community feedback for balancing stability with progress and to accommodate the constraints of (pending) status as an ISO standard. A new policy was proposed (motion Stoughton, second Anderson) that the SC be required to approve submittal of LSB specifications to ISO as candidate standards or amendments to existing standards (NOTE: need correct ISO term for the latter event). Carried by voice vote. The rationale is that any such submittal requires significant work which must be explicitly accounted for in LSB plans and work schedules, and the SC must confirm that a candidate is ready for ISO submittal. As a consent list item, an intent is indicated to not carry forward Interpretations from previous major versions of the specification. An Interpretation may be granted once if the Specification Authority feels that additional time to come into compliance should be granted, perhaps because a particular problem has not been resolved in the upstream project, but a second waiver cycle indicates a problem that should have been resolved either by the certification candidates or in the specification. The SC discussed adding a new policy entitled Release Process. Under this policy, a release checklist, to be maintained by the SC, would be required to be signed off by the SC as part of making a release. Note this is distinct from the checklist the FSG requires to submit a specification to the FSG board. Exceptions to the checklist (i.e., incomplete items) must be detailed. The Chair is directed to develop proposed wording and circulate. A proposal was brought forward from the workgroup that a new subproject to focus on LSB for the Desktop be created. Under the charter, new subprojects may be created (and disbanded) by the steering committee to carry out the purposes of the workgroup, and it was felt that the demand for adding specifications to support graphical desktop applications was sufficient to meet this criteria; the proposal was carried by voice vote. As requested by the workgroup, the chair nominated Rajesh Banginwar to serve as the initial subproject lead. This proposal was approved by voice vote. By charter provision, Rajesh automatically joins the LSB Steering Committee. From nick at msbit.com Fri Jun 17 10:59:07 2005 From: nick at msbit.com (Nick Stoughton) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] DRAFT minutes of 16 June meeting In-Reply-To: References: Message-ID: <1119031146.26055.7.camel@collie> > A new policy was proposed (motion Stoughton, second Anderson) that > the SC be required to approve submittal of LSB specifications to ISO > as candidate standards or amendments to existing standards (NOTE: > need correct ISO term for the latter event). "Amendment" is the correct term. Amendments add substantive new material to an existing standard ... e.g. pthreads went into POSIX by amendment. At the time an amendment is submitted, the vote is ONLY on the material being submitted ... the rest of the document is not open for comment. -- Nick From mats.d.wichmann at intel.com Fri Jun 17 20:54:01 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] Minutes of Steering Committee Meeting 16 June 2005 Message-ID: These are the completed minutes after comments and a few edits. LSB Steering Committee Actions, June 16, 2005 The LSB Steering Committee met June 16 2005 in Hillsboro, OR. Present were Mats Wichmann (LSB Chair), Andrew Josey (test subproject lead, by phone), Stuart Anderson (spec subproject lead), Marvin Heffler (tools subproject lead), Nick Stoughton (at-large member). Five of the seven members were present, constituting a quorum. In informal discussion, the SC confirmed that it wished to continue the current direction of encouraging workgroup consensus as the primary decision making mechanism; to make formal approvals where required by charter; to resolve deadlocks and disputes which prevent forward progress, and to act as a sanity-check on workgroup decisions; and to not change to assume an active driving role on workgroup technical issues. Agreed to create and maintain a Consent List to document decisions of the LSB Workgroup. The list should be reviewed regularly, to make sure previously made decisions are still appropriate. Changes should be documented as a new decision modifying or rescinding an older decision; entries should not be removed to insure history is maintained. Some entries in the LSB Workgroup Policies document are properly consent list entries. Agreed to move "004 Util-linux versus Shadow-utils" and "007 Architecture specific runtime loaders". The latter needs to be followed up with the LSB 2 list (which added x86_64) and the LSB 3 list. These are new items, not changes to 007. In addition, past decisions will be added to the initial Consent List as they are identified (the Chair had enumerated a partial list in email prior to the meeting, and these were all deemed appropriate to add). Policies "005 Specification Intellectual Property" and "006 Subject Matter Intellectual Property" have some issues with imprecise and informal wording - they don't provide precise enough guidance on how the workgroup should act. The Chair is directed to work on a proposal for amended wording, and to coordinate with the FSG in doing so. "008 Certification close for releases" came up for discussion again. The current policy, which was enacted in response to the several LSB 1.x releases, is somewhat obsoleted by the change in direction to not roll the certification program on minor version releases, plus the realization that it's not the LSB workgroup's call when an FSG certification program ends. Change the title to "Certification Support". Remove the mention of minor numbers. Change from a time-based policy to indicating the workgroup will support the current and previous major release. Approved by voice vote. On the Workgroup Charter, the current meeting guideline looks inconsistent with how the workgroup has been acting. There was not a change made, instead the Chair is directed to propose wording to clarify and address these desired changes: 1. the current meeting section paragraph be modified to reflect "plenary meetings" (possibly define this term) 2. an additional paragraph should be added to indicate working sessions (of the type that have been held at various times recently) may also occur. Charter changes require a 2/3 majority of the Steering Committee as well as approval by the FSG Board. A new Policy was proposed (motion Anderson, second Stoughton) that LSB major version releases will be made no more often than every 18 months. Carried by voice vote. The Chair will add a rationale indicating that this policy is based on community feedback for balancing stability with progress and to accommodate the constraints of (pending) status as an ISO standard. A new Policy was proposed (motion Stoughton, second Anderson) that the SC be required to approve submittal of LSB specifications to ISO as candidate standards or amendments to existing standards. Carried by voice vote. The rationale is that any such submittal requires significant editorial work which must be explicitly accounted for in LSB plans and work schedules, and the SC must confirm that a candidate is ready for ISO submittal. As a consent list item, an intent is indicated to not carry forward certification Interpretations from previous major versions of the specification. An Interpretation may be granted once if the Specification Authority feels that additional time to come into compliance should be granted, perhaps because a particular problem has not been resolved in the upstream project, but a second waiver cycle indicates a problem that should have been resolved either by the certification candidates or in the specification. The SC discussed adding a new Policy entitled Release Process. Under this policy, a release checklist, to be maintained by the SC, would be required to be signed off by the SC as part of making a release (the SC is already required by the Charter to approve the formal release of a specification; this adds structure to the way the decision on that release decision is made). Note this is distinct from the checklist the FSG requires to submit a specification to the FSG Board. Exceptions to the checklist (i.e., incomplete items) must be detailed. The Chair is directed to develop proposed wording and circulate for discussion. A proposal was brought forward from the workgroup that a new subproject to focus on LSB for the Desktop be created. Under the Charter, new subprojects may be created and disbanded by the steering committee to carry out the purposes of the workgroup, and it was felt that the demand for adding specifications to support graphical desktop applications was sufficient to meet this criteria; the proposal was carried by voice vote. As requested by the workgroup, the chair nominated Rajesh Banginwar to serve as the initial subproject lead. This proposal was approved by voice vote. By charter provision, Rajesh automatically joins the LSB Steering Committee. From mats.d.wichmann at intel.com Thu Jun 23 07:53:47 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.0 vote needed Message-ID: The Workgroup has expressed comfort with LSB 3.0 as being done, conditional on completing verifications against the final build, which Nick is working on. Jim has requested that if possible, we have the spec ready for an FSG Board vote by Monday as they have a Monday AM regularly scheduled meeting and he claims it's very hard to get them together for a meeting that hasn't been scheduled (there are board members in US, Europe and Asia - the same problem we have in finding a call time, so I understand this). If it's not possible, the approval at that level will need to either wait until the next meeting a month later or they'll have to try to schedule a special vote. Before that can occur, the SC must have given their approval for the spec. That means we need to act on this in some kind of an expeditious manner. I'm soliciting a proposal for what action we should take. -- mats From anderson at netsweng.com Thu Jun 23 09:19:24 2005 From: anderson at netsweng.com (Stuart Anderson) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.0 vote needed In-Reply-To: References: Message-ID: On Thu, 23 Jun 2005, Wichmann, Mats D wrote: > I'm soliciting a proposal for what action we > should take. We should fill out the checklist to see how things stand overall. 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 mats.d.wichmann at intel.com Thu Jun 23 10:11:37 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.0 vote needed Message-ID: >> I'm soliciting a proposal for what action we >> should take. > >We should fill out the checklist to see how things stand overall. Well, yes, but it's not broken out in spec detail yet, and everything else follows after the spec goes gold, so there's not a lot of checkmarks to fill in. From nick at usenix.org Fri Jun 24 17:34:49 2005 From: nick at usenix.org (Nick Stoughton) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: <1119659689.26055.3905.camel@collie> The final build of the 3.0 specification is (I hope) complete and available on the "daily builds" part of linuxbase.org: http://www.linuxbase.org/spec It is intended that this be sent to the FSG board for approval on Monday, but it should also have our approval first. Therefore, please consider this a letter ballot of the steering committee for such approval. If possible, please respond to list before noon PDT (3.00pm EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a reason ... preferably a bug number!). Since bug verification is incomplete, any vote by the SC is conditional upon final bug verification. This is intended to put a checkmark for the "Specification" line (all architectures) in the release checklist. -- Nick From nick at usenix.org Fri Jun 24 18:02:18 2005 From: nick at usenix.org (Nick Stoughton) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] Re: 3.0 specification approval In-Reply-To: <1119659689.26055.3905.camel@collie> References: <1119659689.26055.3905.camel@collie> Message-ID: <1119661338.26055.3942.camel@collie> I vote YES ... On Fri, 2005-06-24 at 17:34, Nick Stoughton wrote: > The final build of the 3.0 specification is (I hope) complete and > available on the "daily builds" part of linuxbase.org: > > http://www.linuxbase.org/spec > > It is intended that this be sent to the FSG board for approval on > Monday, but it should also have our approval first. Therefore, please > consider this a letter ballot of the steering committee for such > approval. If possible, please respond to list before noon PDT (3.00pm > EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a > reason ... preferably a bug number!). Since bug verification is > incomplete, any vote by the SC is conditional upon final bug > verification. > > This is intended to put a checkmark for the "Specification" line (all > architectures) in the release checklist. From anderson at netsweng.com Fri Jun 24 18:55:13 2005 From: anderson at netsweng.com (Stuart Anderson) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: <1119659689.26055.3905.camel@collie> References: <1119659689.26055.3905.camel@collie> Message-ID: On Fri, 24 Jun 2005, Nick Stoughton wrote: > The final build of the 3.0 specification is (I hope) complete and > available on the "daily builds" part of linuxbase.org: > > http://www.linuxbase.org/spec > > It is intended that this be sent to the FSG board for approval on > Monday, but it should also have our approval first. Therefore, please > consider this a letter ballot of the steering committee for such > approval. If possible, please respond to list before noon PDT (3.00pm > EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a > reason ... preferably a bug number!). Since bug verification is > incomplete, any vote by the SC is conditional upon final bug > verification. I vote NO, until the verification is complete. 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 heffler at us.ibm.com Fri Jun 24 21:46:47 2005 From: heffler at us.ibm.com (Marvin Heffler) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: <1119659689.26055.3905.camel@collie> Message-ID: I vote YES to approve the spec with the verification process to continue. We need to make sure we get the FSG board to vote on this on Monday so we won't have to wait another month. 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 06/24/2005 07:34:49 PM: > The final build of the 3.0 specification is (I hope) complete and > available on the "daily builds" part of linuxbase.org: > > http://www.linuxbase.org/spec > > It is intended that this be sent to the FSG board for approval on > Monday, but it should also have our approval first. Therefore, please > consider this a letter ballot of the steering committee for such > approval. If possible, please respond to list before noon PDT (3.00pm > EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a > reason ... preferably a bug number!). Since bug verification is > incomplete, any vote by the SC is conditional upon final bug > verification. > > This is intended to put a checkmark for the "Specification" line (all > architectures) in the release checklist. > -- > Nick > > > _______________________________________________ > 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/20050624/7d7f739c/attachment.htm From cyeoh at samba.org Sat Jun 25 04:27:16 2005 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: <1119659689.26055.3905.camel@collie> References: <1119659689.26055.3905.camel@collie> Message-ID: <17085.16276.775472.28440@gargle.gargle.HOWL> At 2005/6/24 17:34-0700 Nick Stoughton writes: > approval. If possible, please respond to list before noon PDT (3.00pm > EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a > reason ... preferably a bug number!). Since bug verification is > incomplete, any vote by the SC is conditional upon final bug > verification. > Conditional upon final bug verification I vote yes. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From mats.d.wichmann at intel.com Sat Jun 25 07:14:26 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] Workgroup / SC work Message-ID: Just a heads-up on stuff that's coming. 1. I owe proposals on several of the items discussed at the Portland meeting, as noted in the minutes. 2. I really think it's time to revisit the mission statement and sharpen it up a bit. Here's the current one: "To develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux." While that's not wrong, we (as the LSB) don't really do much of the latter, and we might want to reflect more of an intended role to broker solutions - a forum for working out agreements that may become future LSB standards. I don't know - I'm open to discussion, we can also leave it alone. 3. Developing a good set of plans for LSB 4 will involve sharpening up what's on the RoadMap wiki page and deciding on things that really are appropriate to pursue. I'd like to see some way to get more "community" input (yes, we are the community, but a bit of a small set of it I'm afraid). 4. If anyone's got any idea for stimulating more activity on the lsb-wg or lsb-discuss mailing lists, please speak up. We did get a fair bit of activity by conducting the lsbinstall discussions there, and Gordon's library question did draw some reactions, but sometimes it seems like a list to which I post status reports... and not much else. Cheers, Mats Mats From mats.d.wichmann at intel.com Sat Jun 25 10:44:26 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: So in summary, Chris votes yes Marvin votes yes Nick votes yes Stuart votes no Four votes, 3-1 in favor The proposal is approval conditional on completion of bug verification. Stuart votes no; the objection being the bugs are not verified. If we follow ISO style voting, a no vote turns to yes if the objection is satisfied. We're waiting to hear from Matt, Andrew and Rajesh, and as usual I'm holding the chair's vote until others have had their chance. *Technically* this is enough to approve - the charter requires 50% (= 4 votes) for quorum, and a majority in favor. However, as usual we'd like to see a clearer message. I've got the paperwork ready to go if the decision is yes - Jim, I'll forward you links on the LSB web page for these. Mats From rajesh.banginwar at intel.com Sun Jun 26 10:30:48 2005 From: rajesh.banginwar at intel.com (Banginwar, Rajesh) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: I vote YES conditional upon the final bug verification and completing the checklist. -----Original Message----- From: lsb-sc-bounces@base3.freestandards.org [mailto:lsb-sc-bounces@base3.freestandards.org] On Behalf Of Nick Stoughton Sent: Friday, June 24, 2005 5:35 PM To: lsb-sc@freestandards.org Cc: Jim Zemlin Subject: [Lsb-sc] 3.0 specification approval The final build of the 3.0 specification is (I hope) complete and available on the "daily builds" part of linuxbase.org: http://www.linuxbase.org/spec It is intended that this be sent to the FSG board for approval on Monday, but it should also have our approval first. Therefore, please consider this a letter ballot of the steering committee for such approval. If possible, please respond to list before noon PDT (3.00pm EDT, 8.00pm BST) on Sunday, June 26 with a YES or NO (NO must include a reason ... preferably a bug number!). Since bug verification is incomplete, any vote by the SC is conditional upon final bug verification. This is intended to put a checkmark for the "Specification" line (all architectures) in the release checklist. -- Nick _______________________________________________ Lsb-sc mailing list Lsb-sc@mail.freestandards.org http://mail.freestandards.org/mailman/listinfo/lsb-sc From taggart at carmen.fc.hp.com Sun Jun 26 13:39:26 2005 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: References: Message-ID: <20050626203926.1F07537D6E@carmen.fc.hp.com> "Wichmann, Mats D" writes... > We're waiting to hear from Matt,... Yes, subject to verification. -- Matt Taggart Open Source & Linux Organization R&D taggart@fc.hp.com Hewlett-Packard From mats.d.wichmann at intel.com Sun Jun 26 16:30:05 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: I'm voting the same conditional yes, which puts us at 6-1 for approval. We're going to have to really hustle on the verifications since we're also trying to finish off the software deliverables in about the next week. From ajosey at rdg.opengroup.org Sun Jun 26 22:34:31 2005 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: Wichmann, Mats D's message as of Jun 26, 4:30pm. References: Message-ID: <1050627053430.ZM5886@skye.rdg.opengroup.org> Mats Sorry I did not vote, it was the weekend for me and I did not have the cycles to look at the document during that time. I've also seen checkins to cvs after the vote started, does that mean another rebuild? Could you look also at why the Copyright acknowledgement has the IEEE and The Open Group listed. I'm bound to be asked about that at some point. thanks Andrew From mats.d.wichmann at intel.com Mon Jun 27 05:08:40 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: >Could you look also at why the Copyright acknowledgement >has the IEEE and The Open Group listed. I'm bound to be asked >about that at some point. Anybody know the answer to this? I'm assuming this came in after the "manpage" license grant, but do we actually /use/ any of the manpages now or is it pure diff from the SUS pages? From ajosey at rdg.opengroup.org Mon Jun 27 09:15:57 2005 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: Nick Stoughton's message as of Jun 27, 9:11am. References: <1050627053430.ZM5886@skye.rdg.opengroup.org> <1119888673.26055.7755.camel@collie> Message-ID: <1050627161557.ZM1288@skye.rdg.opengroup.org> Nick, All. > > Could you look also at why the Copyright acknowledgement > > has the IEEE and The Open Group listed. I'm bound to be asked > > about that at some point. > > > Good point ... I added these at some point in the past when it looked > like we had some text from POSIX, but I don't think this is the case. > However, it certainly wouldn't hurt to get a formal copyright release > set up if we can. For a copyright release from The Open Group and IEEE you need to be specific in the pages you want, and you would need to acknowledge on the page where used and the front matter. There is specific wording for the acknowledgement, you can see examples in the Linux man pages and the BSD project. For now I think you should remove the statements on the copyright page since there is no license that would allow such use, and that will stop the question being raised as to what text is there that is copyright. regards Andrew From mats.d.wichmann at intel.com Mon Jun 27 11:14:29 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval Message-ID: >Nick, All. >> > Could you look also at why the Copyright acknowledgement >> > has the IEEE and The Open Group listed. I'm bound to be asked >> > about that at some point. >> > >> Good point ... I added these at some point in the past when it looked >> like we had some text from POSIX, but I don't think this is the case. >> However, it certainly wouldn't hurt to get a formal copyright release >> set up if we can. > >For a copyright release from The Open Group >and IEEE you need to be specific in the pages you want, and you >would need to acknowledge on the page where used and the front >matter. There is specific wording for the acknowledgement, >you can see examples in the Linux man pages and the BSD project. >For now I think you should remove the statements on the copyright >page since there is no license that would allow such use, and >that will stop the question being raised as to what text is >there that is copyright. This will need a bug. From mats.d.wichmann at intel.com Mon Jun 27 14:03:05 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3 status update Message-ID: The FSG board did not vote to approve the LSB 3.0 specification yet, they wanted more time, and answers to some questions. Roughly speaking, the questions were: - What does LSB 3 actually consist of, there seem to be embedded, desktop, and other docs. :: this is actually specifically answered by the submission documents, which are archived at http://www.linuxbase.org/policy/forms so I'm not sure where this question came from - What's different from LSB 2? :: I sent them a link to the release notes page on the wiki. there wasn't a place on the FSG form for this, which only asks the details of the current submission, not relationship to previous submissions; and so I hadn't provided this originally. This should probably get added to the form. - Is there a list of items which are not fully implemented upstream. "The issue came up because of requirements in the OpenI18N section which require patches to coreutils which are apparently not ported or accepted into newer upstream versions." This question was asked in the context of understanding where distros would likely be asking for waivers. :: I've provided a response to that, which is basically that the li18nux addon is the only piece of technology that's not actually accepted by upstream. There are a few other minor details which were already covered in the release notes, but those are in the nature of "there's an upstream answer which everybody may not have yet" as opposed to "upstream doesn't have it / is rejecting it / etc.". If there's more of the latter I'm not thinking of, please let me know. The Board will have a call again on Friday specifically to consider this. Which means by then we can remove the conditions from the vote, I hope. I've been busily verifying bugs today, but I've gotten rid of all the easy ones. The rest are either hard, or I'm not eligible to verify it... -- mats From nick at msbit.com Mon Jun 27 09:11:14 2005 From: nick at msbit.com (Nick Stoughton) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] 3.0 specification approval In-Reply-To: <1050627053430.ZM5886@skye.rdg.opengroup.org> References: <1050627053430.ZM5886@skye.rdg.opengroup.org> Message-ID: <1119888673.26055.7755.camel@collie> On Sun, 2005-06-26 at 22:34, Andrew Josey wrote: > Mats > Sorry I did not vote, it was the weekend for me and I did > not have the cycles to look at the document during that time. > I've also seen checkins to cvs after the vote started, does > that mean another rebuild? No ... these are post 3.0 checkins I found while processing the ISO ballots. They are destined for 3.1 (unless we do need another rebuild for any other reason). The vote is/was on the document as posted. > > Could you look also at why the Copyright acknowledgement > has the IEEE and The Open Group listed. I'm bound to be asked > about that at some point. > Good point ... I added these at some point in the past when it looked like we had some text from POSIX, but I don't think this is the case. However, it certainly wouldn't hurt to get a formal copyright release set up if we can. > thanks > Andrew > -- Nick > _______________________________________________ > Lsb-sc mailing list > Lsb-sc@mail.freestandards.org > http://mail.freestandards.org/mailman/listinfo/lsb-sc