kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Jul 24, 2013 10:14 PM, "Cirilo Bernardo" <cirilo_bernardo@xxxxxxxxx>
wrote:
>
> >________________________________
> > 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.

Each software project has different dynamics of evolution.  Bunching them
all into one broad statement is incorrectly crude.

>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.

The builder simply rebuilds, usually within a half day of when the broken
code is fixed by a project developer.  Its simpler than you describe.

>
> Personally I think that with some software the package maintainers simply
have to deliver scripts which build the package as needed.

Kicad package maintainers can retire as far as I am concerned.  Their work
is not relevant to the optimal kicad experience.

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?

Use the testing version, so bugs get found before they "get released" into
the world of those collecting fools gold.

This will actually increase reliability for all.

>
> - Cirilo