kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

>________________________________
> From: Dick Hollenbeck <dick@xxxxxxxxxxx>
>To: Alex G. <mr.nuke.me@xxxxxxxxx> 
>Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx> 
>Sent: Thursday, July 25, 2013 11:51 AM
>Subject: Re: [Kicad-developers] The KiCad GAL new release
> 
>
>
>
>On Jul 24, 2013 4:26 PM, "Alex G." <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
>> >>
>> >> 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.
>You cannot vote action in this project, except when you have a volunteer that is soliciting opinion and willing to do what is decided by others according to vote.  I can tell you now that I will never make a single commit to the stable branch, ever.
>I think it is a dilution of testing and development resources that keeps folks from testing the testing branch.  The end result is both branches are of reduced quality relative to a scheme where bugs were smoked out faster because everyone is using the same tree.  Again, the stable branch is fools gold.  True gold is rapid fixing of breakage in one branch.
>Package maintainers can establish their own policies, but they need not have an effect on my opimions, any more than my opimions affect their policies.
>


Ah, 'stable' release ... I thought the software world threw out that notion years ago - everything is simply branded Beta software these days, even the stuff I pay $$$ for.  From the user's manager's distorted point of view, software should simply work and if there are bugs then the vendor should provide a fix. From the user's point of view, they don't want to learn to compile software. Neither the user nor any managers would want someone to waste time when something breaks and neither would want an incompatible change in file formats.

Personally I think that with some software the package maintainers simply have to deliver scripts which build the package as needed. With 'git' this is utterly trivial - the package maintainers can associate a version with a git tag and allow the users to update to the latest in the repository. If the user encounters bugs in the new build they can reinstall the older version, and if they have thrown out the installer package then they can simply rebuild the older version from its git tag. This scheme would be similar to (but much better) than what people currently do on MSWin: (1) install update, (2) scream and tear out hair, (3) uninstall, (4) reinstall older version.  So the package maintainer needs to act a bit like a release manager.

Although I agree that the packaging is not KiCAD's problem, the question remains: is there anything we can do to help promote KiCAD?

- Cirilo