kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/30/2014 4:57 PM, Miguel Angel Ajo Pelayo wrote:
> 
> 
> ----- 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.

It would be nice if we could take advantage of CPack for this purpose.
It's one of those things I'ld like to take a look at if I had the time.
 This would allow us to set up builders to create packages for all
platforms.

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