Mail Archives: geda-user/2015/10/10/04:03:40
Kai-Martin Knaak wrote:
> DJ Delorie wrote:
>
>
>> Arguing over how forky a fork is is, well, petty. Igor2 is doing
>> something different with the code, fine. He's also still involved
>> with us, fine. Why is this a problem?
>>
> He presented his project as "a _proper_ fork" (underline in the
> original).
>
>
>
>> It's no different than every
>> git branch we create being a "fork" that may or may not get merged,
>> other than irrelevent mechanics and probabilities.
>>
> Igor consistently declares to have no intentions to merge his changes
> back to main line geda. Creators of feature branches typically are
> motivated by the prospect to have their feature merged. To me this
> represents the difference between a fork and a temporary side step.
>
> ---<)kaimartin(>---
>
>
>
Hi Kai-Martin and list members,
I think everyone should scratch their own itch first, before rubbing others.
A quote from a US president comes to mind: "Lead, follow or get out of
the way".
At the time gEDA/pcb didn't lead (properly), nor followed upon Igor2's
plans, so Igor2 started a fork.
Given the history on this one I think it's OK for Igor2 to branch/fork
and then wait for the others (gEDA/pcb developers)to make a first step:
and that would be committing branched/forked code snippets into the
gEDA/pcb repository.
So far I see no efforts being made to incorporate his forked code.
Not even a Launchpad (LP) bug report is filed or a single topic branch
started, so patches can't be included for testing.
All of us gEDA/pcb developers are busy doing other things and have
prioritized them higher.
I for one would like to delve into this, make an implementation plan and
start committing.
It's just that I have only a hand full of spare cycles every day (yeah,
that's a lame excuse ;-).
Getting people motivated for a monthly effort to work on indentified
bugs is a higher priority for me --> more developers ==> more spare
cycles available ==> more bugs squashed.
For users/consumers it's easy: file a bug report and wait see what
happens, give a few reminders if things take too long and move on to
other software if it isn't solved within a year or so.
And as you may have noticed: *we* (few) developers have a massive backlog.
Another issue (pet project) that has a higher priority for me, is
getting pcb Doxygenated, as to give a better and easier understanding of
what is going on inside pcb, for current and future developers --> more
spare cycles better used ==> more efficiency.
And third: every *team* needs a common goal, so first of all *we* need a
good plan to get the efforts of *us* developers aligned (team == 1
common goal, group of "N" people == "N" individual goals).
Launchpad Blueprints (https://blueprints.launchpad.net/pcb) are a good
place to write up plans, some examples are provided for, see it as a
"Facebook" for developers if you will.
These Blueprints can be linked against bug reports.
It's available and editable to *everyone* having a LP account, and as a
side effect all subscribers get a notification by e-mail if something
changes, just to keep them informed.
So to summarize: lots of work to be done --> no time for infights -->
let's all take a first constructive step today ;-)
Kind regards,
Bert Timmerman.
BTW: maybe some of this should go into the wiki.
- Raw text -