Hello Francesco! Thanks for your input!
>> 1 - Create the Umit Project Organization officialy, have a HQ, address, >> registers, etc. >> 2 - Create a business model to generate income and afford Umit Project >> Organization growth. > > I think that everyone here want to know more information about that > and how to help you to realize it. Probably it's better to create a > separate thread or a private mailing list regarding the organization > that's going to be created. Sure, I'll do that at the appropriate moment. Right now I'm studying the possibilities for this proposal. Whenever it comes to disclose the details, and get community opinio/help I'll doing that through a private mailing-list that I'll create. Thanks for your interest! That's great to see you all suporting this idea. >> 1 - Avoid keeping things separated. No project that we work on should be >> offered by other website, domain, etc. That's good for you and that's good >> for Umit Project. Why is that good for you? It is good because you have a >> wider volume of downloads for your tool/library, a bigger community to test >> and support it, and that will reflect to Umit Project brand, and as Umit >> Project brand grows stronger that will reflect back to you. That's the way >> it works for Apache Foundation (please, note once again that it is not >> package namespace related that I'm mentioning this right now) > > Acceptable. My idea is also to have an aggregated blog like > planet.umitproject.org that collects blog posts of contributors. That's an awesome idea. We can also do something similar with contributors twitters. Do we have any open source solution for those two things that we can serve? >> 2 - Setting a namespace. That namespace is simply a way to state where the >> piece of software (tool or library) came from, and will certainly help us to >> keep things sane, because: > > Regarding this will be better to create a democratic survey to have a > clearer idea on how many agreed with that. > If the idea is accepted by a sufficient number of person we have to > choose the namespace to use (umit,umitproject,umitorg btw there's > already another thread in the list to discuss it) Sure we can do a survey, but I can't create one with only one solution for the problems I listed. If someone comes with a second solution (rather than putting everything in a namespace), then I'll be happy to create a survay to collect people opinions. Regarding the namespace to use, we can first try to solve that through a regular thread, and if we find it too hard we can create the survey. Threads are better because we can expose our ideas, do some brainstorming, etc. Surveys are too simplistic for this matter. After further discussion, than a survey is indeed useful. >> 2.a - We can create a sane documentation structure, in which some enters our >> documentation sub-domain, and under umit he can find every project, instead >> of having to find if the code is inside umit, foo or bar. That's intuitive, >> and keeps reference to the Umit Project Organization. > > This is not related to the common namespace but we have to define a > documentation guideline that everyone should follow, like sphinx for > user documentation and epydoc for API etc.. (It's only an example > obviously. We could realize that trough a survey) Indeed, it is not. But if you check the e-mail I sent about the design of the namespace you'll see that a documentation following that hierarchy will certainly be easier to read, search and understand. People developing plugins will certainly find it easier to relate things and find a good consistency to create new plugins. >> 2.b - Avoid conflicts. Someone, in another open source organization may be >> working in a python module named pm, and that will conflict with us if it >> happens that we provide our Packet Manipulator for a user that have that >> other pm library installed. If we have umit.pm, that will be harder to >> happen. I believe that this is the reason folks from Java world adopt this >> namespace pattern, and also the reason why Apache does that. I collected >> some links from some random projects under Apache umbrela and I could verify >> that pattern [0], [1], [2], [3]. >> 2.c - Standard. If we all follow this namespace, we'll all also have the >> feeling that we have to follow the naming convention used by other projects >> under umit. That's something that could work without stating a namespace, I >> know that, but I noted that because it is a nice consequence of adopting >> this namespace standard. >> 2.d - Determine the origin of that software. If other organizations latter >> decide to integrate our softwares into their, they will have to use our >> namespace and that will keep the reference to us wherever that application >> goes also. An example is the case for RadialNet, once again. If it was, >> since the beginning, umit.radialnet, we would have helped to avoid part of >> that confusion. > > These points are not related to a common namespace but by a coding > guideline and by file headers respectively. I agree in the sense that we can solve that with a coding guideline and setting headers. That's right. But the goal here is to have more than one layer of "protection" or "incentiveness", in the sense that people don't need to see the header to realise that it came from Umit Project, and that will stick better in their mind. I think this is Apache's goal. Regarding standard, that adds another layer in the sense that developers will see all the documentation only together, following the same rules, etc. That's more intuitive than simply using the current methods. >> Concerning UMPA, Packet Manipulator and Zion: >> From my point of view, there is no actual prejudice in this restructuring >> for those libraries. If I see one, I would drop it, because it is certainly >> against Umit Project's goals. It is good, because as I said before, those >> libraries will became part of Umit Project's namespace, and that's good to >> avoid conflicts and other bad stuffs (remember the zen of python?). >> A few e-mails ago I said that it would be good also for the sake of UMPA or >> Zion using umit.core stuffs. I regret, and apologize for that. It is indeed >> better that we keep those separated for secondary goals, which is to benefit >> outside world with high quality libraries. That is *ok* to not depend on >> umit.core for those libraries. >> Concernig Packet Manipulator, it is a different thing. It should use >> umit.core and higwidgets whenever possible as this dependency is available >> for every plataform that Packet Manipulator will support, it's small and can >> be easily bundled in our installers and packages. > > I've a copy of higwidgets under my branch with little modifications > and I'm using some of that classes in PM code. Concerning umit.core > I've decided to not use its classes because are related to Nmap and > umit configuration specifically and using those I would had certainly > conflicts with other umit installations. So I would prefer to continue > with PM.Core classes that offers a more flexible solution for my > needs. Indeed, you're right. I think we could move those things into umit.common and I think it won't be a problem anymore, as I proposed in the design thread. Then, we should merge your carges to trunk and create the umit.common with the things that we find that other projects may need that are not exclusively related to the Umit scanning interface. > Sorry for my english I'll try to be as much clearer and concise as possible. > Thanks for reading me! Come on! Your english is ok. Mine is bad sometimes also :-P But I bet your italian is great ;-) 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 ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
