On 7/8/07, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > 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...?
Maybe use patchwork? http://ozlabs.org/~jk/projects/patchwork/ It's a crawler of patches in some mail list, then you can browse it and get those easily. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
