kicad-developers team mailing list archive
Mailing list archive
Re: The KiCad GAL new release
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?
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
> >>> >
> >>> > To hear this is good news, I have yet to spend this time to review
> >>> > intermediary work. But I am extremely happy to hear that someone
> >>> > this massive body of work promising.
> >>> >
> >>> > I think your opinion of "releases" may be overrated however. What
> >>> > 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
> >>> developers, to the best of their ability certify is stable and good
> >>> production use. In fact distros have specific guidelines about not
> >>> packaging "development" code. What this usually means is distros want
> >>> tarball without the terms "rc", "nightly", "devel", "alpha", "beta",
> >>> (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
> >>> 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
> >>> 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