From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9F4AE1384B4 for ; Tue, 22 Dec 2015 12:53:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B0E221C04A; Tue, 22 Dec 2015 12:53:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7DD5EE0888 for ; Tue, 22 Dec 2015 12:53:47 +0000 (UTC) Received: from [192.168.2.174] (ip-176-52-204-228.static.reverse.dsi.net [176.52.204.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id E415633E5E4 for ; Tue, 22 Dec 2015 12:53:45 +0000 (UTC) Subject: Re: [gentoo-dev] Re: repo/gentoo.git, or how committing is challenging To: gentoo-dev@lists.gentoo.org References: <566DACB3.2010105@gentoo.org> <20151213222001.0c1c466a3f3b8b0b53c69a9d@gentoo.org> <20151213190045.1e186781.dolsen@gentoo.org> <20151220212127.6e5cd419@caribou.gateway.pace.com> <56791ACB.3000903@gentoo.org> From: Patrick Lauer X-Enigmail-Draft-Status: N1110 Message-ID: <567947B7.7090205@gentoo.org> Date: Tue, 22 Dec 2015 13:53:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: af37b97f-d93a-4d23-a3ab-df67520f85a6 X-Archives-Hash: bade07c8204d8b608ec2a7698e1eda4d On 12/22/2015 01:08 PM, Rich Freeman wrote: >> Or just point people at a random email, because that's about as good as >> documentation. > Thank you for writing up a guide/outline. > > You appear to hate mediawiki, but you do realize that you could > probably copy/paste that email into the box and call it half-done, > right? Somebody else can always come along and improve it, and that > is kind of the whole point of a wiki, and of FOSS in general. I've worked with Semantic Mediawiki long enough to understand that it is a pile of buggy hacks, on top of a horribly bad codebase, on top of a horribly broken language. Upstream developers don't understand concepts like data truncation, and debugging this pile of code is going to make you cry. (Just as an example: I found a 'pathological' pageview that cost ~40000 SQL connections (yes!) and 90 CPU-seconds render time, server side, on a 4Ghz machine. Moving the database from dedicated hardware to the MW server sped up page render time because the network latency of ethernet becomes painful ...) >From the beginning I've suggested to use something sane, but people Know what needs to be done, so there's no way to avoid such badness to spread. And thus I just refuse to interact with it now, because I know enough details about SMW templates to not want to stare at that buggy ad-hoc mess of random again. > >> Please, stop wasting people's time, if you write code or documentation >> write it once properly, don't release untested things and claim they are >> an official tool, and don't ignore complaints (because they mean, as a >> first approximation, that you screwed up and need to fix stuff) >> > Gentoo devs and volunteers are more than welcome to ignore complaints. > I'll take half-implemented code over no code any day of the week. Broken code is worse than no code: Now you spend lots of time on debugging, instead of doing something more useful. I'd replace gkeys-gen with a ~10-line shell script ... if I had some motivation to dig through some old experiments of mine where I managed to set all parameters for pgp from CLI. Which is all that gkeys-gen would do! > Maybe somebody isn't good at writing documentation, and we benefit > from getting their contributions all the same which somebody can later > follow-up on (perhaps somebody who is better at writing documentation > than code). You're going to make more progress with evolutionary > steps. > > BTW, bugs aren't complaints, and I don't really consider "complaints" > nearly as useful. If you want to point out an error by all means do > so. You can do it without implying that somebody somehow owed you > something better. They don't. > I guess we fundamentally disagree - if you do shoddy work, it is shoddy. I won't praise you for it. Look, *I* spent about a working day all in all on just figuring out why things don't work. Multiply by number of contributors, and it starts looking really sad. Time and motivation are not free resources! That's my time, spent to work around deficiencies I shouldn't even see - if other people had done their job. And that's just frustrating if it happens again and again, and instead of doing something interesting I spend most of my time just being janitor and cleaning up stuff.