kicad-developers team mailing list archive

["Alex G." <mr.nuke.me@xxxxxxxxx>]

On 07/24/2013 08:51 PM, Dick Hollenbeck wrote:
> 
> On Jul 24, 2013 4:26 PM, "Alex G." <mr.nuke.me@xxxxxxxxx
> <mailto:mr.nuke.me@xxxxxxxxx>> wrote:
>>
>> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote:
>> >
>> > On Jul 24, 2013 3:05 PM, "Alex G." <mr.nuke.me@xxxxxxxxx
> <mailto:mr.nuke.me@xxxxxxxxx>
>> >>
>> >> P.S. I can't emphasize enough how much I like the new rendering modes.
>> >
>> > To hear this is good news, I have yet to spend this time to review the
>> > intermediary work.  But I am extremely happy to hear that someone finds
>> > this massive body of work promising.
>> >
>> > I think your opinion of "releases" may be overrated however.  What is a
>> > release wrt kicad?  Its fools gold IMO. Just use your own build, you
>> > obviously know how to build it.
>> >
>> A "release" or "stable branch" in distro packager terms is code that the
>> developers, to the best of their ability certify is stable and good for
>> production use. In fact distros have specific guidelines about not
>> packaging "development" code. What this usually means is distros want a
>> tarball without the terms "rc", "nightly", "devel", "alpha", "beta", etc
>> (a release). If that is not available, distros are also willing to
>> accept a snapshot of the repository, but strongly encourage
>> (gun-aimed-to-your-head type encouragement) a "stable" branch is packaged.
>>
>> What this usually means is, as long as GAL is just another branch, it
>> won't get into the hands of the majority of users.
>>
>> There are also a few "things" that make merging GAL non-trivial. First
>> of all, the tools do not (yet) work in OpenGL/Cairo modes. This will
>> require a smarte(er) merge strategy. In merge ASCII art, it would look
>> something like:
>>
>>  - (devel)     |-----------------------------------*----------------
>>                |                                  /
>>  - (gal_merge) |      *---(make tools work, etc) *
>>                |     /
>>  - (gal)       |----*------(continue normal GAL cycle)-------------
>>
>> (You'll need to read this in monospace for it to make sense)
>>
>> Now this requires some work. I am not qualified to operate the Kicad
>> source tree, but I'm willing to bet it should be doable in a reasonable
>> timeframe.
>>
>> Is it worth it? I vote "yes".
> 
> Distro kicad  packages are not even worth the effort in several of the
> distros, they are so far behind current code as to be irrelevant for a
> serious kicad user.
> 
DISCLAIMER: Skip to third paragraph if you are not interested in
discussions about releases. I won't mind.
DISCLAIMER2: I'm perfectly fine with the current no-release philosophy.

And distro packages being so far behind is partly due to the
release-less philosophy. First of all you lose all the bells and
whistles of a release (blog posts, articles, users seeing a higher
number). You lose, all the publicity, and you lose the users saying "My
kicad is newer than yours", and hence you lose pressure on the packagers
to update. There's no concept of newness. A Kicad branch from two years
ago is just as good as today's Kicad (1) (exceptions exist). I speak
from the perspective of a packager who is not necessarily a "serious
kicad user". Not all packagers are.

Another thing to keep in mind is packager lazyness may hurt Kicad. I
often hear things like "I can't use kicad because it has [this] and
[that] problem; kicad sucks [blablabla]", when the problem they describe
had been fixed months or even years ago.

*** Third paragraph: ***

The release discussion aside, what I was focusing on in the previous
email was getting kicad GAL into mainline and getting it to be fully
functional -- where "getting" is to be understood as "someone please
come do this". I define fully-functional as being able to design a board
in the new rendering modes. If you'll try laying a track in non-default
mode you'll see what I'm saying.

> You cannot vote action in this project,
> [...]
> I can tell you now that I will never make a single
> commit to the stable branch, ever.
> 
Not what I was voting on. Anyhow, I withdraw my (invalid) vote.

Anyway, sorry to raise the undead army.

Peace out!
Alex

(1) This is a great thing actually. It demonstrates the quality of the
Kicad code base is very high