Mail Archives: geda-user/2015/07/10/16:23:30
On Thu, Jul 9, 2015 at 9:33 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
> On Thu, 9 Jul 2015, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>>>
>>>
>>> My specific answer in case of PCB:
>>>
>>> - DVCS kills point 1. and 3. for me. It often kills 4. too, but in case
>>> of
>>> PCB I couldn't ever see a clear roadmap since I started to use it in the
>>> mid
>>> 2000s.
>>
>>
>> You should really try again on DVCS. Its just totally better and the
>> world
>> isn't going back, don't shut yourself out of having fun on 90% of new
>> software.
>
>
> You automatically assume DVCS is the future and centralized VCS is the past,
It more observation than assumption at this point.
> and anything newer must be better, so it must be more fun for me. I do have
I started with CVS, eagerly learned SVN but thought mixed revisions were
undesirable, and when I tried git there seemed little contest. Its not just
that it's newer, I happily use lots of ancient things because I think them
better than more recent offerings (gtk, make, etc.).
> a long list of _technical_ arguments why I prefer centralized VCS, but
> honestly, I don't want to waste my time if you already have such an image
> about DVCS.
Since VCS doesn't do anything that DVCS can't do, I'm guessing these arguments
are all going to fall into the "it causes people to do convoluted things"
category. You may be right that DVCS has contributed to gEDAs forking problem,
but its certainly not the only cause and VCS wouldn't solve the problem at
this point.
>>> - In practice this means random people are working in random branches on
>>
>>
>> This is certainly true of gEDA but not because of DVCS.
>
>
> Your view. Mine is switching from DVCS to a centralized one would be the
> first step to clean up the mess. We probably won't ever agree on this, and I
> accept this; and do you?
If I must, but (at least rough) consensus is always nice if possible. Did you
take a look at Fossil that got mentioned in the other thread? It sounds to
me like it addresses many of the things that bother people about git.
>>> version of PCB that I choose was mature enough.
>>
>>
>> This is the death spiral gEDA is stuck in. Main line development is so
>> slow
>> that (essentially) private forks are more attractive, which in turn slows
>> development more, etc.
>
>
> For me, this is the vitality spiral of gEDA. If I didn't make that PCB fork,
> I may have switched to kicad or whatever else, or if not, I would surely be
> considering that move by now.
>
> I admit I am selfish, but having a PCB version that does what I want is more
> important than trying to push a version that's only getting farther and
> farther away from my needs. Since in either case I wouldn't contribute and
> wouldn't keep using the software long term, I don't even see how this makes
> any difference or induces a death spiral.
Here's the thing with new features: even *one* of them that is really useful to
you will probably induce you to tolerate some learning and problems related
to others that aren't. If you get the new code together into a single
release everything gets widely distributed and tested. You might even end
up liking some of those features that at first annoyed you. Most projects
proceed this way. gEDA has gone in an entirely other direction with massive
forking and very little integration.
"Death spiral", that was a negative, frustrated term. I retract it. But you
have to agree that its pretty sad that we've ended up with approximately
one symbol-to-part mapping system per user, piles of potentially useful code
languishing untested in branches, and endless, mostly fruitless discussions
of what might be done about the situation.
> So what's the deal here? Either everyone joins forces to work on something
> suboptimal, and then it's all great and joy, or people work on their own and
Well, if your private board production system with PCB is actually optimal,
I guess you're right, but mine is far from it and there are lots of things I
can imaging PCB doing better. My infrastructure for handling symbol->part
etc. works ok but I don't think you're properly accounting for the time
that's getting wasted in reinvention even of that relatively simple stuff.
DJ seems open to the idea of some kind of more aggressively integrated branch,
so if we had a (D)VCS that wouldn't cause anyone to run screaming, someone
willing and able to manage it, and some people to test out of it something
might happen.
Britton
- Raw text -