Alex, Perhaps you're right. My primary concern is that I think someone needs to have the authority to reject low-quality changes (for example, those without tests. This *could* be me, but I would like to hand this proposed pilot project off to someone else and (hopefully) move on to coach a different project. For the time being, I'll start looking for promising projects.
Thanks, Craig On Aug 22, 2013 12:55 AM, "Alex Lourie" <djay...@gmail.com> wrote: > Craig > It seems we're running circles. No leader is needed now aside for someone > who starts writing code. How about you choose some an app you consider to > be a good start? We then find volunteers. And start coding. > > I'm sure that the moment it starts, everyone will be interested in results. > On Aug 22, 2013 3:27 AM, "Craig" <webe...@gmail.com> wrote: > >> I'm not opposed; however, every time I've delved into Elementary >> development, I've found myself fighting too many tertiary fires before I'm >> able to get any real work done (usually it's chasing down one obscure >> environment issue or another). So basically, I would like someone who is >> competent at Elementary development to "champion" the project (to serve as >> its leader) and I and a few other TDDevelopers can coach the development >> team as well as help develop ourselves. >> >> Furthermore, this exercise will be more productive if we have other devs >> who are interested in *learning* TDD to participate. >> >> So basically, if you can find a few elementary-proficient developers to >> help with the elementary-specific problems (including a project lead), the >> other TDDevelopers and I can coach and develop along side them. >> >> Thoughts? >> >> >> On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen < >> kurt.smolde...@empuly.net> wrote: >> >>> What do you think of giving Footnote some love? I think it is currently >>> unmaintained (need to verify that), it's conceptually a rather simple >>> application but offers a good set of practices for TDD/ writing tests. >>> >>> We need to verify first of course what the intentions of the current >>> owner are, but I would personally like to see a new version of Footnote... >>> >>> Craig <webe...@gmail.com> wrote: >>>> >>>> >>>> I have never heard a project die because they decided to move to TDD. >>>>> And I heard about lots of hits on the matter. >>>> >>>> >>>> This. I've heard (and witnessed) a lot of projects drop their defect >>>> percentage from 20% to 3%. A lot of new-to-TDD developers don't like it at >>>> first because it feels slower, but I don't think those people remember how >>>> much time is spent bug hunting at the end of a release cycle. >>>> >>>> I think the next step is to find a pilot project and get the lead >>>> developer(s) to agree to work toward TDD. This will probably look like: >>>> >>>> 1) Modifying the project structure to include _test directories >>>> 2) Creating tests with GLib.Test or some such >>>> 3) Coaching/mentoring the developers at TDD >>>> 4) Performing code reviews in which insufficiently tested code is sent >>>> back for revision >>>> >>>> After testing it out for a few months, the community can see how they >>>> like it. >>>> >>>> Does this sound like a reasonable approach? If so, would any project >>>> leads like to volunteer their project? And who in the community would like >>>> to participate in such an experiment? >>>> >>>> >>>> On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie <djay...@gmail.com> wrote: >>>> >>>>> Albert >>>>> >>>>> We don't need to exaggerate. Though TDD is, indeed, a development >>>>> methodology, it is not supposed to completely change the way everyone >>>>> works. >>>>> >>>>> Just consider that writing a good test takes about 10 minutes, and >>>>> that each developer writes one or two tests for new stuff they add (or the >>>>> old one they fix) from time to time. Then, in time, you'll have part of >>>>> your code tested, which is exactly what we're aiming for. Beginning is >>>>> hard, continue something is easier. >>>>> >>>>> I have never heard a project die because they decided to move to TDD. >>>>> And I heard about lots of hits on the matter. >>>>> >>>>> >>>>> On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios <optimi...@gmail.com >>>>> > wrote: >>>>> >>>>>> Hi Craig, >>>>>> >>>>>> Thanks for your explanation and the linked video. I am still >>>>>> agnostic, but I don't want to be the only one who complained about the >>>>>> proposal. >>>>>> >>>>>> At this point I have more questions than answers, and those will >>>>>> probably be solved with a working example. >>>>>> >>>>>> But remember, *TDD is a development methodology* not a testing >>>>>> methodology. It will change our development work flow, and will probably >>>>>> move potential volunteers away from the project. >>>>>> >>>>>> TDD like every other development methodology does not fit every >>>>>> project or team. It can be a hit, and it can even the death of the >>>>>> project. >>>>>> >>>>>> Albert >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 20, 2013 at 12:50 AM, Craig <webe...@gmail.com> wrote: >>>>>> >>>>>>> Hi Albert, >>>>>>> >>>>>>> Thanks for your response, you asked a lot of great questions. In >>>>>>> addition to Gufran's earlier response. >>>>>>> >>>>>>> Can you prove that there will be huge benefits in time/resources? >>>>>>> >>>>>>> >>>>>>> Well, that depends on what you consider "proof". In the spring, my >>>>>>> company paid several thousand dollars to send me to a conference in San >>>>>>> Jose in which many software development authorities recited, "test >>>>>>> driven >>>>>>> development pays itself off in iteration 0". That means the very first >>>>>>> time >>>>>>> you write the code it has already paid for itself (because even before >>>>>>> you >>>>>>> get the automatic-regression testing benefits, you've already got the >>>>>>> benefits of a better architecture and documentation--because the tests >>>>>>> _are_ the documentation!). I'm sure I can dig up lots of other >>>>>>> resources, >>>>>>> but I think it should suffice to say that I've never heard an expert >>>>>>> comment on TDD except to say it's fastest way to develop quality >>>>>>> software. >>>>>>> For more information addressing your specific concerns, se e the >>>>>>> Wikipedia >>>>>>> article's "benefits" section (and read on to the "shortcomings" as it is >>>>>>> also relevant: >>>>>>> http://en.wikipedia.org/wiki/Test-driven_development#Benefits. Even >>>>>>> more importantly, this short video: >>>>>>> http://www.youtube.com/watch?v=DodJQyHsmHI >>>>>>> >>>>>>> >>>>>>> Can you prove that there will be less bugs? (looks like that if >>>>>>>> tests are not right, bugs will populate equally). >>>>>>> >>>>>>> It's pretty hard to write bad tests if you're practicing TDD, >>>>>>> because you write the test first, watch it fail, insert the code you >>>>>>> need >>>>>>> to make it pass, and then hopefully watch it pass. If you wrote a bad >>>>>>> test, >>>>>>> it very probably will pass before you've written the code to make it >>>>>>> pass >>>>>>> (which serves to alert the programmer that his test is bad or his >>>>>>> software >>>>>>> is doing something unexpected) or the test will fail after he has >>>>>>> correctly >>>>>>> written the next line of code (which serves to alert the programmer to >>>>>>> review both the code and his test and identify the source of the >>>>>>> problem). >>>>>>> For this reason alone, many, many bugs are eliminated. >>>>>>> >>>>>>> From what's been said, looks like there will be an extra effort on >>>>>>>> development, adding complexity and more tools to know (not to say >>>>>>>> maintain). >>>>>>> >>>>>>> Besides the initial learning curve, development actually goes >>>>>>> _faster_ with TDD (see the aforementioned Wikipedia article--I can >>>>>>> provide >>>>>>> more resources on demand) because debugging time becomes exponentially >>>>>>> more >>>>>>> expensive as time passes after the bug has been introduced. This is >>>>>>> because >>>>>>> the bug can live anywhere in any code that has been added *since the >>>>>>> last >>>>>>> time the tests were run* and because the programmer will have an >>>>>>> increasingly difficult time remembering the code he wrote at the time of >>>>>>> the bug as time progresses. With TDD, you are running the tests after >>>>>>> every >>>>>>> change (generally you test every time you build), so as soon as you've >>>>>>> broken something you find out about it. This means that the bug is >>>>>>> guaranteed to live in the last change you made, which is a smaller >>>>>>> sample >>>>>>> and fresher-in-your-mind than changes you made weeks ago. Regarding your >>>>>>> complexity concern, generally the process isn't complex (it's actually >>>>>>> very >>>>>>> simple) and it _simplifies_ development once you learn how to do it. The >>>>>>> most complex part is figuring out how to integrate testing into the >>>>>>> CMake >>>>>>> project, and that's only complicated because CMake is complicated. >>>>>>> Regarding tools, there are already testing tools available for Vala, >>>>>>> including GLib (so we don't have to maintain anything). Anyway, testing >>>>>>> tools don't take a terribly long time to learn. >>>>>>> >>>>>>> Can we focus on the half done things before adding new projects? >>>>>>>> Granite is not ready, documentation is missing, not to talk about the >>>>>>>> bugs >>>>>>>> that survived Luna release ... >>>>>>> >>>>>>> >>>>>>> TDD is more valuable the sooner you start implementing it. Even if >>>>>>> you didn't write tests for old code and only started TDD with new code >>>>>>> (and >>>>>>> existing defects), you would be doing yourself a huge favor. I'm not >>>>>>> suggesting that everyone stop what they're doing and go back and test >>>>>>> every >>>>>>> line of code (although it would be a good thing to chip away at over >>>>>>> time), >>>>>>> but practicing TDD on _new_ code can't hurt that much, can it? >>>>>>> >>>>>>> With that in mind, are there any arguments against TDD that outweigh >>>>>>> its merits? >>>>>>> >>>>>>> Thanks again for your questions! :) >>>>>>> Craig >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 19, 2013 at 12:32 PM, Albert Palacios < >>>>>>> optimi...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Craig and Gufran, >>>>>>>> >>>>>>>> I don't agree with TDD, and making a committee. Can you prove that >>>>>>>> there will be huge benefits in time/resources? Can you prove that there >>>>>>>> will be less bugs? (looks like that if tests are not right, bugs will >>>>>>>> populate equally). Can you prove that creating, modifying and fixing >>>>>>>> code >>>>>>>> is going to be easier? >>>>>>>> >>>>>>>> From what's been said, looks like there will be an extra effort on >>>>>>>> development, adding complexity and more tools to know (not to say >>>>>>>> maintain). Can we focus on the half done things before adding new >>>>>>>> projects? Granite is not ready, documentation is missing, not to talk >>>>>>>> about >>>>>>>> the bugs that survived Luna release ... >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 19, 2013 at 7:27 PM, Gufran <dogab...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Count me in. >>>>>>>>> I cant really put forward any point on how should we proceed but >>>>>>>>> I'd definitely love to be with the team. >>>>>>>>> Yes, a *testing committee* is a good idea, maybe something >>>>>>>>> independent of dev community. We can write scripts to automate tests, >>>>>>>>> and >>>>>>>>> we can do that in any language (Python for example), so it would be >>>>>>>>> like a >>>>>>>>> Python coupling between software and tests. >>>>>>>>> Just my two cents :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Aug 19, 2013 at 10:43 PM, Craig <webe...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> This is cool and important, but I don't think it should stop the >>>>>>>>>> discussion on test driven development. Perhaps this could be a >>>>>>>>>> separate >>>>>>>>>> thread? It doesn't sound as though anyone is opposed to TDD, so can >>>>>>>>>> we >>>>>>>>>> confirm that? And if no one is opposed, how can we proceed? Can we >>>>>>>>>> start >>>>>>>>>> some kind of a "testing committee" to help determine what testing >>>>>>>>>> steps are >>>>>>>>>> needed, what framework to use, and how to integrate testing into the >>>>>>>>>> existing project structure (i.e., using CMake)? >>>>>>>>>> >>>>>>>>>> Does this sound like a good plan? Thoughts? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 19, 2013 at 12:05 PM, David Gomes < >>>>>>>>>> da...@elementaryos.org> wrote: >>>>>>>>>> >>>>>>>>>>> I'll work on it, so far we only have this I made: >>>>>>>>>>> https://dl.dropboxusercontent.com/u/19899464/reviewstutorial.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Aug 19, 2013 at 6:01 PM, Albert Palacios < >>>>>>>>>>> optimi...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Munchor, >>>>>>>>>>>> >>>>>>>>>>>> A contribution / bug fixing step by step guide is needed at the >>>>>>>>>>>> developers site. There was a .pdf before the new site change, but >>>>>>>>>>>> now it is >>>>>>>>>>>> impossible to find. >>>>>>>>>>>> >>>>>>>>>>>> The problem with the old guide is that it encouraged to >>>>>>>>>>>> create your own branch instead of using the >>>>>>>>>>>> ~elementary-dev-community one >>>>>>>>>>>> (this is totally new for me). Obviously, bazaar guides doesn't >>>>>>>>>>>> teach you on >>>>>>>>>>>> using the "elementary-dev-community". >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Aug 19, 2013 at 6:57 PM, David Gomes < >>>>>>>>>>>> da...@elementaryos.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I always tell people if they make their branches owned by >>>>>>>>>>>>> ~elementary-dev-community I will volunteer to fix the code style >>>>>>>>>>>>> myself. I >>>>>>>>>>>>> have all the free time and the will to do it, just people always >>>>>>>>>>>>> make their >>>>>>>>>>>>> branches owned by themselves. >>>>>>>>>>>>> >>>>>>>>>>>>> ~David "Munchor" Gomes >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Aug 19, 2013 at 4:29 PM, Albert Palacios Jimenez < >>>>>>>>>>>>> optimi...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Before talking about testing, and advanced development >>>>>>>>>>>>>> techniques for teams with resources, there is one easy and >>>>>>>>>>>>>> simple thing we >>>>>>>>>>>>>> can do to accelerate development. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sometimes (very often), bugs are stopped due spaces not >>>>>>>>>>>>>> following the "code style" guidelines. Adding a "code style" >>>>>>>>>>>>>> validator >>>>>>>>>>>>>> script before compiling, we can prevent uploads with spaces at >>>>>>>>>>>>>> the end of >>>>>>>>>>>>>> the lines ... and save a lot of time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, just executing the next line before compiling: >>>>>>>>>>>>>> >>>>>>>>>>>>>> find . -type f -print0 | xargs -0 sed -i 's/[ \t]*$//' >>>>>>>>>>>>>> >>>>>>>>>>>>>> We will remove every "white space" at the end of any line, >>>>>>>>>>>>>> including new lines with tab spaces. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This can sound stupid, but it is absurd to block bug fixes >>>>>>>>>>>>>> during several days due white spaces at the end of lines. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>>>>>>>>>>>> Post to : elementary-dev-community@lists.launchpad.net >>>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>>>>>>>>> Post to : elementary-dev-community@lists.launchpad.net >>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>>>>>>>> Post to : elementary-dev-community@lists.launchpad.net >>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>>>>>>> Post to : elementary-dev-community@lists.launchpad.net >>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>>>> Post to : elementary-dev-community@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Alex Lourie >>>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~elementary-dev-community >>>> >>>> >>>> >>>> Post to : elementary-dev-community@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>>> >>>> >>>> >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >> >> -- >> Mailing list: https://launchpad.net/~elementary-dev-community >> Post to : elementary-dev-community@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~elementary-dev-community >> More help : https://help.launchpad.net/ListHelp >> >>
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp