Re: looking for a maintainer (pcb-rnd)
Hello Dima,
On Thu, 8 Dec 2016, Dima Kogan wrote:
pcb-rnd@igor2.repo.hu writes:
I got redirected from pkg-electronics-devel to debian-science with the
request below. I already have a working binary package lintian finds
good, the source package still has some lintian warnings. I'm the upstream
developer/maintainer; if someone is willing to maintain the debian
packages, I'd give all support from upstream side.
Hi. I could potentially do this, but I really don't like forks.
Is the original gEDA PCB project dead?
Not totally dead but sort of hibernated. I've been following the
mailing list and sometimes IRC channel for many years and
sometimes participated in the code sprints as an observer.
Facts:
- there's no clear project leadership at the moment, and as far as I can
tell there was none in the past year; it's hard to tell where the project
is heading
- last development snapshot release is from March 2014, the previous
(which I believe was the last official stable release) is from late 2011.
And it's not because the software is finished: number of bug reports and
feature requests are growing.
- as far as I can tell there's no planned date for the next release
- there's very slow progress in processing bugs or adding new features;
bugreports often end up in unresolved launchpad tickets; new features
usually end up in branches and it takes very long (or forever) to get them
merged back to master
- after some errors in around September, pcb got removed from Debian
testing
Do you share patches?
Yup. Especially in pcb-rnd -> gEDA/pcb direction. I am trying to balance
new features and refactoring decade old code in my fork. While doing the
refactoring I often bump into bugs that affect gEDA/pcb. I report these
and these reports often end up as launchpad tickets or even code in their
git. Sometimes they find a similar old bug in old code and I get a mail
that pcb-rnd might be affected.
I think we have a good cooperation on this.
However, patches are not byte-to-byte match, mostly because of the
different policies. Much more development time spent on pcb-rnd than on
mainline so we can affort refactoring. In fact we have cleaned up some of
the critical core infrastructure to remove limitations that bugged users
for years. This makes the same fix look different when saved in a patch.
Why would somebody want to use the original pcb instead of this one?
The only major features mainline offer and we don't are: opengl rendering,
having official packages in most Linux distributions and "being the
official thing".
In pcb-rnd we implemented a many features that had a long threads on the
mailing list but didn't result in any code in mainline.
To list a few of the extra features: we can read and write kicad board
files, we have a back annotation mechanism to gschem, we are portable (I
could compile and run pcb-rnd on an IRIX, without any GNU installed). A
longer list of new features:
http://repo.hu/projects/pcb-rnd/features/index.html
Can you send some links of the mailing list discussion that started the
fork?
It seems geda-project.org with the mailing list archives is down at the
moment. Couldn't search them in gmane either and didn't find cached
versions with google either.
I can share my point of view how it happened (sorry, wall-of-text).
I've been using pcb since about 2005. After some time I started to follow
development, joined the IRC channel, even made some negligibly small
contributions. As an user I was happy with the direction the development
went.
Later on there were new directions, things I didn't find useful and a few
things that even got in my way as an user. I first took the Debian package
and changed the configuration and built my own binary packages for my own
use. Then I started to do tiny code modifications to achieve small
changes I couldn't do with configuration. This went on for some time, then
around 2013 I finally realized I actually have an unpublished fork. I also
realized it's because I want to achieve things mainline doesn't and vice
versa. I announced the fork. This also meant I stopped trying to get my
features and wishes in mainline via requesting or patching, I just made
them happen in my fork. I spent extra effort on making these patches easy
to merge back in mainline, but I didn't make any effort to actually push
this.
During summer 2015 a newly active developer in mainline tried to channel
all efforts and forks and developers into mainline. Unfortunately the
direction pcb-rnd always took and the direction mainline went didn't
correlate at all, so my fork remained. There were fierce flamewars about
this with that developer and some mainline users.
I think the current "janitor" of the project (his own word for this) and
most current developers of mainline agree that it's good to have
alternatives and forks. We have good cooperation. One developer and some
users explicitly refuse to even try pcb-rnd (or any other fork). There are
still occassional opinions on the mailing list that forks are bad, but no
flame wars this year.
And how does the bus factor of your fork compare to that of the gEDA
pcb?
I think they are about the same in all aspects:
- in pcb-rnd I spent a lot of time and by now know most of the code base;
I'm alone with this here; about mainline my impression is that they have
1, maybe 2 already mostly passive developers having similar knowledge of
the code
- there are about the same amount of developers having partial picutre,
working on some smallish part of the code
- both projects have some central infrastructure (servers, services) ran
by a single person, so the bus number is the same on this too
- both projects are aware of the low bus number and are trying to increase
it; I made my highest prio to real-time support any developer when they
are working so my experience with the code base can be shared.
- I get positive feedback from pcb-rnd developers about how my
refactoring. Especially about how the modularization effort helped them
join the project and how harder it would have been with mainline. I like
to believe long term this lowers the barrier for new developers. In the
same time I've seen a new contributor joining mainline too. So I think the
two projects have similar bus number on this too, maybe with pcb-rnd has
more potential long term.
To be clear, there're no rules saying that Debian shouldn't carry forked
projects, but you're looking for a maintainer and not a sponsor, so you
need to sell this to a potential maintainer.
Sure, I totally understand.
When I try to "sell" pcb-rnd to new users, beside the software features I
usually highlight these human factors:
- We have a roadmap, and a steady, predictable progress. And
actual releases.
- We implement the wishes users stated in long discussions on the mailing
list (less talk and more coding, compared to mainline)
- We try very hard to keep the barriers low: users can report bugs through
whatever channels they can reach us, we don't require a launchpad account
or even a specific bug report format.
- We react on bug reports and user requests ASAP. This very often means
fix commited in svn within 24 hours from the report.
- Low developer barrier: because of the modularity, developers can join
and freely work on whatever features they want, without interfering with
existing code or features; in practice this means the chances are very low
for a developer or patch or feature to get refused or to bitrot in a
feature branch.
Best regards,
Tibor Palinkas
Reply to: