Mail Archives: geda-user/2015/08/25/23:21:30
On Tue, 25 Aug 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Sun, Aug 23, 2015 at 6:29 PM, <gedau AT igor2 DOT repo DOT hu> wrote:
>>
>>
>> On Sun, 23 Aug 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>
>>>
>>> Unfortunately no one is going to be nearly so well positioned to merge
>>> your
>>> stuff as you are. Relatively, it will be painfully inefficient for
>>> them and they
>>> will feel it as they work.
>>
>>
>> Unfortunately no one is as unmotivated to invest time in this as I am. This
>> won't happen, sorry.
>
> I take it you acknowledge that no one can do it as easily as you. But
Sorry, I don't. There are parts that would be easier for me and parts that
would be harder for me. In the net sum I don't think I'm in better
position than the average mainline PCB developer.
> I guess you
> also feel that since others don't want to bother much, there's no
> reason you should
> bother or use build/vcs you dislike.
What I feel mainly are:
- the direction of development/planning of mainline PCB are diverging
fast away from what I (as an user want), so there's less and less chance
I'd use it - coding someting the programmer himself don't use is a bad
choice imo
- the tools used (git, autotools) in the process would take my time away
from actual coding and focus them on administration or otherwise less
useful activities
- related to git: I am about 95% sure that whatever merging I'd do would
end up in a bitrotting branch
- honestly, working together with a medicore troll like Markus while John
is asking me not to change anything in gschem after each commit message
that happens to match the regex "schem" is not really appealing
There are some other minor reasons. All the same since I originally
started my fork. Really, I just want a version that does exactly what I
want, without having to spend a lot of time on things I don't need or
even would want to be remove. The best way to have this is a fork.
> Suppose someone else did do the work to merge it this time, would you feel then
> feel more or less inclined to use common build system etc. and generally
> design-for-mergability in the future?
I look at it as a deal: costs and benefits.
Costs: I'd need to give up things that work much better in my fork than
in mainline:
- the 0-administration repo.hu framework
- the simple, centralized VCS
- a build system that is easy to hack
- I'd have worry about how to disable or revert changes or new features I
dislike (see below); this leads to a situation where instead of a clean
fork that just does exactly what I want, I have to maintian a fork,
constantly merge forth and back, just to keep on having a version that
does what I want.
Benefits:
- my stuff ends up in mainline
- I automatically get useful new features and bugfixes (see below)
It's clear that the weighting of different aspects are different per
developer. With mine, costs clearly overweight the benefits.
*** To avoid new flamewars, I have to declare... About the features listed
below: no offense meant; when I say a feature is useless for me, I don't
mean the developer working on it is wasting time or that the features is
useless in general. They are just useless for me, as a PCB user. ***
About the new features: I'm not like John and I am not for a static
software package. However, I'm not like typical windows users either: I'm
not happy just because there are new features. I always like to look at
what the new features are about.
IIRC recent features I've seen discussed on the list:
- file format change to sql: would be an absolute show stopper for me;
I'd revert to an old version or change to kicad or whatever this happened
and I didn't have a fork
- doxygen documentation: I'm not against it, but I personally find
doxygen-generated docs totally useless in practice
- 3d support in core: I think it's bad design
- 3d exporter: it's a good idea, although I don't need it
- buttons and project manager: good for new users, I personally don't
need it
- importer/exporter to PADS or whatever other proprietary CAD's file
format: good thing, but doesn't affect me at all
I probably missed some interesting topics, but my point is that some of
these features are show stoppers for me, others are indifferent but at the
end "would just increase complexity and size" of core regardless of
whether I want to use them. Of course exporters are good in the sense they
are somewhat external to the core so they add features without increasing
core size. (This is the same idea Al threw in about having everything in
plugins).
Before I started the fork, I was using an obsolete version of PCB because
any time I upgraded, I got things worse. After a while I couldn't even use
the official Debian version because of opengl, so I had to roll my own
package. From that, sticking with an old verison and complining by hand,
it's a trivial step to make a fork when you want to implement something.
If you are wondering what kind of changes and features I'd like to see in
PCB, what kind of change I am for, well, they are in pcb-rnd. Or look at
the daydreaming subthread: a full redesign of the layout internals.
>> Forks may have different purposes. Some forks are created by the author in
>> hope that he can merge it back to mainline, some are not.
>
> I guess if you're correct that nothing worthwhile to you will happen
> in mainline pcb ever again, you have the right approach. Otherwise its a loss
> for you as well as everyone else.
This had been the case already for a few years when I made my fork. It's
been happening sice the fork too. I wouldn't bet a fortune on a change of
this tendency.
Regards,
Igor2
- Raw text -