On 8-Jul-07, at 7:43 PM, Carsten Haitzler (The Rasterman) 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...?
Can you say bugzilla? It makes it really easy to deal with patches and let the submitter update them and add comments all in one place. You could also probably get it setup to email a list with bug changes if you wanted. dan ------------------------------------------------------------------------- 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
