On contributing to lettuce

87 views
Skip to first unread message

Gabriel Falcão

unread,
Oct 28, 2013, 1:53:36 PM10/28/13
to Lettuce Developers
Hello everyone,

my name is Gabriel, the author of lettuce.

First of all I wanted to apologize for not being present in the mailing lists, but I also get happy to see that people help each other and get by any problems.

Secondly I want to justify so many open pull requests, the reason is actually in the CONTRIBUTING.md of the lettuce codebase, but let me clarify here.

Lettuce has over 700 stars and 160 forks in github, besides that making a simple search in github code for "from lettuce import" results in over 2000 repositories, also as of this exact moment in PyPi lettuce has over 7800 downloads from last month.

Those numbers just add more responsibility to the principles of lettuce:

* Lettuce is a software for writing and running automated tests, and people rely on it to make sure that their software is working. 
* Therefore lettuce has to excel in quality and robustness, I wrote lettuce through test-driven development back in 2009, it currently has 179 unit tests, 107 functional tests and 30 integration tests. Those numbers are still too little, but they are what lettuce have to make sure that peoples builds are not going to break due to lack of responsibility.

But very often I get pull requests and emails from people wanting me to merge their contributions into lettuce, which is amazing and makes me really happy, if it weren't for one important thing:

A lot of pull requests don't have tests or documentation. 

So let me emphasize again: Lettuce is a test software and I will not accept contributions without tests, otherwise the contributed code can possibly lead to a false-positive or false-negative bug and jeopardize the builds of thousands of people who trust lettuce to write their tests with.

Open pull requests

Now lately I've been receiving from lettuce enthusiasts asking about pull requests that weren't applied, I'll show them here with the reason they weren't applied:

-----
Threading support for Django httpd: https://github.com/gabrielfalcao/lettuce/pull/392
Not applied for lack of tests
-----

-----
This person sent a pull request that barely explains what it is, has no tests and no documentation. Won't be applied unless this scenario changes.
-----
implementation of smtp mail server queue for "--no-server" option with specs - https://github.com/gabrielfalcao/lettuce/pull/363 and https://github.com/gabrielfalcao/lettuce/pull/388
No tests for this functionality, no merge.
-----
ReasonToFail object has no cause attribute when exception had no message... - https://github.com/gabrielfalcao/lettuce/pull/385

This one is supposedly a bug fix, but with no tests to prove that the bug was solved, no merge.

----
This pull request supposedly fixes 2 bugs and has exactly 2 tests, I haven't had time to look at it, but since the pull request itself breaks the build and uses an english that is really hard to understand, I reserved myself the right to look at it later, when I have time and patience.

---

Canned step to create M2M model links - https://github.com/gabrielfalcao/lettuce/pull/375
No documentation, I barely understood what it does because I didn't look in depth at the code and it has no docs, how is that I can allow a feature in lettuce that people won't know that is there? 

I have been "loose" about tests in the past: I allowed people to contribute with xunit output, but the person who contributed didn't provide tests for it, and so it was broken.
Then people started to send a lot of small pull requests like this one that provide a "quick fix", might work in their computer, but has no TESTS! It's unacceptable, and I am so sorry for having accepted tis pull request in first place. This is why I put a big red warning on the bottom of the lettuce website about this functionality being unstable.


----

Proposes a new feature but has no documentation


---
XUnit Totals For Steps Don't Match Console Output - https://github.com/gabrielfalcao/lettuce/pull/355
Remembe when I mentioned above that xunit ouput lacks tests and people haven't taken it "seriously" ?
This is another lingering pull request that supposedly fixes a bug, but has no tests to prove that the bug exists and was finally solved. Won't be merged until that happens.
----

This pull request doesn't even have a description, has no tests and no explanation. I won't look at it until I have time to do see if it's really a bug or what, and solve it in the right way: adding test coverage.

----
Broken


Please don't take me wrong

I have empathy for all the people who sent pull requests, regardless whether it was or not writen with acceptable code quality, I recognize that the person took their own time to send a contribution, I just can't merge code that is not stable or is not documented.


Thank you for understanding
 -- Gabriel Falcão
Reply all
Reply to author
Forward
0 new messages