Mail Archives: geda-user/2015/08/23/13:21:34
On Sun, Aug 23, 2015 at 1:06 PM, <gedau AT igor2 DOT repo DOT hu> 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/
- Raw text -