kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Mac and Windows are getting there.  I fully expect that by the end of 2013,
Kicad'll have daily builds for a few varieties of Linux, OS X, and Windows.

I can't say I'm entirely pleased that Dick thinks the package maintainers
should simply retire. Could you clarify , Dick?

Adam Wolf
Wayne and Layne LLC

On Jul 25, 2013 4:27 AM, "László Monda" <laci@xxxxxxxx> wrote:
>
> 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>
>
> _______________________________________________
> 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