delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2017/05/30/11:14:08

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 30 May 2017 17:22:37 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb-rnd] up next: subcircuits (a.k.a. footprint
model redesign)
In-Reply-To: <alpine.DEB.2.20.1705301602550.1656@nimbus>
Message-ID: <alpine.DEB.2.00.1705301651010.27212@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1705300721100 DOT 27212 AT igor2priv> <alpine DOT DEB DOT 2 DOT 20 DOT 1705301602550 DOT 1656 AT nimbus>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com


On Tue, 30 May 2017, Roland Lutz wrote:

> On Tue, 30 May 2017, gedau AT igor2 DOT repo DOT hu wrote:
>> 3rd: pad stacks and blind/buried vias (with the lowest score possible - 
>> seems to be a lower priority task with no real user demand, postponed for a 
>> later date)
>
> I'm not actively doing PCB layout right now and haven't ever used blind or 
> buried vias, so maybe my opinion shouldn't be weighed to heavily here, 
> however: both "professional" electronic engineers I talked to which were 
> considering switching to PCB for layout told me that the inability to use 
> blind and buried vias was the mayor show stopper for them.

Sure, thanks!

A year ago I made a switch in pcb-rnd "project management": I realized I 
shouldn't care too much about the virtual ("would-be") users because they 
won't ever become actual users in 99.9999% of the cases, even when you 
spend days or weeks implementing their feautre request. I have multiple 
examples on this. (You can still see a failed experiment on this at 
http://igor2.repo.hu/cgi-bin/pcb-rnd-poll.cgi)

Instead, we favor the feature request of existing pcb-rnd users. If there 
are enough requests from them, requests of would-be users go at the end of 
the queue.

This method worked out very well. When I was doing the old method, pcb-rnd 
was really a one-man show. Sometimes I implemented what random people 
requested, but they nearly never cared to test the result (requesting a 
feature is for free, testing software is not - see below). Since I am 
doing this new method, we are constantly growing. So it's more beneficial 
to keep those users/contributors/developers happy who are really using 
pcb-rnd than those who might one day consider using it (but most probably 
won't).

Anyway, converting from virtul user to actual user is pretty simple, and I 
think we constantly demonstrate that we implement things in short time and 
that such a conversion is no waste of time. So if there's a would-be user 
now, who really wants a specific feature, he shall invest the time to 
become an actual user knowing that once that happened he can make the 
feature request and will probably see the feature implemented in weeks or 
months.

I also find this fair economically: a small investment required from a 
would-be user before the large investment from the developers is made. 
Else development time becomes valueless and there would be 1000 pending 
featur request that then noone will ever use or even try out, wasting 
development time on useless features instead of focusing them on useful 
ones.

From another aspect: if I ask you whether you want pcb-rnd to support 
spiral traces, why would you ever say no? Even if you think you won't ever 
use pcb-rnd, you have nothing to lose by saying "yes"; but if you say "no" 
and then you figure you want to use pcb-rnd there's one feature less. So 
from your seat the right answer is always "yes", because that costs you 
nothing and no risk involved, while a "no" would mean some marginal risk. 
This why I figured it doesn't make sense to ask would-be-users or 
non-users.

So bbvias and padstacks stay low prio until there's real user demand. Even 
if pcb mainline implements bbvia meanwhile. (And if that happens, then 
please do tell us wether that made those two guys switch to pcb.)

Regards,

Igor2



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019