From mats.d.wichmann at intel.com Fri Sep 2 00:02:50 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB selection guidelines: License / Bestpractice Message-ID: There's a fairly big push to settle on the issues of selection criteria. This isn't going to come as any surprise to most of you. Non-SC people are expecting the proposal on the table, which is crafted to allow software under terms like Qt, to be complete by Tuesday, and an SC vote in relatively short order after that, perhaps by Sept 10 or so. I've tried to temper expectations a little bit as it usually takes this group a while. We of course are not obligated to do anything just because people have asked, but it seems like we ought to have a clear decision due to the community concerns raised over what appears to be a gtk-in, qt-out direction on the part of lsb-desktop. Note that selection policy is not currently an LSB policy, but it's felt that this needs to be an SC decision. This might be a good time to start thinking about questions, concerns, etc. From mats.d.wichmann at intel.com Fri Sep 23 05:38:18 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.1 direction Message-ID: Hi Steering Committee, We reached a bit of a dilemma over the LSB 3.x release series. With the successful completion of the ISO ballot meeting, we owe ISO a final version no later than Oct 31. As this should be an approved LSB spec, we need to leave time for review and approval, so the deadline is fast approaching. At the same time, we need to fix a few moderate to serious errors in the spec which implies we need to do an LSB 3.1 release - this is probably not a surprise. The dilemma is that the two events would be far better aligned than disjoint. It doesn't say great things about our stability promise if an ISO spec is delivered in October, perhaps published in December, and in January we deliver a new spec. New resources did not magically materialize to help move a 3.1 spec along, so we're faced with a "if the deadline is about now, we can't do it all" situation. Nick has proposed a scheme yesterday where we could stage the 3.1 release by module. Some words on that are here: http://www.linuxbase.org/LSBWiki/ProjectPlan31 Since this would need to be put in effect Real Soon Now (well, today, since Nick is away next week), I thought I'd ask if this seems acceptable. From anderson at netsweng.com Fri Sep 23 06:00:56 2005 From: anderson at netsweng.com (Stuart Anderson) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.1 direction In-Reply-To: References: Message-ID: On Fri, 23 Sep 2005, Wichmann, Mats D wrote: > Nick has proposed a scheme yesterday where we could stage > the 3.1 release by module. Some words on that are here: > > http://www.linuxbase.org/LSBWiki/ProjectPlan31 > > Since this would need to be put in effect Real Soon Now > (well, today, since Nick is away next week), I thought > I'd ask if this seems acceptable. Given the utter lack of resources to apply to these problems, I don't think the staggered schedule is going to really make much difference. I think the bugs will still be unresolved as the later deadlines come and go. For example, an additional 4 weeks won't be enough to write the docs needed for the C++ bug. 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 rajesh.banginwar at intel.com Fri Sep 23 10:32:06 2005 From: rajesh.banginwar at intel.com (Banginwar, Rajesh) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.1 direction Message-ID: I don't see this as a problem. For ISO all that matters is core. The only comment I have is why not combine the Graphics and C++ together for RC1 and release? Also, we need to keep in mind that the desktop release will happen right after that. So the database updates will need to be synchronized. Thanks, -Rajesh > -----Original Message----- > From: lsb-sc-bounces@freestandards.org [mailto:lsb-sc- > bounces@freestandards.org] On Behalf Of Wichmann, Mats D > Sent: Friday, September 23, 2005 5:38 AM > To: lsb-sc@freestandards.org > Subject: [Lsb-sc] LSB 3.1 direction > > > Hi Steering Committee, > > We reached a bit of a dilemma over the LSB 3.x > release series. > > With the successful completion of the ISO ballot meeting, > we owe ISO a final version no later than Oct 31. As this > should be an approved LSB spec, we need to leave time > for review and approval, so the deadline is fast > approaching. > > At the same time, we need to fix a few moderate to > serious errors in the spec which implies we need to > do an LSB 3.1 release - this is probably not a surprise. > > The dilemma is that the two events would be far better > aligned than disjoint. It doesn't say great things > about our stability promise if an ISO spec is delivered > in October, perhaps published in December, and in > January we deliver a new spec. > > New resources did not magically materialize to help > move a 3.1 spec along, so we're faced with a "if the > deadline is about now, we can't do it all" situation. > > Nick has proposed a scheme yesterday where we could stage > the 3.1 release by module. Some words on that are here: > > http://www.linuxbase.org/LSBWiki/ProjectPlan31 > > Since this would need to be put in effect Real Soon Now > (well, today, since Nick is away next week), I thought > I'd ask if this seems acceptable. > > > > _______________________________________________ > Lsb-sc mailing list > Lsb-sc@freestandards.org > http://mail.freestandards.org/mailman/listinfo/lsb-sc From nick at usenix.org Fri Sep 23 11:07:43 2005 From: nick at usenix.org (Nick Stoughton) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.1 direction In-Reply-To: References: Message-ID: <1127498863.27241.12491.camel@collie> On Fri, 2005-09-23 at 10:32, Banginwar, Rajesh wrote: > I don't see this as a problem. For ISO all that matters is core. > > The only comment I have is why not combine the Graphics and C++ together > for RC1 and release? > As far as I'm aware, there are no real problems with Graphics, save for bug 707 (uplift OpenGL), which we tied to 4.0 anyway. So we could do Graphics at the same time as Core. However, I was trying to get as little as possible in the Core release so as we can maximize the likelihood of achieving the deadline! And C++ has a whole other set of problems (as indicated by Stuart), so tying it to that may unnecessarily slow its release. > Also, we need to keep in mind that the desktop release will happen right > after that. So the database updates will need to be synchronized. > We need to get the desktop stuff to use the new module tables ... which may mean completing the module design! (see the Module and ModLib tables). This would allow desktop libraries to be added to the db without affecting any of the other specs. Anyway, as the project grows, always releasing everything at once will get exponentially harder; I believe it is imperative that we start to allow each module to move at its own pace. If 3.1 C++ can't be done till Nov 06, well, so be it! Each individual spec-set (i.e. generic+arch) should have its own independent life. Only as we bump core up a major version do we have to think of the impact of that on all the dependents. I suspect that major releases will still have to be lock-stepped because of potential ABI changes. -- Nick From mats.d.wichmann at intel.com Fri Sep 23 11:37:17 2005 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:54 2007 Subject: [Lsb-sc] LSB 3.1 direction Message-ID: >> Also, we need to keep in mind that the desktop release will >> happen right after that. So the database updates will need >> to be synchronized. >> >We need to get the desktop stuff to use the new module tables ... which >may mean completing the module design! (see the Module and ModLib >tables). This would allow desktop libraries to be added to the db >without affecting any of the other specs. This is not as much of a problem; desktop isn't a 3.x target, and we should branch the specdb tree as soon as possible after the 3.1 stuff is out, so that desktop goes into Head and we can continue to maintain 3.1 if needed.