On Sun, 8 Jul 2007 19:55:08 -0400 dan sinclair <[EMAIL PROTECTED]> babbled:
> > 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. Can we set up a bugzilla project (per e project) SPECIFICALLY for patches? (separate it from bug reports)? -- ------------- 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
