On Thu, Jul 25, 2013 at 2:13 PM, Adam Wolf <[email protected]> wrote: > 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.
Excellent news, Adam! It'd be great to create a download page for the daily releases featuring the daily download links along with daily commits in an easy-to-read manner. Of course this will truly make sense when all the platform-specific builds will be ready. Speaking of the site, it's down. Am I right that it's pretty usual? I'd like to contact with whoever is responsible and offer my help. As a first step Pingdom should be set up to get notified. Just instructed Netcraft to monitor site uptime: http://uptime.netcraft.com/up/graph?site=http%3A%2F%2Fwww.kicad-pcb.org > 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" <[email protected]> wrote: >> >> On Thu, Jul 25, 2013 at 4:28 AM, Alex G. <[email protected]> wrote: >> > On 07/24/2013 08:51 PM, Dick Hollenbeck wrote: >> >> >> >> On Jul 24, 2013 4:26 PM, "Alex G." <[email protected] >> >> <mailto:[email protected]>> wrote: >> >>> >> >>> On 07/24/2013 03:41 PM, Dick Hollenbeck wrote: >> >>> > >> >>> > On Jul 24, 2013 3:05 PM, "Alex G." <[email protected] >> >> <mailto:[email protected]> >> >>> >> >> >>> >> 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 : [email protected] >> > 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 : [email protected] >> 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
