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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
