kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2014-08-15 14:17 GMT+02:00 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>:
> On 8/14/2014 6:55 PM, Derek Kozel wrote:
>> Hello!
>>
>> First of all thank you to everyone who has contributed to getting KiCad
>> to where it is now. I've made several boards with it and hope to make
>> many more. I'm a recent EE/CS graduate with experience working on medium
>> sized C++ projects, mostly in Linux.
>>
>> I'd like to give back to the project and the areas I think I can help
>> with are:
>>
>>  * Reviewing the open bugs and trying to link duplicates, recreate new
>> ones, and test if old bugs have been fixed but not closed.
>> For instance https://bugs.launchpad.net/kicad/+bug/593782 has been in
>> progress for 3 years and appears to be a Will Not Fix.
>
> Well that's embarrassing.  It's not a "Will Not Fix".  It's a "lead
> developer completely forgot he assigned himself for the task".  My
> feelings wont be hurt if you fix it.
>
>>
>> Is there a specific person who "owns" triage and bugs or is it open and
>> I should proceed using my best judgement?
>
> There is no one specific person although Nick Østergaard has been doing
> a great job of maintaining the bug report (a belated thank you Nick for
> your efforts).  As far as bugs go, use your best judgement.  Some are
> fairly simple but some have been known for years and require very
> significant changes (the Eeschema library search path ordering bug comes
> to mind).

Thank you very much for your acknowledgement. I like kicad, so I wan't
to help where I can. At the moment trying to keep the bug tracker
usable, by requesting more info if I think it is needed, mark
duplicates and such. Trying to keep it tidy, so it is easier for you
to use efficient. Sometimes I also tag bugs. I mostly tag bugs related
to Orson's work, because I know it makes it easier for him.

> Some general rules of thumb are:
>
> * Learn and follow the coding policy.  It's in the source documentation
> folder.  Patches can and will be rejected for policy violations.  We
> wont beat up too badly the first patch or two that has coding policy
> violations but as you contribute more the expectation is that the coding
> policy will be followed.
>
> * Start off with small changes and bug fixes to learn your way around
> the source.  KiCad is a large project so it takes awhile to figure out
> how all the piece fit together.
>
> * Always share your intentions on the developers mailing list when
> making significant architectural or behavioral changes.  It's also a
> good idea to let other developers know what you are working on to
> prevent duplication of effort.
>
>>
>>  * Reviewing and improving the main website
>> For instance KiCad appears to no longer have a presence on Sourceforge,
>> so the News, Press, and Sourceforge links are dead on the homepage.
>> (http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite) There
>> also are pages which could be improved both in content and organization
>> I believe.
>>
>> Who should I talk with about this?
>>
>>  * Updating the binary distribution of KiCad for Windows
>> The version linked to from the homepage is from over a year ago. If this
>> is the current Stable version, it seems like that should be explicitly
>> stated and links to that version for the other OSes provided. I'd like
>> to work with Brian Sidebotham or others from the winbuilder project to
>> supply more recent binaries under the unstable/development label.
>
> This would be great.  We have quite a few Windows users that would be
> more than happy to test the latest and greatest versions but don't have
> the desire to learn how to build KiCad from source even using
> kicad-winbuilder.
>
>>
>> The existence of a stable version or a release schedule is something I
>> wanted to ask about. I searched the website and developers list archive
>> but didn't see any references to either. This is the area I'm most
>> uncertain about as I don't have a full grasp on the project status and
>> roadmap.
>
> That has been discussed by the lead developers but no decision has been
> made on how to proceed at this point.  One thing I can tell you is that
> it will *not* be done the way we have done it in the past.  Trying to
> maintain a separate stable branch is too much work given the lack of
> manpower.

When I read the road map section about stable releases, I see the
status is listed as "Initial planning stages". I am wondering what
this initial plan is. Is this a public plan, or is it some
thoughts/wishes inside lead developers head? Or is the case "just"
that the lead devs are not motivated to work for stable release as
such?

I am curious about what kind of release model you want. I remember
that some of you (lead devs), at the time testing was renamed product,
that some revisions would be tagged as "a stable" period or something.
This has kind of happened twice, where the revision was set in the
kicad-install.sh. First time was at pre-kiway and a second time was a
few weeks ago or so.

>>
>> Thanks ahead of time for your replies. I hope I can help out and get to
>> know some of you.
>>
>> Cheers,
>> Derek
>
> Welcome aboard and thank you for contributing to KiCad
>
> Wayne
>
>
> _______________________________________________
> 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