On Fri, Oct 28, 2011 at 7:56 AM, Mike Blumenkrantz <m...@zentific.com> wrote: > > Hi. > > Before I begin, know that I am not thinking of any one person with this email, > nor am I thinking of anyone at all. This is a general email which I am writing > based on my own thoughts after having seen the recent flood of new developers > (which is great!). > Please read it as such and do not read farther into it. > > ****************************************************************************** > > SVN commit access for developers in EFL is not a right, it is a privilege. If > you work hard, prove that you are willing to put in the time and effort to > make > your code stand out, and own up to your mistakes when you make them (and we > all do), you get commit access. We have no further policy about this, and I > think this laid back atmosphere is one of our greatest strengths. > > Because of this, however, we have no precedent for informing new developers of > the "right time" to consider obtaining commit access, nor do we tell them the > basic rules which come with commit access after we give it out. I hope to do > both of those things here. > > > * WHEN IS THE RIGHT TIME TO ASK FOR COMMIT ACCESS? * > The given answer is "when you feel like you've done enough to deserve it." > This > is ambiguous, so I'll try to clear it up. Here are points to consider: > > ** You are active on enlightenment-devel, staying current with active > discussions > ** You are subscribed to enlightenment-svn > *** You read current commit emails, review the commits, and sometimes point > out > bugs or areas which could be fixed > ** You submit patches of significant value over a period of months > *** Your patches RARELY require any editing or revision > ** You have an area in EFL where you could be called an expert > *** You know the other developers who work in this area or related areas > *** You review patches submitted to enlightenment-devel related to your area > of > expertise > ** You are regularly in #edevelop ***** (this really is a requirement > nowadays) > > If most or all of the above statements apply to you, then you should probably > be getting commit access. If not, consider whether you actually need it; > remember that if you are a committer, YOU ARE RESPONSIBLE FOR ALL CODE WHICH > COMES INTO YOUR INBOX. This means patches, commits, everything. If someone > commits broken code to something that you own or manage, it's YOUR fault if > someone else gets a broken system. If there are patches waiting to be reviewed > for something you work on and you don't review them, THEY WILL NOT GET > COMMITTED. > > This brings me to a very relevant point: over the past month(s) I have seen a > lot of complaints that patch reviewing on enlightenment-devel is slow. The > reason why it's slow is because people who have asked for commit access are > either busy or lazy! Usually it's the former, in which case there is nothing > to > do but wait. When developers are being lazy, the best thing to do is ask in > #edevelop if someone can review your patch. In fact, this is ALWAYS the first > thing that you should do before submitting a patch. If you get it > pre-reviewed, > you have just reduced the time it will sit on enlightenment-devel gathering > dust before raster gets to it. > > ******************************************************************************** > > * WHAT DOES HAVING COMMIT ACCESS MEAN? * > When you are given commit access, this means you are considered responsible > enough to make your own decisions. You should always attempt to observe the > following rules, though at times you will need to break them: > > ** Do not bug raster about every commit you want to make. Seriously. I realize > the first few commits can be scary and require hand-holding, but you can > always come to papa discomfitor who has lots of free time to kill. > ** Managing vs Contributing. If you are the SOLE primary committer for a > component, and people come to you when there are issues with it, then you > are managing that component. Otherwise, you are contributing. Take this into > account for your info.txt file to avoid confusion. > ** If you are contributing to a component that has a manager, YOU NEED TO TALK > TO THEM BEFORE MAKING ANY LARGE CHANGES! As an example, everyone knows that > Tom Hacohen MANAGES textblock, so I would go to him if I wanted to make > everything someone typed come out backwards. He would tell me that this is > stupid, veto my patch, and SVN would be saved. > ** It is your duty to review ALL code which touches your area(s) of expertise. > Your area(s) of expertise should be whatever you have listed in > Managing/Contributing in your info.txt. If you are not comfortable reviewing > code in an area, you should not be listing it here. > ** Commit counts are NOT an indicator of quality, nor an avenue for mature > individuals to be competing on. If you make 50 commits in a day and do > nothing but fix formatting and whitespaces, you have effectively worsened > SVN by creating a large block of useless commits which everyone will then > have to review to make sure you didn't accidentally break something. > > ******************************************************************************** > > I'll reiterate that none of the above statements are targeted at anyone. We > don't have any of these on the wiki, nor have they ever been explicitly told > to > anyone (that I know of); they are meant to be inferred by watching the > more senior trolls^Wdevelopers. > > Having said all of this, I think it's great that we're finally starting to get > more people active in SVN, and I hope that everyone will continue to act > responsibly while having fun :)
excellent mail, please make it a wiki page :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
