kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <mangelajo@xxxxxxxxxx>]

----- Forwarded Message -----
From: "Miguel Angel Ajo Pelayo" <mangelajo@xxxxxxxxxx>
To: "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx>
Cc: "KiCad Developers" <kicad-developers@xxxxxxxxxxxxxxxxxxx>
Sent: Saturday, 30 August, 2014 10:39:24 PM
Subject: Re: [Kicad-developers] Project proposal

Hi Wayne!,


> 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.

That's very similar to other projects I work for from my position at
Red Hat (openstack), we have a window to provide specification for new features,
a window to merge new features, and a window to stabilize.

At least for the subproject I work on (neutron) it's 3/4 (new features)- 
1/4(stabilization), in this case we have back ports to stable branches,
because we have resources for that, something that helps on that is 
marking the backportable fixes with  "Backport-Potential" in the commit message.

I can only say, that removing the time constraints, and the backports, 
it already sounds like a very good enhancement to the project.

> 
> 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.

I'm not in the position to help on this at this moment, but I also believe 
it's something very necessary if we want to remove the entry barriers for users.

I'm my opinion, the more automated the installer generation is, the better,
this way we could auto build, and auto upload even the development releases
to be accessible to anyone.

> 
> Kind Regards,
> 
> 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
>