Hi Shash. </Begin RedFace> I had discussed my recent addition to the PersistentFactories offline, but I should have posted online about it to give everyone fair warning. I apologize for that. And thanks to Mike N. for enhancing the Hibernate service to "clean-up "after I checked in. </End Redface>
As for downloading all modules, I am probably not the only one who is running on a Dial-up generally, and as a result, this is not necessarily practical for me. A download and completeinstall of the Default modules alone is 2.5 hours, provided my internet connection stays connected that long, and SF does not drop me. I have no idea how long a download of ALL the modules would take me. The best suggestion I can think of is to second Shash on having a public discussion on core/server checkins before committing. +1 for public discussions. As for running the tests, and checking the changes and the code in question before checkin, DEFINATELY +1 (I do run the tests before I check in, actually. I hope everyone else does as well). >From the tone of your email, somebody has been deleting methods off of core >interfaces without warning??? I will act as look-out for any lynching party that >wants to kick off. +1 for marking methods as deprecated rather deleting them (I >guess make sure deprecation is turned on for compiles). +1 for keeping changes/configs generic in nature as well. Regards, Steve -- Java/J2EE Developer/Integrator Currently "On the Road" 214-724-7741 Platform Independance Rules. Give me a stable platform, and I will give you stable code. ----- Original Message ----- From: Sasvata (Shash) Chatterjee Sent: 9/17/2003 11:25:08 AM To: [EMAIL PROTECTED] Subject: [Keelgroup] CVS checkin discussion > All, > > As we are finessing our way to Keel-2.0, it is important that we watch > our changes to CVS. I would like to propose the following, which in > essence, is an online peer review of the changes: > > - Before making any changes to CVS, propose the changes first to this > mailing list with a summary of the changes, and potential impact to > existing users. > > - To maintain compatibility, make sure core interfaces in keel-core > aren't altered unless absolutely necessary. If needed, make sure we > discuss first on list to exhaust other possibilities. > > - Each contributor must have all Keel modules checked out, and check > that we do not break compiles in any module at all with our checkins. > The discussions above are important, because users are likely to have > implementations based on core-interfaces, and we will not be able to > test we didn't break something. When in doubt, don't change interfaces. > > - Before checkins, make sure to run build-tests.sh and make sure our > compile, unit and functional tests all pass. Note that our tests don't > cover everything yet, so we'll need to be careful even beyond the > tests. But if even our meager tests fail, then...well.... > > - In all changes, try very, very hard to maintain backwards > compatibility. If necessary, deprecate the backwards-compatible > function, and remove after one major release. > > - Changes to Keel should be "generic" in nature, avoid changes specific > to a particular environment, container, browser, etc., or, your own > local setup. > > Please provide some feedback on my comments here. Based on community > feedback, I'll modify and once we have something, we'll put up on a new > "developer" page I want to put up. Among other things, the developer > page will contain the Keel charter, coding guidelines, these CVS > guidelines, branching guidelines, etc. Any suggestions on what else to > put there are most welcome. > > Thanks, > Shash > > http://keelframework.org/documentation > Keelgroup mailing list > [EMAIL PROTECTED] > http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
