X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 23 Aug 2015 06:46:42 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] Antifork In-Reply-To: Message-ID: References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 23 Aug 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > You are right in your motivations. We do need to pull in stuff from > the various branches. I have been doing testing of Igor2's pcb-rnd. And I am very grateful for your (and Britton's) feedback. The software got better after fixing bugs and implementing features you guys found or requested. > The more functionality that goes into that branch, the more I worry > about project fragmentation. As cool as his branch is I really miss > autotools build and opengl shading. I think it is not a branch, but a fork. I think it's less of a project fragmentation. I regard pcb-rnd as a separate project, not as a branc of pcb. It's like gschem vs. pcb is not fragmentation for me either. Autotools: the system I have in pcb-rnd is superior to autotools. Since pcb-rnd is young, there may be cases when something doesn't work out of the box, but I usually fix them within a day after it's been reported. From the user perspective, it's the same ./configure. Of course if you want fancy things like install random parts in user home directories, that gets a bit more tricky. But honestly, did you try to install a different version of glib in your home using autotools and then compile pcb using that version? And did it work for the first attempt, without questions raised? Opengl: I didn't delete that code, it's just disabled by default. As I have 0 interest in using or de velopen opengl stuff, it stays disabled until a volunteer comes and fixes it (when it becomes an optional feature). Looking at the current levle of _actual_ PCB user activity (see later), this is unlikely to happen. > > It is nice to have a tool to do what you are describing but I fear > merging code with out talking to it's authors. They most likely have > reasons for not merging it other than "I was too lazy to submit a > patch." It might just be "i wanted testing done." or "the mainline > developer(s) drove me away back then." The problem is I suspect a lot > of it is "This worked good enough for me to do X but not reliably > enough for me to feel like it was ready for inclusion." A very important factor along the ones listed, at least in my case, is: "I either sit down and to it in my fork and I have a working stuff or I get lost in a trying to keep things nice and compatible recursion and will never have the actual feature". > We need a way to go down the branches one by one and > 1. Ask their owner about them. > 2. If the owner is missing in action do a review ourselves. 3. switch to a centralized VCS and start using it properly, in a real team work, so you won't need scripts and manpower to get a "merged" version. Or even a complete mainline the user can refer to... This is my personal opinion. I know a vcs flamewar will follow, and I won't join it. About PCB user activity... I started to work on pcb-rnd again on 12th July. I have a good working time logging system I use for my hobby project so I know that I've spend 135 hours on it since. I don't regret any minute of it, since the new features of pcb-rnd are really useful for me. However, the past month also showed me a strange phenomenon. It seems there are only a few actual active PCB users out there. I don't have numbers, but I estimate there would be about 20 or 30 users wordlwide, who read the mailing list and really try to follow what's going on. The strange phenomenon is that many people are willing to express their strong opinion on what features are needed in pcb-rnd (or in pcb, on this regard we may consider pcb-rnd as a test lab from pcb's perspective), but when it comes to actually compiling and running a new version, only a very few invest the time. Although scripting won the poll of most wanted features for pcb-rnd, I found only 2 who actually tried to compile and run the stuff. To me, this means even if there are only a few active PCB developers out there, proprionally there are even fewer active users/testers. There are occasional sprints in development, and there are usuallt 2 or 3 users reporting results. There's probably nothing wrong with that, but if that's the case, I find it natural that developers find it more motivating to develope for themselves than for the "crowd" - at least, that's the effect on me. In practice, this means: I am finishing the doc upgrade for scripting of pcb-rnd today, but I feel like this part of the investment was a waste: I didn't need better docs than the ones I had before. It is clear the bottleneck for pcb-rnd users was not the documentation either. After that I will go on developoing the poll winning features (since I need them too), but I probably will invest less effort in detailed documentation or tools/features/options I don't actually use. I will conduct another experiment, tho: I will try to compile an as-static-as-possible executable for x86_64 Linux. It's not a priority so if it doesn't lead anywhere after a day I will probably give up. But if it works, there'll be a way for new users to try the stuff without having to check out and compile anything (and honestly this seems to be one of the big bottlenecks nowdays - even on Linux). Regards, Igor2