X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <56839894.50909@xs4all.nl> Date: Wed, 30 Dec 2015 09:40:52 +0100 From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: gEDA and it's future with Scheme & Guile was Re: [geda-user] Project leadership References: <20151229212943 DOT 2d486c8c AT wind DOT levalinux DOT org> <322D36D8-DAB6-4117-B22B-8FF515B00D2B AT noqsi DOT com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com gedau AT igor2 DOT repo DOT hu wrote: > > > On Tue, 29 Dec 2015, John Doty wrote: > >> >> On Dec 29, 2015, at 5:24 PM, Svenn Are Bjerkem >> (svenn DOT bjerkem AT googlemail DOT com) [via geda-user AT delorie DOT com] >> wrote: >> >>> On 30 December 2015 at 00:58, John Doty wrote: >>>> Okay, I get excoriated when I ask that developers leave working >>>> code alone. Now I?m excoriated for suggesting the sort of positive >>>> contribution somebody who wants to write code could make. >>> >>> Your positivism is only brought to town when it fits your agenda. >> >> Am I not entitled, as a user, to want progress without having to give >> up what already works well? > > Your current agenda: > > 1. DO NOT CHANGE ANYTHING IN GEDA. > 2. DO NOT CHANGE ANYTHING IN GEDA. > 3. DO NOT CHANGE ANYTHING IN GEDA. > 4. DO NOT CHANGE ANYTHING IN GEDA. > 5. proress can only made by writing other programs > > Solution: fork (or just save a copy of) geda today. Stop caring how > others change their copy. Will save everyone a lot of time. > > Hi John and all, The *real* challenge is that even if you did do a fork, the rest of the world around *your* geda-gaf fork will change. Changes like gtk2 --> gtk3, guile finally getting nuked, the last scheme programmer dies, OS updates all libraries, the i*86 infrastructure dies, etc. etc. You could always fork these too and try to freeze them on the time line. So it will probably become a struggle to follow pace. The change from gtk2 --> gtk3 (or gtk4, or any other gui) will lead to radical changes in gschem (hope we will not break stuff like pcb did with the "nm" change). What we developers need to implement (in Launchpad ?) is a robust system for "Management of Change" (MoC) to take away any fears of breaking stuff and workflows. This means a better control of *our* developer workflow (that is, from the programmers perspective) ... please do not rant over this one as a change in *your* user workflows ;-) This means things like organizing "second pairs of eyes", and not just any pair of eyes: they need to have the ability to review and scrutenize code without hesitation (tap programmers on fingers). I'm sure *you* could do that. The changes in pcb code base for yet another GUI will be minimal --> *radical flexibility*. The changes in pcb code base for yet another plug-in or feature will be minimal --> *radical flexibility*. Count your blessings. Kind regards and the best for 2016, Bert Timmerman.