Mail Archives: geda-user/2015/08/26/11:03:56
On Tue, Aug 25, 2015 at 11:22 PM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> 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
I agree with John for the most part but I am tired of the topic being
mentioned in every thread.
> 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
The problems we have are not caused by the file format architecture
but by the messy way the layout is handled after it leaves the file.
SQL would not fix this but it might motivate change in the layers
above it.
> - doxygen documentation: I'm not against it, but I personally find
> doxygen-generated docs totally useless in practice
Fair but I would really use it.
> - 3d support in core: I think it's bad design
Yes that should probably be in a library that connects to HID.
> - 3d exporter: it's a good idea, although I don't need it
Cool features like this are what expand your user base. New users like
eyecandy even if the things that make a tool great have nothing to do
with it.
> - buttons and project manager: good for new users, I personally don't need
> it
Agreed
> - importer/exporter to PADS or whatever other proprietary CAD's file
> format: good thing, but doesn't affect me at all
I don't see anyone here actually doing this and if they did I would
hope it would be it's own library.
> 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
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -