From cyeoh at samba.org Tue Sep 23 20:30:37 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] bugs database Message-ID: <16241.4061.203449.734511@gargle.gargle.HOWL> I think the bugs database (http://bugs.linuxbase.org) is almost ready to go. I have populated the components for Development Environment, Application Testing, and Runtime Testing and Stuart has done the Specification. If Mats could do the same for the Sample Implementation and Marvin the Application Battery then I think we can go live. Do we need to have separate components for Website? I suspect we can just a have a general component. We may also want a misc component for all of the products in case someone wants to file a bug that doesn't fit into any of the current components. So far we have used the convention that the default owner for bug reports in a component go to the appropriate mailing list. In general I think this is a good idea and makes it much less likely that new bugs will go unnoticed for ages which can happen currently with the Source Forge bug database. At some stage we will have to move all of the bugs from Source Forge over to bugzilla. I guess this will have to be done manually? If possible we'll want a way to disable the bugs database on Source Forge so people can't lodge any more bugs there. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From heffler at us.ibm.com Wed Sep 24 09:54:36 2003 From: heffler at us.ibm.com (Marvin Heffler) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] bugs database Message-ID: I have added components for the Application Battery. Regards, Marvin Heffler Linux Standard Base IBM Linux Technology Center 11400 Burnet Road, Zip 908-1A33 Austin, TX 78758 (512) 838-0953 T/L 678-0953 "Christopher Yeoh" Sent by: lsb-sc-admin@mail.freestandards.org 09/23/2003 10:30 PM To: LSB Steering Committee cc: Subject: [Lsb-sc] bugs database I think the bugs database (http://bugs.linuxbase.org) is almost ready to go. I have populated the components for Development Environment, Application Testing, and Runtime Testing and Stuart has done the Specification. If Mats could do the same for the Sample Implementation and Marvin the Application Battery then I think we can go live. Do we need to have separate components for Website? I suspect we can just a have a general component. We may also want a misc component for all of the products in case someone wants to file a bug that doesn't fit into any of the current components. So far we have used the convention that the default owner for bug reports in a component go to the appropriate mailing list. In general I think this is a good idea and makes it much less likely that new bugs will go unnoticed for ages which can happen currently with the Source Forge bug database. At some stage we will have to move all of the bugs from Source Forge over to bugzilla. I guess this will have to be done manually? If possible we'll want a way to disable the bugs database on Source Forge so people can't lodge any more bugs there. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia _______________________________________________ Lsb-sc mailing list Lsb-sc@mail.freestandards.org http://mail.freestandards.org/cgi-bin/mailman/listinfo/lsb-sc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20030924/77c83319/attachment.html From gk4 at austin.ibm.com Wed Sep 24 13:43:03 2003 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] bugs database In-Reply-To: <16241.4061.203449.734511@gargle.gargle.HOWL> References: <16241.4061.203449.734511@gargle.gargle.HOWL> Message-ID: <1064436182.8705.692.camel@gkraft4> Chris, I'm having a hard time auto filling some of the bugzilla form attributes like I did for sourceforge. Here is what we did in the past: http://www.linuxbase.org/spec/lsbreview.html Here is what I'm trying to setup: http://www.linuxbase.org/~gk4/lsbreview.html I would like to be able to fill in the form like http://bugs.linuxbase.org/enter_bug.cgi?product=Specification?bug_file_loc=URL_TO_PAGE_BEING_VIEWED Any hints? George (gk4) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20030924/720be6ec/attachment.pgp From cyeoh at samba.org Wed Sep 24 22:28:26 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] bugs database In-Reply-To: <1064436182.8705.692.camel@gkraft4> References: <16241.4061.203449.734511@gargle.gargle.HOWL> <1064436182.8705.692.camel@gkraft4> Message-ID: <16242.31994.207904.190484@gargle.gargle.HOWL> At 2003/9/24 15:43-0500 George Kraft writes: > Chris, > > I'm having a hard time auto filling some of the bugzilla form attributes > like I did for sourceforge. > > Here is what we did in the past: > > http://www.linuxbase.org/spec/lsbreview.html > > Here is what I'm trying to setup: > > http://www.linuxbase.org/~gk4/lsbreview.html > > I would like to be able to fill in the form like > > http://bugs.linuxbase.org/enter_bug.cgi?product=Specification?bug_file_loc=URL_TO_PAGE_BEING_VIEWED > > Any hints? > > George (gk4) > Checkout the "Remember values as bookmarkable template" button on the add new bug report page. It generates URL's like this: http://bugs.linuxbase.org/enter_bug.cgi?product=Runtime%20Tests&version=unspecified&component=lsblibchk&rep_platform=All&op_sys=All&priority=P2&bug_severity=normal&bug_status=NEW&assigned_to=&cc=&bug_file_loc=http%3A%2F%2F&short_desc=lsblibchk%20should%20be%20built%20lsb%20comforming&comment=%5BMoved%20from%20SourceForge%2C%20%23707719%5D%0D%0A%0D%0AThe%20lsblibchk%20program%20will%20not%20execute%20by%20default%20in%20the%0D%0Asi%20since%20the%20si%20does%20not%20have%20%2Flib%2Fld.so.1.%20Instead%20it%0D%0Ashould%20be%20looking%20for%20the%20appropriate%20ld-lsb%20file.&dependson=&blocked=&maketemplate=Remember%20values%20as%20bookmarkable%20template&form_name=enter_bug which would pass them to the bugzilla form with the fields prepopulated. We may have issues with the submitter needing an account to submit a report. I don't know if bugzilla has the ability to anonymous bug reports, or maybe we'll need to create a dummy account. Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From cyeoh at samba.org Tue Sep 30 17:40:52 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Licencing cleanup Message-ID: <16250.8852.721297.657086@gargle.gargle.HOWL> Matt has pointed out that we have been rather inconsistent (sometimes contradictory I think) with the Licences we attach to our test programs. Some of the test programs under "tests/misc" have the same licence as TET which has various "rename if modified clauses" which may make it impossible or at least very hard for Debian to package. For these tests specifically (appchck, cmdchk, cxxabichk, devchk, libchk, pkgchk, rpmchk) I think we (the LSB) can live with out these restrictions. AFAICT all of this code is copyright to the Free Standards Group (all written by either Stuart or myself). rpmchk contains some RSA Data Security copyright code which has a BSD advertising clause which might cause us a bit of pain in the future - I wonder if there is an alternative here?. Andrew, I'm specifically interested in getting your thoughts on this. TET was released under this licence so I'm wondering if there are reasons, related to running a certification program, that we would want to have these modification restrictions? Regards, Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From ajosey at rdg.opengroup.org Tue Sep 30 22:13:22 2003 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Licencing cleanup In-Reply-To: Christopher Yeoh's message as of Oct 1, 10:40am. References: <16250.8852.721297.657086@gargle.gargle.HOWL> Message-ID: <1031001051322.ZM4710@skye.rdg.opengroup.org> Does Debian have a problem with OSI approved licenses? TET is under the Artistic license. The other testsets from The Open Group are effectively under The Open Group Test Suite License, http://www.opensource.org/licenses/opengroup.php which is a modified artistic license (i think they still have the expanded license [artistic + mods] in the LSB tree rather than the collapsed version that was submitted and approved by the OSI). The restrictions on TET placed by the former are more flexible than the latter -- the latter picking specific restrictions to preserve the existing test modes. Our choice of Artistic for the TET was primarily that we like to have Artistic control over our product:-) If we were to look at relicensing, of all the other licenses today we would probably look to one of Larry Rosen's - the AFL or OSL V2.0. Perhaps it would make things easier for Debian if the license clauses were updated to the approved OSI versions for the testsets. On Oct 1, 10:40am in "[Lsb-sc] Licencing c", Christopher Yeoh wrote: > > Matt has pointed out that we have been rather inconsistent (sometimes > contradictory I think) with the Licences we attach to our test > programs. > > Some of the test programs under "tests/misc" have the same licence as > TET which has various "rename if modified clauses" which may make it > impossible or at least very hard for Debian to package. For these > tests specifically (appchck, cmdchk, cxxabichk, devchk, libchk, > pkgchk, rpmchk) I think we (the LSB) can live with out these > restrictions. > > AFAICT all of this code is copyright to the Free Standards Group (all > written by either Stuart or myself). rpmchk contains some RSA Data > Security copyright code which has a BSD advertising clause which might > cause us a bit of pain in the future - I wonder if there is an > alternative here?. > > Andrew, I'm specifically interested in getting your thoughts on > this. TET was released under this licence so I'm wondering if there > are reasons, related to running a certification program, that we would > want to have these modification restrictions? > regards Andrew