[Fwd: Re: [cgl_discussion] Reposting my query about CGL-LSB
subhabrata.biswas at wipro.com
Mon Feb 17 05:23:46 PST 2003
> -----Forwarded Message-----
> From: Craig Thomas <craiger at osdl.org>
> To: Subhabrata Biswas <subhabrata.biswas at wipro.com>
> Subject: Re: [cgl_discussion] Reposting my query about CGL-LSB compliance
> Date: 14 Feb 2003 09:44:08 -0800
> As for LSB certification, you are correct that the work group does rely
> on either an LSB certification brand or as mentioned by Jeremy, making
> sure the LSB tests pass via a self-validation. I personally feel that
> it is a good idea if you as an individual would like to run the LSB
> tests on certain distributions that have CGL features, to assure that
> no LSB regressions occur. As far as I understand the LSB and its tests,
> the test suite is free to download and run by anybody (open). However,
> only the LSB has the authority to _certify_ a distribution. Therefore,
> you should be able to freely run the tests.
Based on your suggestion that I can try running the LSB test
suite to verify LSB regressions, is there a place/group where
these results can be shared? I am not looking at a formal
announcemnt/proclamation by us of a particular CGL-patched linux
having passed or failed LSB test suite validation.
I was wondering if there's a discussion group where these self-
run test results of ours can be shared to get suggestion and views
from the open source community.
Ofcourse Rusty has already pointed to the LKML, the concerned
CGL/kernel patch maintainer and this discussion list as some of
the 'Interested Parties' for the LSB compliance test of CGL patches,
specially if non-conformity (which in non-diplomatic terms is called
bug) is detected. What happens for result which I feel would be good
to cross-check and share with the community?
> One of the best ways to contribute to the CGL effort is to mimic what is
> being done for the POSIX Interface compliant requirements (1.2.1 through
> 1.2.4). Here, a sourceforge project was created called the Open POSIX
> Test Suite. Contributors are adding POSIX test cases to validate
> compliance. It is hoped that in the future, the LSB will utilize these
> test cases and incorporate them into their certification test.
> That said, there has been some recent discussion to provide a similar
> project for IPv6 validation tests. Investigations are underway to
> determine the best method to deploy a test suite (heavily leveraging
> the Tahi project). The goal again is to hope that these tests
> eventually make it into the LSB suite in the future.
> If you or your group is interested in contributing to CGL activities,
> this would be the place to add the greatest benefit to CGL.
Thanks for this information. Me along with my group will be more than
interested to contribute to this activity. I am trying to gather more
info. on this from the CGL discussion list archives, but would appreciate
pointers/indicators about where information on this is available. Correct
me if I'm wrong, but as I understand no project/activity has yet started
for developing these IPv6 validation test suites.
> So far, there should be no need for a CGL feature addition to change the
> behavior of a core system call. Therefore, any CGL additions should not
> affect the LSB compliance. However, in the event that an LSB regression
> occurs, it should be up to the distribution first to assure that the
> patches include were corrected. If the investigation of a regression
> leads directly to a CGL feature, then the I would assume that the CGL
> technical board will be involved in making some sort of decision
> regarding the potential conflict between the LSB spec requirement and
> the suspected CGL requirement causing the LSB regression.
Thanks for sharing what would be CGL's stand on these kind of conflict
scenarios. I really appreciate it.
subhabrata.biswas at wipro.com
More information about the cgl_discussion