kicad-developers team mailing list archive

[László Monda <laci@xxxxxxxx>]

On Thu, Jul 25, 2013 at 2:13 PM, Adam Wolf
<adamwolf@xxxxxxxxxxxxxxxxxxxx> 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" <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



-- 
László Monda <http://monda.hu>