X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rXxfw5eN+VOeVAdrGVDzfTVo5wYxc7Hg7hO6EJ2rPI8=; b=W2m54fjhukgAIXxU307MAdJi/t0Lj3a0y/X9ODZRg45BPofuzm6zK6IFJbMW06Hmpf AryiD+MyUe+g2iCBlJyrUDzIuPD8ck6rdSj/lFFD/ZkHbP0KwEnf7fAySK97FKwfOj+h dnBDa8Nbq+0CCeXr3OYeTPFrKTVX+ibE/mfMWF1A/izngg+KUXAJngSJfaJr4SC4mM5J 8hfT0flSKDBX80+Z816AM6yjBk0r1udOJi1OKu0JCgg3nJNc8vATnEVAoUGwmyL7Ql8G JjRxuNm25wnIGnDGPYGv008H3lyFm/Wd5be7+ONmw4slWt8Q0PNcab+eRB5qhDDk81KG rsgw== MIME-Version: 1.0 X-Received: by 10.152.6.41 with SMTP id x9mr7010347lax.120.1440348954972; Sun, 23 Aug 2015 09:55:54 -0700 (PDT) In-Reply-To: References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> Date: Sun, 23 Aug 2015 16:55:54 +0000 Message-ID: Subject: Re: [geda-user] Antifork From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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, Aug 23, 2015 at 4:46 AM, wrote: > > > 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. I am not trying to push you to change the way you run *your* fork. >> 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? I have built glib on some non-x86 architectures and non-linux's. > 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. I was not asking you to support it. I was just saying we need something that pulls in your work with the original PCB so that effort is not diluted over forks. >> >> 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". Well. Yes the mainline of PCB needs a cleanup so that this is less of an issue. >> 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. Too radioactive for me. > 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. You are confusing geda users with members of this list. A lot of users probably get gEDA via their linux distro. Why would they be on this list? > 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. We were more active a while back. As the software develops again and activity is noticed things will grow again. > 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. That is very true and why we need to "Antifork" things a bit. > 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 know I have been an absent lately and for that I apologize. I agreed to be more involved in testing and I got side lined. > 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). I use Gentoo specifically because I prefer to compile everything. > Regards, > > Igor2 Evan -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/