Darn those mailing list headers!
------ Forwarded Message From: Jason van Zyl <[EMAIL PROTECTED]> Date: Sun, 16 Dec 2001 12:18:23 -0500 To: fredt <[EMAIL PROTECTED]> Subject: Re: [Hsqldb-developers] Project Guildelines On 12/16/01 11:13 AM, "fredt" <[EMAIL PROTECTED]> wrote: > On 30 November I posted some Rough Code Guidelines to this list. In the > light of some of the posts, I think I ought to expand and clarify some > issues to avoid any obstacles to further development of the code. > > There are currently three main developments being led by our Project: > > 1. Mark Tutt's new codebase as he described it recently in his post here and > in the forums in the past. Mark stated that he is no longer interested in the project. The statement is made here in this message: http://www.mail-archive.com/hsqldb-developers%40lists.sourceforge.net/msg000 01.html This new codebase is not in CVS and he wanted to be removed from the project so where is this new codebase? > 2. Efforts to modularise and rework the current codebase to overhaul JDBC > and other functionality. These are mainly led by Campbell but recently we > had contributions from Hiep and Clay. Could you summarize these efforts for the group. Or post links to the webform entries? I think we are all interested in the details. > 3. Efforts to fix the bugs and improve SQL and JDBC compliance in small > areas. These are led by myself based on contributions from many users and > developers. Mauricio will be helping to ensure JDK 1.1.x compliance and > hopefully contribute code as well. I believe that JB also has some contributions in this area as well. > I am discussing mainly the 3rd group of efforts below: > > Mauricio correctly pointed out the following: > --quote > Just keep in mind while writing the proposal that the current > HSQLDB is not really a GNU-type project, where you are forced to contribute > changes back to the community. I understand from looking at the forum posts > that many developers use this code as part of a larger commercial project, > and there has to be a way for them to contribute changes back to the > community if they desire to do so. > ---end quote > > The above has always been a main consideration in the development and > maintenance of the Hypersonic into HSQLDB code. With the modified apache style license that was originally set forth by Thomas Mueller has always made this possible. > Implication 3.1: Changes to code base will be made in the CVS in incremental > steps to allow outside developers to reincorporate their changes into the > code base and hopefully contribute them back to the Project. > > Implication 3.2: If possible, changes to SQL /JDBC should be linked to > entries in the properties file which allows at least some backward > compatibility with previous versions. This applies where there are two > different valid interpretation of the same features. (there are already > examples of this, see patch 491272 for instance). This clarifies my > stipulation in the Rough Code Guidelines that: > > "Improvements to SQL and JDBC interfaces should bring HSQLDB closer to > common standards. Clear notification should be given when improvements > _might_cause incompatibilities with existing applications that use HSQLDB. > This area is very important and needs special attention." > > Regarding the 2nd group of efforts: > > Implication 2.1: If we are going to use the CVS regularly we need to have a > structure in the CVS for the inclusion of those contributions as they are > being developed. For example, Clay has recently made some contributions with > the aim of changing the existing code to support multiple database and > different transaction isolation levels. His effort needs a lot of > development and testing before they become part of a release. In the > meantime, group 3 changes would be introduced regularly and accepted or > rejected in a shorter time-frame -- we need to establish procedures to do > both at the same time. > > Implication 2.2: We need to modularise more as we go along. There are two > completely different uses of HSQLDB as applet and application / server which > have different size implications. We need to be able to build both out of > the code base, keeping 1.1.x and 1.2.x and above compatibility for both. > > I will later release the Rough Guideline together with the contents of this > post on the web site. I think you should also include the meritocracy guidelines that have been discussed on the mailing list and the use of the mailing list should be stated in the guidelines. By generally following the Jakarta guidelines you can simply point people to these documents: http://jakarta.apache.org/site/guidelines.html In this message I also outlined a proposal which many people took the time to answer: http://www.mail-archive.com/hsqldb-developers%40lists.sourceforge.net/msg000 26.html How do you intend to incorporate those into the guidelines. Namely i), ii) and iii) in the above mentioned proposal. In that same document, outstanding are some answers to some very serious questions. I caution anyone participating in the project to take note of the answers provided for i) and ii). Namely what is HSQL Development Group, how the license has changed and why? I will point out that original hsql (http://hsql.sourceforge.net) site has changed to state clearly the licensing terms of the original project which is a license that clearly states that the code is copyright "Hypersonic SQL Group". Developers please look carefully at the license currently listed in the source. It now states a copyright of "HSQL Development Group". I know that Thomas Mueller did not give his permission to change the license unless someone knows something I don't. So in essence what has happened is illegal. It is not that it can't be easily corrected in the source, the issue is how did it happen in the first place? Mark mentioned that Michael Cannon is the 'principle' of the HSQL Development Group (whatever that is). So in effect, the license changed magically and Michael Cannon somehow became the principle of this group, and it has also been mentioned by Mark that we should wait for Michael to reappear before we decide anything. To me this is absurd. These are things that have been stated on the list in the past few days and they can be found in the mail archive. Again I urge you to scrutinize the facts carefully. What has been done is not right. You can't just up and change the license of a codebase. Other facts to mention is that there was originally no discussion that I can find about the guidelines for the project when it started. Eight months into the project is not the point at which we should be mandating guidelines. The answers to the questions regarding licensing and project origins have been skirted around. Mark said that 'no one owed me an explanation', but the the people contributing code should definitely know. If this is kind of answers we get, that we don't deserve answers, ask yourself if you really want to participate in a project like that? My opinion is that this project is not run like a typical open source project for the basic fact that these issues have not been resolved, no one seems to want to answer them and nothing has been disclosed. Mark Tutt doesn't appear to want to answer the questions or participate anymore, Michael Cannon can't be found and Fred you frankly haven't clarified anything. I certainly don't believe it is in anyway rude or presumptuous to demand the answers to these questions. Do you really want to contribute your code to a project where these issues are left unanswered? > > Fred Toussi > > > _______________________________________________ > hsqldb-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hsqldb-developers -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons ------ End of Forwarded Message _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
