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" <l...@monda.hu> wrote: > > On Thu, Jul 25, 2013 at 4:28 AM, Alex G. <mr.nuke...@gmail.com> wrote: > > On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: > >> > >> On Jul 24, 2013 4:26 PM, "Alex G." <mr.nuke...@gmail.com > >> <mailto:mr.nuke...@gmail.com>> wrote: > >>> > >>> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: > >>> > > >>> > On Jul 24, 2013 3:05 PM, "Alex G." <mr.nuke...@gmail.com > >> <mailto:mr.nuke...@gmail.com> > >>> >> > >>> >> 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@lists.launchpad.net > > 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
