2009/5/2 Adriano Marques <[email protected]>: > Hello Bart! > > Thanks for your input, and I understand your concerns. Please, read my > remarks in line. > >>> It will be happen with UMPA, PacketManipulator, UmitBT, ZION, QS(QuickScan), >>> BluetoothSniffing, etc. The distribution of the package will be the same, >>> what changes is the import. >> >> I wanna hear what do you mean by 'the distribution of the package will >> be the same". Seriously. > > By saying that, Luis meant that it will be possible to distribute UMPA > as a separate package for others to use just as you currently do. The > *only* difference, is that people using umpa will have to do import > umit.umpa instead of import umpa. I know someone could say it is > easier to do import umpa, and I agree with that. But... come on! We > have auto completion, and the goal here is to make our organization > grow better and stronger with a sane pattern for all current projects > and all projects to come.
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 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. 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. 2) Various problems to mantain branches and trunk in svn. 3) Problems in the distribution to mantain everything separate. But this was the original situation? 4) Misalignment in the code and various conflicts that should be merged or solved on every release of any application. > >>> All projects belongs to Umit Project, so it make sense that all of them >>> should be included on umit package. It is similar like Apache organization, >>> Universitys and others organizations do. We are not inventing nothing :-) >> >> I don't know how much you understand structure of Apache code, but >> not. It's not the same. Sorry. > > Yeah, that's just an example. We don't actually plan to follow every > step from Apache. Our goal here is to have every project under a main > module, which is umit. That will make it easier to integrate, maintain > patterns, and distribute. It may sound ok to keep as we currenlty are, > but think of how we'll maintain the pattern when we have more 10 or 20 > other projects and everyone decide to take a different path. It won't > work. If everyone just keep using that methodology of putting their > package inside umit, we'll have a better integration and it will be > clear to everyone which pattern to follow. > >>> Please don't discuss it on IRC, if you have something against please send it >>> to the mailing list. >> >> Firstly, who decide it? And why someone wanna decide about some >> projects which are made by other contributors? I don't like this kind >> of words like "UMPA will be something", because I would like to have a >> discussion first. > > Mentors propose the ideas, then, *if* it is something that people > doesn't agree we bring that to the list to discuss. But, the final > answer is upon the mentors, because if we leave to be decided by > everyone it will take forever to decide on any subject. We decided to > take this path. You didn't like it, that's ok. Now, you must come with > solid reason on not to go on this way, and perhaps technical > impossibilities that proves us wrong. Otherwise, there is no reason to > change, as the goal of Summer of Code is to improve the project and > that's what we believe well get if we take this path. > > I understand it it a boring work, and that it may sound awkwards now, > but it is something that will help both your project and the > organization, don't worry. > >> Secondly, this idea about UMPA e.g. is completely bad. I wanna hear >> some real arguments first. Then I will say why it's bad. > > Let's try to do the oposite, tell us why it is bad, and then we try to > adapt the organization goal to the project needs if it is necessary > and bad indeed. > > Hope you understand our goals, and rest assured that we're always > trying to improve without any willing to prejudice any project or > contributor. Some decisions simply won't make everybody happy, but > that's life. If we try to make everyone happy, we'll never succeed on > that, but we'll certainly try to chose the best for everyone in the > group. That's the Nash Theory, uh? ;-) > > > Kind Regards, > > -- > 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 > -- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ 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
