On Mon, 9 Jul 2007 02:35:15 +0300 "Hisham Mardam Bey" <[EMAIL PROTECTED]> babbled:
> 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?". i swear i recently cleaned out the patches - like a few weeks back? Actually.. .I think we need a patches mailing list...? > > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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