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=TRhsQ7Jg3oeAPHJRa/lyY9oSSTJxDu3wWvZ70tHHiKE=; b=JhOQC1YKhT0Zz7D/7MxdTHjKjOeUt88dRozdb37N466aUqvZMaibnbh1v+u9dWlHQP L/6d10wUMJojxYKNGjwCel/guqscquZtAhy1gJ1DZaEBIlXfwzFiT3jnfffvYrXNf77A kDJOHEtxaMR1j3evEUhvT00WRJTXaKKhWr95N6T2nQCxtBgr+S/d8gXyDfNjaV47cvVt q3ndeNPSOIHvU93uPjkjyfzuaOVQtoEE0c6fX+uD4RL8dKDM6rIbx1cffhkpjZ/G43fn HsqR6qUN0dTE7vgkrCMbU3Mg2a2oy5wegOb86mPerASNK3oWyD4jG8YFVYtVfnFDdMQN R3Rw== MIME-Version: 1.0 X-Received: by 10.152.6.41 with SMTP id x9mr7073181lax.120.1440350474238; Sun, 23 Aug 2015 10:21:14 -0700 (PDT) In-Reply-To: References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> <55D9BDC7 DOT 4000608 AT jump-ing DOT de> Date: Sun, 23 Aug 2015 17:21:14 +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 1:06 PM, wrote: > > > On Sun, 23 Aug 2015, Markus Hitter (mah AT jump-ing DOT de) [via > geda-user AT delorie DOT com] wrote: > >> Am 23.08.2015 um 06:46 schrieb gedau AT igor2 DOT repo DOT hu: >>> >>> >>> On Sun, 23 Aug 2015, Evan Foss (evanfoss AT gmail DOT com) [via >>> geda-user AT delorie DOT com] wrote: >>> >>>> 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. >> >> >> pcb-rnd means to replace pcb, you can use only one of both. > > > What exactly does make you think that? Igor2 the only alternative (which I am no opposed to) is that we drop the current mainline and use pcb-rnd going forward. >> gschem doesn't, it's a tool for a different task. >> >>> 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 >> >> >> With this attitude it's clearly subject to bit rotting. If OpenGL doesn't >> work well it needs fixing, not abandoning. That is what worries me. > So please fix it. Before I started on pcb-rnd, I was struggling with the > gl-enabled versions from time to time. The final fix was always to revert > back to a non-gl version. I can't recall anyone was attempting to fix any of > these. I think the official standpoint is something like "buy bigger > hardware and live with it". I remember those days. People were kind of obnoxious about it. >>> 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". >> >> >> Right. That's exactly the problem which needs tackling. Seeing forking as >> a solution is a bit shortsighted, though. >> >> This attitude totally misses an important point: you get only the fixes >> you do yourself. If somebody else fixes something in another fork, you have >> to duplicate this work. Forking is essentially giving up on collaboration. > > > I agree. I waited long before the fork and did it as a last resort. > > When you have a project that's going in 90% the wrong direction (as in > directions you, as an user don't like) while there's exactly 0 effort put in > things you actually want, you either abandon the whole thing or fork. > > I don't yet see how switching to kicad or something else would have been > better. KiCad has it's own problems. > >> gEDA had never achieved the current level of sophistication if such >> attitudes whould have been widespread 20 years ago. > > > I agree. 10 years ago there was a team who more worked towards common goals. > Back than these goals also happened to be much more aligned with my (user > and developer) needs. It didn't 100% meet my needs, but was close enough > that I didn't consider switching to something else or forking. The goals are all still aligned as far as I can tell. There are debates about how they should be implemented. > I think the major problems on this is total lack of a working team with > coherent and well defined goals and the DVCS. > >> I know a vcs flamewar will follow, and I won't join it. > > >>> 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. >> >> >> Perhaps you confuse pcb with pcb-rnd users here. > > > Sadly, I don't think so. Just read back the mailing list. Point out features > or bugfixes in pcb or geda that brought up more than 2..4 users who > _actively_ did something about it to help the developers. It simply doesn't > happen too often. > >> New features in pcb-rnd are not new features in gEDA/pcb. Essentially you >> ask people to abandon gEDA/pcb in favour of pcb-rnd. > > > Again, why do you think that? Looks like you are mistaken... > >> Antifork knows about no less than 20 forks now (thanks for the additions, >> Bert). > > > So pcb has more forks than active developers, cool! > >> Think what whould happen if each of these forkers had a similar attitude >> as you: these 20 users whould split up on 20 forks, making ... right, only >> one user per fork: the forker him selfs. > > > Well, to be honest, I think most of those forks are like that... > > And I still consider it a fail that you need scripts just to keep track of > the forks that happen in the official VCS. > >> >> >>> 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. >> >> >> You see? If you had committed to the official repo, this task would have >> been done by others. > > > Not really. First of all, it would be just yet-another-bitrotting branch or > fork in the git mess. Second, I worked on features the official developers > never found important enough or would be right against. I don't see how they > would invest time in working on them in git and not in svn. > >> Almost all recent commits are about documentation. Collaboration means > > 50% more work for 200% more gain :-) > > In this case, it would be rather: > > - about 300% more work, because of git, lack of the auto release, auto > packaging, auto publishin features of repo.hu > > - about the same amount of work on the actual features, since as I wrote in > the previous paragraph, noone else would really join me working on my major > features > > > Sorry Markus, but we disagree in most points. I don't think I will be able > to convince you about mines the same way as I don't think you'd be convince > me about yours. We just have to live with it. > > Regards, > > Igor2 -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/