On Wed, 2011-02-09 at 13:08 +0100, Cedric BAIL wrote: > I am for enforcing commit by a svn hook for all top level library. > This mean that if you wan to commit something in eina, eet, evas, ..., > you should at least start by editing your info.txt and set that now > you are a contributor to one of this library. If you don't do that > before your commit will be rejected. > > There is currently too line in info.txt for that, Managing and > Contributing. Managing is when you feel you can review some big patch > and commit them inside. People should understand that when they say > they do manage one library, they will have more responsibility and > more burden (people will come to them to ask question about the > internals or ask review for some patch). When you are managing a > library, you should have some idea of it's current status regarding > its current state of stability. Contributing would be when you do some > small change, small improvement, fix bugs and fix broken build, but > you don't feel like taking more responsability on it. > > Updating correctly this two information and forcing people to keep > them correct would help new comer to identify whom they should ask and > would help us spread the burden of the release cycle too. It will be > easier during the release cycle to identify people that take a library > in charge to know what is the status of it. > > Anyone that have access to the svn could still commit some code, but > he will understand more what it does mean and take more responsability > for his work.
I see two problem with this suggestions. The first big problem is that people don't always know their way around all of the lib. For example, I maintain the font engine but I know squat about some other parts of Evas, so it's not that easy, and parsing will get a bit annoying. Maybe if we do "evas (textblock, font engine and etc)" i.e "<name of lib> (free text description)" that could work. Anyhow, I'm up for this idea as well, I don't mind adding this kind of a permission system :) And the other (bigger) problem is reverting changes. Although I'm not the maintainer of eet, I want to be able to revert bad commits in it. You don't have to be familiar with a piece of code to be able to detect a bad commit. Maybe we can allow everyone to revert by adding a tag to the log message? > I am all for it. If we agree on this, we should add this guideline to > our wiki so people have an easy place to find this information and > don't feel bad because it's not clear from the outside. Just waiting for a general approval and then I'll put everything in the wiki in a nice and orderly manner. > Thanks for your long mail by the way ! Was my pleasure. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
