From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1efdd369be089610 X-Google-Attributes: gid103376,public X-Google-Thread: 1025b4,1d8ab55e71d08f3d X-Google-Attributes: gid1025b4,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: what DOES the GPL really say? Date: 1997/07/06 Message-ID: X-Deja-AN: 254991218 References: <5pb8gf$j4m@lyra.csx.cam.ac.uk> <5pim4l$5m3$1@news.nyu.edu> <5pmg6e$nai$1@Venus.mcs.net> <5pmiuv$2f1@camel4.mindspring.com> <5pn2h2$sjg$1@Venus.mcs.net> Organization: New York University Newsgroups: comp.lang.ada,gnu.misc.discuss Date: 1997-07-06T00:00:00+00:00 List-Id: Les says <> Effective software development requires that the scope of use and testing of a piece of software be commensurate with the stage of maturity of the project. When a fix is first developed, it remains in the domain of the fixer until he or she is reasonably confident that it is a correct fix. Then it is propagated to the development team and other people try it out in the context of other things that are going on. When the team collectively thinks that a set of fixes is ready, then it needs to go outside the team to a small selected group of users to see if things work (a process usually called alpha or beta testing depending on the perceived maturity of the release, really I am talking about what I would call external alpha testing here). Then when a release seems to be in a potentially releasable state, it needs to be more widely tested (this is a typical beta test situation). A product can then be initially released to a wider circle of customers, and eventually a full release can be made. If the requirements of the GPL made it impossible to follow this procedure, then the GPL would in practice make it very difficult to develop reliable software. But the GPL in practice does NOT make it impossible to follow this procedure. Although further distribution is always permitted, during the early stages, those involved understand that it is not helpful to widely distribute that which is not ready to be widely distributed. In the case of GCC, the snapshots are available to a number of people, but the Free Software Foundation notes that wide distribution of these snapshopts is not helpful to the GNU project, which seems an exactly accurate assessment, and since people perceive that it is an appropriate assessment, they generally agree. There are some glitches, at one point a CD ROM of the Linux distribution included the snapshots, which was potentially highly disruptive, and some loud yellling at the people involved went on to try to avoid this happening in the future. Note that people's willingness to abide by the informal "do not distribute" rules is based on their perception that the request is reasonable, and is indeed based on a concern to avoid premature distribution. If they felt that the request was based on a desire to hoard software that was in fact ready for wide distribution, they would not concur, and the redistribution would occur. There is a huge philosophical difference between seeing distribution restricted because a group of people agree that it is not a good idea for the good of the project involved to distribute software prematurely, and a situation in which distributable software is being hoarded. Richard Stallman is adamant about the importance of free and wide distribution of software as I think everyone knows, but he is equally adamant that it is a bad idea for insuffiently tested snapshots to be prematurely distributed widely, and will yell loudly at anyone who "misbehaves" in this manner. I know that, I have been yelled at! In the case of GNAT, our position is quite simple, our beta testing works by having very small sets of customers get wavefront releases. They are willing to test these out, because these beta versions fix problems they need to get around, and they are willing to risk the instability of a new version to get around their problem. In my previous message, I outlined the internal QA testing we do to try to minimize the possibilities of such instabilities. When we have something that we feel is potentially ready for release, we distribute it more widely to our supported customers. And more of them pick it up. That actually is a relatively new procedure for us, and resulted recently in the internal prerelease designated 4.10a. Well what's the result? In fact 4.10a is looking good, BUT there are a couple of glitches that have not proved a problem for our customers except in one or two cases, but which absolutely MUST be fixed before a full public release of the 3.10 (oops I mean 3.10 when I mention 4.10 anywhere above). We are now working towards a 3.10b. We will make this available to our customers again, and if it is glitch free, then release it publicly. As I noted in a previous post, releasing free software is actually more difficult than releasing proprietary software. In the latter case, the user community is self limiting to those who are willingf to shell out the money, you have a chance to track the users, and most importantly, you provide at least some kind of support. In the case of free software releases of GNAT made by ACT, the new software is immediately used by tens of thousands of users, we have no idea who is using it, and we cannot provide support to those who are using it. That means that we have to be SUPER sure, to the best of our abilities, that the release is glitch free. We are determined to work carefully towards this goal, and will not release 3.10 before we think it is ready, no matter how loud Ronald and others may yell. Looking back, if we have made release mistakes it has been on the side of releasing too early (in particular the annoying Constraint Error on syntax mistakes in 3.04, and the loader problems in the 3.09 NT come to mind -- the latter is actually instructive, we slightly rushed the 3.09 NT, to get out a CD ROM for STC. Unfortunately, there is now way to cut the CD ROM via the PAL without making the version public, so we were pushed into releasing this a little earlier than we wanted. Now 3.09NT has proved useful to many many people, but it has also caused some unnecessary frustration). It is our goal to avoid such problems in the future. If this annoys some enthusiasts who are panting for the latest version, I am sorry, but I think it is more important to get solid releases, than to get less solid stuff earlier. Robert Dewar