Hello Bartosz, > please don't take these words personally, i know that some of them may > sound a bit bitter.
Don't worry pal ;-). I would say the same for all I write, because I don't master english and somethings often sound more harsh than I would like it to be. > Saying that user has to add 'umit.' and he can use auto-completion is > not an argument. it's the "solution". more, this solution make some > dependecies to the editor etc. in general, it sound like Microsoft > idea. But lets follow.. Say that to Apache ;-) There is *no* problem on typing umit. people do import of libraries with names way bigger than umit.umpa all the time and no one decide not to use that library because the name is too big. We're very far from being Microsoft in that sense. > I'm sorry Adriano, but please do not use 'better' and other adjectives > which are non-measurable in technical world. I wanna see some facts. I'm sorry, but it is measurable. We we say that having everything under umit. keeps things sane, it is a technical benefit. When people see umit.umpa, umit.zion, umit.pm, umit.whatever, they realize where this package came from, where to find further help and instructions, and under which umbrela the project is. That agregates value to your library, and agregates value back to Umit's brand also. That's indeed a benefit in both technical and organizational senses. > When I compress your words above i got only one thing 'it's for > integration'. But i don't see how it would help. Worse, I see how it > would break integration process. So, please write in some points, > benefits of it. I really wanna read and understand it. Maybe I'm > wrong. I don't see how this will break the integration process if it is for integration's sake. That's just as simplistic for me. Let's try to keep things from another perspective: we've set a point. Intead of criticize, try to point out the issues you see then. This way it looks like you simply didn't like our idea and you want to fight it back. > OK. Is it about Summer Of Code or about Umit Project? > Sorry, but if > you see this line between mentors and students, so I have a question. > There is 3 mentors, and 5 students. But there is more contributors. > More, Summer Of Code is 3 month period. What about the rest of 9 > months? It is about Umit Project. I am it's administrator and founder. I have steped back from coding to dedicate on up lifting this organization and make it grow stronger. That includes creating an official organization and managing to have funds to afford our contributors to work on Umit and receive money outside SoC. Therefore, whenever I see something that needs improvements I ponder about it, and I ask people to follow it for organization's sake. If it is something that needs extra pondering, I ask the oldest contributors what they think about the idea. If, in the end contributors aren't happy with our decisions, then we trow that on the list for discussion and then we decide that together. If we can't converge into the same point, then I have to decide upon what I find to be the best option for Umit. That's simply the way it works for any other organization (Python, Apache, OpenOffice, etc.). The titles may change, but in the end there needs to be someone to put a period in a subject and take the decision or people will gossip on that forever. > Then the rest of us have the same importance? Sure everyone do. It isn't because I'm the admin and you're not that I'm more important than you. All we're discussing here is for Umit's sake, not Adriano's sake nor Bartosz's sake. That's why we simply don't take a decision and impose that, but we leave it open for discussion, and I'm taking the time to answer you and everyone so that we can all try to converge to the same opinion. > I don't any > relation between restructing of Umit Project and Google Summer Of > Code. Google Summer of Code is when we get most people contributing. Contributors are getting money from Google to develop open source solutions for Umit Project. That's the goal and that's the relation. It is something that we need to do, and we fortunately have Google to afford you guys to do that. Otherwise, it would take longer than we would like it to be. > If you really see (I'm hoping you don't), then explain me what > about other 9 months where there is 3-4 active developers? If you > don't the relation, please stop use argument about mentors/students. I understand your point. I'm sorry about using misleading titles in this case. Unfortunatelly, we don't have proper titles for everyone. I often try to get conseil from the closest contributors, and I don't try to ask everyone. You're right, because you are a mentor and I didn't ask what you think before proposing the idea. But I didn't do that with Devtar and Rodolfo as well. I just try to get one or two old contributors to agree and support the idea, than I propose it. > Sincerely, I would like to see how it would help us. It will eternaly link your library to umit, and whoever use it outside umit will know where it came from. That's a significant benefit, and will bring confidence to your library. We all know that we prefer to use a library from a known organization rather than a library writen and maintained by only one person. > Francesco pointed a lot of arguments agains this idea. More e.g. UMPA > use exactly 0 line of Umit code. One day, it may come to use. > It doesn't need to be integrated in > any way. UMPA will come bundled with Umit. > It makes only limitation for UMPA. There is no limitation at all. Independent UMPA will be only one setup.py step away, always. > It has different licence. It is LGPL. There is no conflict. > Umit uses UMPA. But UMPA is a library and we are hoping that other > projects might use UMPA in the near future. Another reason to have umit.umpa. That will encourage people to use it because it is maintained by a living organization. > But library it's a > library. It's a bit distinct between library and anything else. If I > were in other project and I would like to use some library to modify > network packates, and I will see UMPA as a part of something bigger, > propably I would drop it, because I will get more than I expected. The developer will download umpa.tar.gz and he will see that there is no extra on that. We can make that clear in the about. Honestly, when I'm chosing a lib and I see one from apache and another from somewhere else, I don't think I'm getting more than I needed. Actually, I think that I'll get a better library than the other. > I don't need then GUI and some application. I wanna library. You can package umit.umpa alone, without including gui or whatever. The goal, as I said in answer to Francesco's mail, isn't to have everything going inside trunk, but everything using the same module schema. > Why any > projects always seperate library from the other parts of projects? > Because it's useful. Because someone else can use it and don't feel > confuse. If we're talking about 2 or 3 libs, than you might be right. But as we grow bigger, that will be certainly the opposite. It may end up on each project forking, and adopting different nomenclatures and patterns. > Please, don't make another Microsoft Windows from this. Let's > keep UNIX style. since 60's it looks like it's a good way to separate > things. Sorry Bartosz, but I can't understand that drama. We're not Microsoft in any sense, and chosing to have everything under umit doesn't mean we're evil or that we make bad choices. > Why Qt is not included in KDE in any way? Why Gtk is not > included in Gnome package? Would you really want to use gnome.gtk ? That's first because QT and GTK came *before* KDE and Gnome. Also, it is simply a design decision. Our goal with this design is to have everything under the same module root. The reasons? 1 - Relate every projects to Umit, regardless of their name. 2 - Have people to feel confident on those libraries because they come from Umit. 3 - Subject every project to follow the same naming standards 4 - Ease integration among those projects > You know that it would makes some other barriers. > Please don't break some rules of computer science, just because. > Otherwise, please provide strong arguments first. Don't see any computer science rule I broke. 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
