Mail Archives: geda-user/2015/08/23/08:34:32
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. 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.
> 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. gEDA had never achieved the current level of sophistication if such attitudes whould have been widespread 20 years ago.
> 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.
gEDA/pcb's official repo _is_ a centralised CVS. It allows everything you can do with a Subversion counterpart. Git master is just as immutable as SVN trunk. Not enforced by lack of software features, but enforced by policies and hunks. The result is the same.
One key feature of Git is its distributed nature. Which also means: if one committer messes up, another one can restore easily from his clone, because a clone is also a backup. With this in mind one can be much more relaxed about granting write access.
Another one is management of branches. This means, whoever wants to fix something "just for me" can do so in the official repo, in a branch. Branches can be compared easily, forks not so. Branches can be rebased to follow development on master, doing so with forks is much more work and rarely done.
All this applies to SVN as well as to Git repos, so no SCM war.
> 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. 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. No surprise there are only few going this route and even fewer doing so permanently.
Antifork knows about no less than 20 forks now (thanks for the additions, Bert). 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.
> 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. Almost all recent commits are about documentation. Collaboration means 50% more work for 200% more gain :-)
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
- Raw text -