-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clay Lenhart <[EMAIL PROTECTED]> writes:
> I want to take a step back and look at the biggest issue and why, in my > opinion, it is the bigest issue right now. > > The mailing list and forums (with monitors) is not a big difference. One may > be slightly better than the other. The problem is that a majority of people > prefer one way (mailing lists) and a influencial minority prefer another > (forums). This is A Sign Of Things To Come and why it is hotly debated. When > a technical decision that have similar, debatable, advantages and > disadvantages, how will this be resolved? The same way? How did the influential minority get its influence? What will happen when other people on the list do more work and gain more respect? If this is an Open project, and based on a meritocracy (every OSS project is meritocracy whether it is voted in or not), then I suspect we will be *officially* using mailing lists soon :) > It appears to the older members that the new members are trying to hijack the > project. Perhaps. If I were someone thinking that someone was trying to hijack my code I would take a step back for a second. Say the assumption is correct, and that we are just here to hijack the code and that we won't get anything done. So what? Which ever project does the best work will win. So what is the problem. I don't think anyone is trying to hijack. Probably a better word would be "encourage" or "cooperate" > I wished that the older members had the view of Linus. Linus does not feel he > directs his project, but that he channel's the energy of others to the > project. http://kerneltrap.org/article.php?sid=398 It is as if the older > members fear the newer members will invalidate their plan for the project. ... you also have to be open to criticism... Linus was very comfortable with his technical skills. > It would help to lay out how decisions are made in this group and how new > people can participate in the direction of the project. The nice thing about > Jakarta's voting structure is that it is clear to everyone how decisions are > made. I have NO idea how decisions have been made in past but I have to be honest - if they are made like I *think* they are being made, by a central group without any influence from the outside, this will be very bad for the project. > Also, I would like to start a new member FAQ. Here are the questions I have > (and some answers). I am interested in the answers to the questions I do not > know. That is a good idea. I am working on the Anakia docs. If you develop any content we should get it in CVS an on the site... Thanks for offering to help. > How do I contribute? (bugs, patches, etc) > > What is the ideal patch? > connect to CVS, download the latest version > make your changes > If the only change on a line is only dentation, then do not indent (this will > affect diffs, plus identation is automatically done by JIndent) or Emacs :) > make sure your patch compliles by running > ant clean > ant jar (with an unset CLASSPATH) to avoid old libs) > Make sure it passes the tests by running > ? > make a diff file(s) between the CVS version and your version > on Linux run: diff -u CVSFile YourFile > DiffFile > Create a JUnit test that proves that the bug exists in the CVS version, and not > in your version (bugs or features) Ideally there would be a JUNit test. Some bugs can't have tests. AKA documentation bugs, design style bugs, refactors, etc. > Upload the files to Patches in Sourceforge. I don't like the SF patch mechanism. Am I the only one?? Can't they just send them to the list? > How do I discuss development issues with more experiences members? mailing > list or forums -- ed note: Hopefully this will change to one or the other, but > this is the truth right now. mailing list. > How long do patches take to be applied to CVS? I would like to establish another policy. That if you don't here back from us with 2 weeks assume that your patch was rejected. 1. This will keep us on our toes. 2. This will avoid us sitting on patches forever. I hate OSS projects that apply patches months after I sent them. We should also accept or reject patches as a whole unless this was approved by the patch submitter. This has the advantage of explaining to a potential submitter the reasoning why a patch was invalid. This is a great way to work with new engineers. > How do I know if the patch has be rejected? How do I dicuss this with the > person or group that rejected it? > > What do I do if the patch does not get applied to CVS in the normal time > period? > > > > -Clay <snip> see above.. Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ Intellectual 'property' is to property as fool's gold is to gold. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8G5zBAwM6xb2dfE0RAsdBAKCAQAeM/t9s1gCPa1d9dGCUf0BNsgCguAs1 tXUabCM+q0EfrkGNjA8O9w4= =8asP -----END PGP SIGNATURE----- _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
