kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.







>
> > I regret ever creating the stable release.  It is simply fools gold.
> > The testing tree almost always has fewer bugs simply because they get
> > fixed faster.
> >
> As a Fedora package maintainer, I can vouch that lacking a stable branch
> would be a headache hell for a packager. A stable branch prevents cases
> where a deadly bug is introduced, and very quickly fixed, but a distro
> taking the source snapshot right in-between. Fool's gold or not, it
> serves its purpose.
> DISCLAIMER: I am not involved in packaging Kicad for Fedora.
>
> Alex
>