Mail Archives: geda-user/2015/08/23/09:04:35
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?
>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.
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".
>> 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.
> 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.
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
- Raw text -