kicad-developers team mailing list archive

[László Monda <laci@xxxxxxxx>]

On Thu, Jul 25, 2013 at 4:28 AM, Alex G. <mr.nuke.me@xxxxxxxxx> wrote:
> 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.

PR is one of the strongest reasons, I believe.  Something like
http://kernelnewbies.org/LinuxChanges is badly needed for KiCad
because users have zero high-level visibility regarding new features.
For example the middle button panning feature might seem like a minor
change development-wise but it's extremely useful for users.

I agree that the no release philosophy directly contributes to
outdated packages on distros but seeing the resistance on the
development side this can't be expected to change.  A part of me can
understand it because backporting shit is no fun.

As an alternative it'd be extremely useful to provide daily releases
to the community.  Something like what Adam Wolf does but for all the
3 major platforms.  The version string could be updated to the current
day, this way users could see who runs the most recent version.  This
and the news section could boost adoption significantly.

> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



-- 
László Monda <http://monda.hu>