Hello Francesco!
> IMHO this is a wrong desing proposal. Packing everything under umit is > a wrong thing to do. > And if everything should be packed under the organization namespace > also the 'umit' should be moved inside this. Than we'll have umit.umit > :P I understand your concerns. But, we actually have several options here. We don't actually need to have umit.umit. umit is a module and umit.gui is actually the main interface. umit.core is used by other libraries, so it shouldn't be under umit.umit as I understood. If we find that we need to keep it separated, than I'm sure we can find a solution for this case in order to have a sane hierarchy for things. > Altough I understand the need to unify everything under a same root, > these are separate programs and libraries. They don't fit in the same > category and should be mantained separate. Indeed. Some of then need to be maintained separately, others don't. It is the case for PM. We all must understand that having everything under umit.something doesn't mean to have everything under the same directory in the repository. We may keep all branches, and still have everything under umit.something. That's completly feasible. > Btw this are the various scenarions we could encounter in if the > restructuring will done: > > 1) Generate errors and conflicts over the install process. Do you > remember the higwidgets problem? Should be the same for various > applications that are not so indipendent. Not quite. The problem we had with higwidgets was because people were installing zenmap and umit in the same machine. not applicable to our changes. Setup tools can deal with that easily also. > 2) Various problems to mantain branches and trunk in svn. Perhaps you said that because you were under the impression that all projects should remain under trunk. But it isn't the goal. As Luis said, you're baiscly going to do the following: mkdir umit mv PM umit/pm change your modules to the same nomenclature we're using change your imports That's all ;-) > 3) Problems in the distribution to mantain everything separate. But > this was the original situation? That's not a problem, as we have to maintain and keep things separated anyway. > 4) Misalignment in the code and various conflicts that should be > merged or solved on every release of any application. No the case. Explained under 2. Thanks for your input! I appreciate your remarks! Cheers! -- Adriano Monteiro Marques http://adriano-marques.blogspot.com http://www.umitproject.org http://www.pythonbenelux.org "Don't stay in bed, unless you can make money in bed." - George Burns ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
