Mail Archives: geda-user/2015/07/09/22:59:29
I am choosing to pick up this thread with this email.
On Thu, Jul 9, 2015 at 4:01 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> On Wed, 8 Jul 2015, Evan Foss (evanfoss AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>> A few people have said that projects slow when developers loose
>> interest. While everyone is here (admittadly sucked in by the gravity
>> of the other thread) it is worth asking what would excite developer
>> interest?
>
>
> I am an user of gEDA; mostly gschem and PCB. I never contributed anything,
> so my opinion is of an outsider's and is mostly about how/why I didn't join.
>
> First, my generic answer. What makes me work on a random open source
> project? For me, it's a combination of these, probably in this order or
> priority:
>
> 1. It's fun to code it - in hobby projects this is clearly the top prio
I use geda for work a lot.
> 2. I need the feature - in a project ran by others, it's unlikely I'd work
> on a feature I wouldn't need or use directly. I think I'd leave
> such features for other developer. It's a bit different in the projects I
> run, for some reason I feel more responsibility there.
>
> 3. My work is useful and is built into the project; my patches are not
> thrown out and there are no unreasonable barriers that make any contribution
> 10x more complicated and time consuming than if it was my own project. This
> point may look somewhat fuzzy in this generic form, but it is very clear in
> practice and the decision is easy when I send a few patches.
I understand this. I watched #4 happen.
> 4. This is a combination of 1 and 3: the project has a "roadmap"; it doesn't
> even have to be a written one, but generally it's going towards some
> specific goals that are recognizable with the naked eye of an average user.
> The goals should be at least partially aligned with my exceptations about
> the project. In other words: the project at least a bit tries to achieve
> what (as an user) I expect/want.
Hmm... sounds almost like why i started this thread.
> ****
> DISCLAIMER:
I removed the text here because people focused way more on it than the
rest of this which was to be blunt more relevant.
Once more deciding what repo system is used will ultimately fall to
the guy who runs the server. DJ
> ****
>
> My specific answer in case of PCB:
>
more snipping
> - Bad experience with contribution from the far past (others say these
> things got improved lately). Many years ago I tried to fix a small bug but
> getting my patch accepted took too long and I had to spend too much time
> fine tuning my patch for no apperant reason. Later on I tried to contribute
> by working out an external example code for getting shorts displayed better.
> Developers got distracted into a "before we can deal with this, we need to
> clean up the infrastructure of PCB here a bit" recursion (this happens a lot
> with me in my own projects too!). All in all, I consider both occasions
> total waste of my time which made it easy to move on to other projects.
And for all their cleaning only a handful of people can really be said
to understand the code.
> - PCB started to take directions in the last 4..5 years that I didn't really
> like. The new features were much more often annoying and contra-productive
> than useful for me. I started to compile PCB from source to turn off opengl
> (normally I'd install the debian package). The features I really wanted or
> the features I'd find useful didn't stir much interest lately. At some point
> a few years back, after a new version introduced
> yet-another-bunch-of-code-I-didn't-want, I just decided to fork an older
> version of PCB. I implemented the features I wanted, and I don't have to
> worry how a new release would be stuffed with features I'd never need.
The footprint of PCB grew a lot as I recall. I thought we could still
turn off opengl? Personally I love it. I did a board last month with
more than 2 layers and it was fantastic to have transparency.
> - Now that I have my fork, it's unlikely that I'd contribute to the official
> stuff for simple, small, local, selfish reasons: I obviously do all the
> little things the way I enjoy the most which makes working on my fork much
> more attractice any time I feel like coding something for PCB. It's a
> one-way mechanism.
Well I am sorry you are effectively cutting yourself off. I would like
to try your version if you don't mind. I am curious to see what you
would like the HID to look like.
> - It is important to mention that I could do this only because even that old
> version of PCB that I choose was mature enough.
>
> My practical reasons on gschem and related tools:
>
> - DVCS (see above)
>
> - scheme: I needed some netlist backends, but scheme fully blocked me.
> Actually it was cheaper to code up an sch parser in another language back
> then, reproducing a lot of gnetlist code. Later on I figured a viable
> "cheat" was to write gnetlist backends to export raw data in generic formats
> (text, xml, json, lihata). As it's basically just "copy an existing backend
> and modify the prints" kind of job I though it'd be quick. Unfortunately
> scheme made it very hard and painful. For me, scheme is clearly a
> showstopper.
I hear you on scheme. Did you add that scheme code to the main project?
> - gschem in its form is probably complete for me. I don't see any features I
> really need and I could implement in a reasonable time frame. Back
> annotation is something I'd love to have but the way I imagine that feature,
> it would require major changes, many of which would require UI changes. Even
> if there was no scheme involved, I am not sure I'd dare to jump on it,
> because of the sheer volume of the work required.
My only addition to gschem proper would be a spell check for the
comment field. I know a lot of people won't like it so that patch will
probably never get pushed out but for a dyslexic like me it is
critical.
> Regards,
>
> Igor2
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -