kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

Since Javier sort of let the cat out of the bag, I thought now would be
a good time as my first official announcement as project leader to talk
about creating a stable release of KiCad.  As you may have read in
Javier's post that this stable release would be a light weight release
in that there would not be bug fix back ports.  The goal is to attempt
to strike a balance between the needs of users and the resource
limitations of the project.  In order for this to work effectively, I
feel we have to adopt a slightly different development model than we
currently have.  I am proposing that we move to a model more like the
Linux kernel where there is a merge window for new features followed by
a stabilization period.  Once the merge window is closed, we can focus
on the tasks required for a stable release.  I am *not* suggesting we go
to a time based release.  I don't believe we are in the position to make
that happen.  The amount of time the merge window is open will depend on
what new features are introduced and how disruptive they are.  The
amount of time between the close of the merge window and the next stable
release will depend on how long it takes to complete all of the tasks
required to ready a high quality stable release.  The way I see it, the
following tasks would need to be completed in order for a stable release.

1) Bug fixing

At a minimum all bugs that cause segfaults or loss of data need to be
fixed first.  All new and existing features must perform as expected and
documented.  We need to flesh out all the new features such as GAL, P&S
router, and Kiway code to make sure it is rock solid.

2) Usability

The user interface should be as consistent as possible between the major
frame windows as well as the dialog layouts.  Any key board handling
quirks should be addressed.  I've seen a few bug reports about hot key
behavior so it would be good to get these resolved if they haven't been
fixed already.

3) Documentation

All of the features recently added to KiCad must be added to the
documentation.  The existing documentation needs to be vetted by folks
whose native language is English or have very strong English skills.
Quite a bit of wording of the existing documentation can be confusing.
There has been a suggestion of moving our documentation to a text base
layout format to make it more version control and translation friendly.
 I'm all for that.  One thing that I ask of whoever steps up to perform
this task that whatever format is choosen, the tools to edit and build
the documentation must be readily available on all the major platforms
support by KiCad.  By readily available, I mean there needs to be binary
installers.  I'm fine if Windows users have to install MSYS2/MinGW along
with the required packages to edit an build the documentation.  I don't
think it's good idea to ask our documentation folks to have to build the
tools from source.

4) Installers.

High quality binary installers are a must for all of the supported
platforms.  I cannot stress enough how important this is.  Asking users
to build and install KiCad from source is insane.

There are Linux distro packagers, corporate users, and potential
sponsors who consider stable releases a must.  Obviously, none of this
can happen without your help.  Please take a few days and carefully
consider this proposal and how you can contribute to help make it a
reality.  I will be traveling the next two days so please hold off on
the big barrage of comments and questions until early next week so I can
make a feeble attempt to keep up with them :).  I also want to extend my
sincerest thanks to all who have contributed their time, talents, and
money to help make KiCad what it is today.

Kind Regards,

Wayne