On 7/9/07, Виктор Кожухаров <[EMAIL PROTECTED]> wrote: > > > > One of the options would be to assign a maintainer to each piece of > > code in our CVS. That maintainer should obviously know the code very > > well and should be able to take a decision about a feature > > improvement, an addition, a patch, a major redesign, and API break, > > etc... When things have to do with that piece of code, anyone can > > obviously pitch in, but it will be more or less his decision. If he is > > too busy, that person can have a "helper" that is also knowledgeable > > about that code and can take a decision. This should help the entire > > lag we always have with emails, patches, features, etc. finding their > > way into our CVS.
> My personal view is that dedicated maintainers might be a bit overkill > at this point. Once projects are finally released, then a dedicated > maintainer is really justified. But the current code base is constantly > changing, even if not as drastically as it used to. Furthermore, > maintainers can never be truly 'dedicated', mainly because of the spare > time issue. And we all know that spare time is hart to come by, even > sometimes impossible to obtain. > > An intermediate solution would be to discuss any changes on the dev > mailing list. And by discussing, I don't mean that the proposer should > post a message, which will be ignored, but people should actually try > and participate. Furthermore, we should really stick with discussing > important issues in the dev list, instead of on irc. Mainly, because > theres a centralized 'log' of the discussions going on here, and there > is no excuse for someone missing a conversation. I myself have made the > terrible mistake of discussing changes on irc only, thus keeping > interested people out of the loop. The point here is that leaving things open-ended doesnt always get the job done. If someone wants to work on (for example) Etk, Exhibit, Evolve, or any related app / libs, I will help them out (and in reality, only those directly involved with the aforementioned will help them out). The question here is though, what do we do when it comes to things like Ecore, Evas, and Edje? Who takes the decisions there? Raster is obviously too busy, others dont really know enough about the internals, so what do we do? (Note that some people DO know enough about the internals of those libs, so they need to be handed the responsibility, if they choose to accept it). The question that I will ask again is, "why do we have patches that are several months old on our mailing list that have not been given a yes or no yet?". > At this stage of development, API breakages should not be a concern. As > you said, there have been no 'stable' releases yet, so we can't really > piss off users of the libraries, as they should be bloody aware that the > code is unstable. Internal breaks can easily be fixed, thanks > to /insert_your_diety_here/'s great inventions, find and grep. Indeed, and the more important issue is that after we *do* release, will we THEN want to break the API? Thats going to be even more painful, not to mention will make our libraries obsolete to who ever decided to use them (just when these guys went ahead and released something, they're breaking it or creating a second version of it - is what people are gonna think). Regards, hisham. -- Hisham Mardam Bey http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
