On Wed, Mar 28, 2018 at 3:59 AM, Stefano Zacchiroli <z...@upsilon.cc> wrote:
> First of all, thanks a lot for tagging/releasing Beancount 2.0, I'm > really excited about this (even if it's the same code base than a few > days ago, I know, but I can't help it!) > Like I said, there's really nothing much special about today, it's like a birth date on the years after birth. The main impact of tagging 2.0.0 is that knowing that a large number of people will stick with the release I can probably start taking more risks again. On Tue, Mar 27, 2018 at 10:52:48PM -0400, Martin Blais wrote: > > "Attracting more developers" is not an explicit goal of the project, > though > > "attracting more developers who write very long and thoroughly > thought-out > > suites of unit tests for very small and contained changes worked and > > reworked again from all the findings found from aforementioned > laboriously > > written unit tests covering most of the cases" is quite useful. Do you > > believe moving to github would result in more unit testing? > > I totally agree that one platform or another does nothing to *actively* > encourage developing more unit tests. > > And I'm certainly not a fan of GitHub --- proprietary platform, forces > non-free JavaScript onto users, etc., etc., you know, my "usual FOSS > things" :) But FWIW the way I think about this is not in terms of > actively encouraging contributions, but rather not *discouraging* it. > Say a user has developed a bunch of test suites and want to contribute > them. And say that user is like Martin M., fluent with Git/GitHub, but > almost never used hg/bitbucket. He might give up sending you the tests > at the first attempt of rebasing/rewriting a PR that fails, unless he > has additional spare time and motivation. And at that point you would > have lost a contribution that you consider valuable. > > That said, I don't particularly care, Bitbucket is as bad as a platform > as GitHub in terms of software freedom, and I'm happily using > git-remote-hg locally anyway, so the two alternatives are really the > same to me. > This comes as no surprise, but your radical Leftist POV is always welcome on this list no matter what. It's our political diversity initiative :-) The thing is, if reading the one or two short pages on doing a mercurial checkout is too much, I want to say it's almost a Good Thing that there's a little bit of a hurdle. It ensures you're not going to waste your time making a submission that will never get merged. How can the contribution be expected to be valuable if that's all the effort someone is willing to put in? You speak as if a little bit of untested code is worth anything. It's not. Let me explain. Here's how I go about adding new code to Beancount: 1- I have an idea, or I need something that's not there 2- I code something up, it works (in the one case I'm using it for) 3- So I write a couple of unit tests for the new idea 4- Very quickly (and invariably) I realize some flaws in my approach, it breaks some other thing or assumption, other test far away from it start to fail, and/or it's not general enough, or while testing some corner case I realize something I hadn't thought about which invalidates the whole idea 5- So I go back re-design, fixup a lot of other stuff, and write more unit tests - I iterate like that 4-5 more times, until it looks good (or I abandon the idea because it's not general enough after I realize I was wrong). What I thought would take 10 minutes ends up taking 4 or 5 hours of development time. (BTW that's one of the reasons I love plugins, usually they're isolated and are less likely to lead down that road.) Most people's contributions stops at (2). That's a problem. So then if I want that contribution - and to keep things stable, you DO want to be able to do your accounting without facing bugs, don't you? - I have to go write the unit tests myself, and INEVITABLY it either breaks some other stuff or it needs improvement or even rewriting and 3, 4, 5, and iterate. (2) takes almost none of the time, it's not really "valuable." It's really super ridiculously easy to hack something that works in your one use case without testing it than going the extra 10 miles further to fix everything upstream to finish the job right. All the time is spent in 3-4-5-iterate. THAT's where the value is. The artifact (the code) is not valuable; the testing and running of it is. The more we run that codebase successfully and shape it to solve our problem, the more value it acquires. (That's one reason a really loose and wildly unchecked language like Python often wins over more pedantic approaches - we move fast, and the code more quickly morphs around the problem's "shape", that optimization often more than makes up for correctness.) Learning to checkout, commit and push a Mercurial PR? Honestly that should take VASTLY less time than coding up the idea and doing the work necessary to merge it in. If that hurdle is enough to deter someone... maybe it just keeps a lot of quickly coded, untested "drive-by contributions" away, all the better. If you make a contribution and there's no test... well you're forcing me to either (a) go write the tests myself for your contribution (in other words, I end up doing most of the work), or (b) ignore it and work on the stuff that I care about. (And it's not like I'm in need of ideas... visit the TODO file, there's 5000 lines of ideas there. I'm pretty sure I'll never be able to do it all. My problem is time. I like to learn what users' pain points are to address those when I don't rub against the (e.g. UTF8) but new ideas are a dime a dozen...) Now... I'll say it again: the quickest, fastest way to any contribution getting merged is to write thorough set of corresponding unit tests, and then iterate, and then address merge comments and iterate on them until it's good enough. It's a lot of work... but it's the work that I put in myself. (There's a reason it's reasonably stable and that you're here.) I know I sound a bit harsh, but really, I'm very generous with my time and I promise I will be helpful in the process of working through PRs. And I have the advantage of having written most of this, so I'm really familiar with it, I can provide some helpful guidance. If you really want something in... and you're willing to put in the work to write tests for "most" (say, 80%) of the corner cases and to automate checks so it won't break in the future, and are willing to maintain the feature when new issues do arise (they will... otherwise I have to do it?), and iterate with me until it's well tested, and are open to the fact that maybe, just maybe, in the process we will both realize it might be better to drop the feature after all because it breaks too many things (this happens, occasionally, sorry Michael about the @@)... then I think it's possible to make good contributions. Will it take more of your time than you think when you set out? Yep, almost certainly. And here cue that Willy Wonka meme... https://memegenerator.net/img/instances/81584686/oh-you-cant-learn-4-or-5-mercurial-commands-thats-sad.jpg -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhO_-rbiMt4QRtUQkf%3DKDsq6d%2BQ5Ugiya4Bmz7Rf_1dsCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
