Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
wolfspraul has joined #qi-hardware
cladamw has joined #qi-hardware
dvdk has joined #qi-hardware
<qi-bot>
[commit] David K
<qi-bot>
[commit] David K
wej has joined #qi-hardware
jow_laptop has joined #qi-hardware
xiangfu has joined #qi-hardware
panda|x201 has joined #qi-hardware
rejon has joined #qi-hardware
rejon has joined #qi-hardware
<qi-bot>
[commit] Adam Wang: changed AD1580BRTZ pin3 to Unspecified, added WM9707SCFT/V description with 48-lead TQFP, added few lib into .pro file (master) http://qi-hw.com/p/kicad-libs/c35e54d
<qi-bot>
[commit] Xiangfu: m1/patches/rtems: milkymist-audio-add-support-mic-boost.patch preserve the mic boost setting (master) http://qi-hw.com/p/wernermisc/56adfde
<GNUtoo>
duck duck go tells it's a package from openwrt
GNUtoo has joined #qi-hardware
LunaVorax has joined #qi-hardware
GNUtoo has joined #qi-hardware
zenlunatic has joined #qi-hardware
<kristianpaul>
GNUtoo: yup it is
<wolfspraul>
wpwrak: did you see Dick on the kicad list explaining that the company he works for (I guess) specifically says they don't want him to fix bugs or provide support anymore, only *new* features in KiCad? :-)
<wolfspraul>
that is so funny
<wolfspraul>
the often seen industry race - who can claim whatever feature X first, whether it works or not, whatever the details - all irrelevant
<wolfspraul>
by the time people find out feature X is totally broken, feature Y is being hyped and driving new sales :-)
<wpwrak>
ah, interesting ...
<wpwrak>
funny comparison with linus/linux. i'd say linux was already rather big by the time he started to earn real money with it. i guess C-based projects just scale more gracefully :)
<wolfspraul>
he seems worn out
<wolfspraul>
should sleep a bit :-)
<wolfspraul>
the strategic concern of kicad should be readability and maintainability of code, modularity, community policies and culture, collaboration with geda, much better way for people to work on a high quality free component library, and a thousand other details
<wolfspraul>
my 2c
<wolfspraul>
what Dick is describing there is mostly an illusion
<wolfspraul>
but it's good that he's brining it up, so he shares his frustration a little and others can pad on his back
<wolfspraul>
bringing
<wpwrak>
his approach doesn't scale. it's the "core team of tired old men" approach.
<wolfspraul>
sure. also lack of trust in true community momentum.
<wolfspraul>
I think it was a bad day with his company telling him that he's not allowed to fix bugs, only add new features.
<wpwrak>
a bad combination. a "core team" per se isn't so bad, but it has to be agile. else, it's only busy making excuses or fighting competition
<wpwrak>
while everybody else either gets frustated or falls asleep
<wolfspraul>
honestly, with all my industry experience, that's one of the most stupidest things I've read in a long time, if that was really the mandate
<wolfspraul>
I cannot imagine any company on a sustainable path with that kind of mandate. I would go to the highest management available to me and put my badge on the table :-)
<wolfspraul>
but I also think he is just describing it that way, his superiors were probably getting impatient about a lot of 'big features' that they want to see soon
<wolfspraul>
so yeah, a little stressed out there :-)
<wpwrak>
hmm, could be
<wpwrak>
well, as long as the "core refactoring" is part of the "new features", a bit more focus wouldn't be so bad :)
<wolfspraul>
you know when you hear about 'big refactoring', in >50% of cases that's the beginning of some trouble
<wolfspraul>
the longer the refactoring takes the bigger the risk
<wpwrak>
yes, that refactoring has been going on for at least a year too long
<wpwrak>
nothing wrong with discussing such things for a few days and then getting busy for some weeks. but at some point of time, the momentum just disappears
<wolfspraul>
sure
<wolfspraul>
a year? then it's dead
<wolfspraul>
is the refactoring happening in live code/commits?
<wolfspraul>
I didn't notice anything
<wolfspraul>
oh, maybe I did notice the insane amount of renames back and forth
<wolfspraul>
without any consistency
<wolfspraul>
SomeFunction -> Some_Function -> some_function -> SomeFunc -> smFnc -> some_FUNCTION -> and so on
<wolfspraul>
that's kicad
<wpwrak>
;-))
<wolfspraul>
and all names move in different ways, so a() becomes A() while at the same time B() becomes b()
<wolfspraul>
go figure
<wolfspraul>
really
<wpwrak>
well, there's the big redesign of the internal database engine ...
<wolfspraul>
I don't mind cleanup, at all. but when I see names changing in different (!) directions, that's bad
<wpwrak>
of course, one problem may be that the task is too big to do it in one session. that's the day job problem
<wolfspraul>
so those big changes are happening in the live code base? or is there a branch somewhere?
<wolfspraul>
if it's in the one trunk codebase, maybe it can be finished one day :-)
<wpwrak>
and yes, redundant renames can be a bad sign. i do that quite a lot too, though. but it's usually quick. maybe 5 minutes and then i like my code again.
<wpwrak>
i don't really know where those big changes are
<wpwrak>
maybe ask ?
<wolfspraul>
I'm talking about inconsistent naming changes
<wolfspraul>
the inconsistency is what is bad
<wolfspraul>
because you may as well stop the stupid renaming and first settle on *ONE* system
<wolfspraul>
otherwise I rename your names, and you rename mine
<wpwrak>
i've seen some blueprints mentioned. and a bit of infrastructure code is getting merged. but i don't know if there's a real migration branch somewhere
<wolfspraul>
and we happily commit ever thereafter
<wpwrak>
ah yes, if people are diverging, that's a problem