From mats.d.wichmann at intel.com Wed Dec 1 12:36:55 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Merging some LSB WG roles Message-ID: Picking up an old thread that never really got resolved.... In presenting a clearer picture of what the key LSB workgroup roles and categories are, I'd like to coalesce three subprojects into one: Application Battery Sample Implementation Build Environment and call the result Tools, representing the software we release which isn't tests. Separately, we could talk about whether things like libchk, pkgchk, etc. belong to tools or to tests. I think this better matches reality, since for many months there have been two weekly calls of those three groups combined anyway, and at least to date, it's been all the same (small group of) people. I'd appoint Marvin lead of this new group if you all approve of the change (at least until he finds a way to get out of it :). Feel free to propose a better name than Tools, as well. Subproject changes are a Steering Committee matter so I'm askin' in a formal way for discussion / approval / disapproval: "The steering committee may choose to form and disband subproject teams as needed to carry out the purposes of the workgroup." -- mats From heffler at us.ibm.com Wed Dec 1 12:44:17 2004 From: heffler at us.ibm.com (Marvin Heffler) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Merging some LSB WG roles In-Reply-To: Message-ID: I have no problem combining the three subprojects into one since that is the way we have been handling it anyway. I'll be glad to lead the combined team, as long as I get some help in building and testing all the permutations. As far as a name for the team, I don't know if Tools is right since the lsbsi and appbat are both tests used for application certification. Maybe a more appropriate name would be something like Application Certification Tests and Tools. 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 12/01/2004 02:36:55 PM: > Picking up an old thread that never really > got resolved.... > > > In presenting a clearer picture of what the key LSB > workgroup roles and categories are, I'd like to > coalesce three subprojects into one: > > Application Battery > Sample Implementation > Build Environment > > and call the result Tools, representing the software > we release which isn't tests. Separately, we could > talk about whether things like libchk, pkgchk, etc. > belong to tools or to tests. > > I think this better matches reality, since for many > months there have been two weekly calls of those > three groups combined anyway, and at least to date, > it's been all the same (small group of) people. > > I'd appoint Marvin lead of this new group if you all > approve of the change (at least until he finds a way > to get out of it :). > > Feel free to propose a better name than Tools, as well. > > Subproject changes are a Steering Committee matter > so I'm askin' in a formal way for discussion / > approval / disapproval: > > "The steering committee may choose to form and disband > subproject teams as needed to carry out the purposes of > the workgroup." > > -- mats > > _______________________________________________ > 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/20041201/1da15a3f/attachment.htm From mats.d.wichmann at intel.com Wed Dec 1 13:14:37 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Merging some LSB WG roles Message-ID: > I have no problem combining the three subprojects > into one since that is the way we have been handling > it anyway. I'll be glad to lead the combined team, > as long as I get some help in building and testing > all the permutations. Part of this we need to solve separately from this discussion - we need to implement the vision Chris and others laid out in the August meeting about autobuilders that can do the production builds, adding "make check" sanity tests at least to the builds, and generally developing more tests-of-testsuites (and by extension, of the other bundles). There are bugs filed on all of those, just nobody really working on them (Chris Johnson agreed to take some of them at least to look). > As far as a name for the team, I don't know if Tools > is right since the lsbsi and appbat are both tests > used for application certification. Maybe a more > appropriate name would be something like Application > Certification Tests and Tools. A bit of a mouthful but possible. From cyeoh at samba.org Wed Dec 1 15:46:19 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Merging some LSB WG roles In-Reply-To: References: Message-ID: <16814.22475.406670.219327@gargle.gargle.HOWL> At 2004/12/1 12:36-0800 Wichmann, Mats D writes: > > I'd appoint Marvin lead of this new group if you all > approve of the change (at least until he finds a way > to get out of it :). > > Feel free to propose a better name than Tools, as well. > > Subproject changes are a Steering Committee matter > so I'm askin' in a formal way for discussion / > approval / disapproval: Sounds good to me. At least until we end up with a lot more developers :-) Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From mats.d.wichmann at intel.com Thu Dec 9 12:04:47 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy Message-ID: We're looking at adding a new policy to cover how the LSB is versioned to formalize what we've been acting on informally. Here's the current proposed wording - please discuss so we can get to a vote on this one. -- mats Proposed Policy 0xx: LSB Specification Versioning Policy. * Changes to an interface that result in binary incompatbilities, major additions or deletions such as a previously unsupported library require a change to the major number (1.x.x) of the specification. * Additions of an interface, removal of a previously deprecated interface and correction to interface descriptions may be reflected with a change to the minor number (x.1.x). Additions of interfaces is permitted in the case where the inferface being added already exits and is in use in multiple distributions. * Changes to the specification that are editiorial in nature only require a change in the editorial digit (x.x.1) From heffler at us.ibm.com Thu Dec 9 12:27:11 2004 From: heffler at us.ibm.com (Marvin Heffler) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy In-Reply-To: Message-ID: The new wording looks okay to me. I say we go with it. 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 12/09/2004 02:04:47 PM: > We're looking at adding a new policy to cover how the > LSB is versioned to formalize what we've been acting on > informally. Here's the current proposed wording - > please discuss so we can get to a vote on this one. > > -- mats > > > > Proposed Policy 0xx: LSB Specification Versioning Policy. > > * Changes to an interface that result in binary > incompatbilities, major additions or deletions such > as a previously unsupported library require a change > to the major number (1.x.x) of the specification. > > * Additions of an interface, removal of a previously > deprecated interface and correction to interface > descriptions may be reflected with a change to the > minor number (x.1.x). Additions of interfaces is > permitted in the case where the inferface being added > already exits and is in use in multiple distributions. > > * Changes to the specification that are editiorial in > nature only require a change in the editorial digit (x.x.1) > > > > > _______________________________________________ > 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/20041209/99f3f17c/attachment.htm From cyeoh at samba.org Thu Dec 9 18:55:49 2004 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy In-Reply-To: References: Message-ID: <16825.4149.423826.456360@gargle.gargle.HOWL> At 2004/12/9 12:04-0800 Wichmann, Mats D writes: > We're looking at adding a new policy to cover how the > LSB is versioned to formalize what we've been acting on > informally. Here's the current proposed wording - > please discuss so we can get to a vote on this one. > > -- mats > > > > Proposed Policy 0xx: LSB Specification Versioning Policy. > > * Changes to an interface that result in binary > incompatbilities, major additions or deletions such > as a previously unsupported library require a change > to the major number (1.x.x) of the specification. > > * Additions of an interface, removal of a previously > deprecated interface and correction to interface > descriptions may be reflected with a change to the > minor number (x.1.x). Additions of interfaces is > permitted in the case where the inferface being added > already exits and is in use in multiple distributions. Could we clarify the deprecation rules a bit? Ie exactly how many versions of spec does an interface needs to be listed as deprecated before it can be removed. I don't think it should be possible to have an interface move completely from required to deprecated to removed without the major number being bumped at some stage during this process. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From gk4 at austin.ibm.com Fri Dec 10 06:34:19 2004 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy In-Reply-To: <16825.4149.423826.456360@gargle.gargle.HOWL> References: <16825.4149.423826.456360@gargle.gargle.HOWL> Message-ID: <1102689254.9379.9.camel@gkraft4.austin.ibm.com> Don't forget to document this new policy... :-) http://www.linuxbase.org/policy/ George (gk4) On Thu, 2004-12-09 at 20:55, Christopher Yeoh wrote: > At 2004/12/9 12:04-0800 Wichmann, Mats D writes: > > We're looking at adding a new policy to cover how the > > LSB is versioned to formalize what we've been acting on > > informally. Here's the current proposed wording - > > please discuss so we can get to a vote on this one. > > > > -- mats > > > > > > > > Proposed Policy 0xx: LSB Specification Versioning Policy. > > > > * Changes to an interface that result in binary > > incompatbilities, major additions or deletions such > > as a previously unsupported library require a change > > to the major number (1.x.x) of the specification. > > > > * Additions of an interface, removal of a previously > > deprecated interface and correction to interface > > descriptions may be reflected with a change to the > > minor number (x.1.x). Additions of interfaces is > > permitted in the case where the inferface being added > > already exits and is in use in multiple distributions. > > > Could we clarify the deprecation rules a bit? Ie exactly how many > versions of spec does an interface needs to be listed as deprecated > before it can be removed. > > I don't think it should be possible to have an interface move > completely from required to deprecated to removed without the major > number being bumped at some stage during this process. > > Chris -- George (gk4) -- George (gk4) From mats.d.wichmann at intel.com Fri Dec 10 16:40:03 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy Message-ID: >Could we clarify the deprecation rules a bit? Ie exactly how many >versions of spec does an interface needs to be listed as deprecated >before it can be removed. > >I don't think it should be possible to have an interface move >completely from required to deprecated to removed without the major >number being bumped at some stage during this process. Good question - any thoughts? From mats.d.wichmann at intel.com Fri Dec 24 08:01:32 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] Proposed LSB versioning policy Message-ID: >>> Could we clarify the deprecation rules a bit? Ie exactly how many >>> versions of spec does an interface needs to be listed as deprecated >>> before it can be removed. >>> >>> I don't think it should be possible to have an interface move >>> completely from required to deprecated to removed without the major >>> number being bumped at some stage during this process. >> >> Good question - any thoughts? > >Seems sensible for removal to require a Major digit bump. Proposed wording from someone? Here's the original text again: Proposed Policy 0xx: LSB Specification Versioning Policy. * Changes to an interface that result in binary incompatbilities, major additions or deletions such as a previously unsupported library require a change to the major number (1.x.x) of the specification. * Additions of an interface, removal of a previously deprecated interface and correction to interface descriptions may be reflected with a change to the minor number (x.1.x). Additions of interfaces is permitted in the case where the inferface being added already exits and is in use in multiple distributions. * Changes to the specification that are editiorial in nature only require a change in the editorial digit (x.x.1)