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 :)
--
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.
------------------------------------------------------------------------------
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
