kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----
> From: Wayne Stambaugh <stambaughw@xxxxxxxxxxx>
> To: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Cc: 
> Sent: Sunday, August 31, 2014 4:47 AM
> Subject: [Kicad-developers] Project proposal
> 
> 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.
> 


[snip]

I think it's OK not to set a fixed interval for the merge window, but we
will need some coordination - at least a web page where people can put
notes about what they are working on and the progress they're making. That
would make it easier to decide when to make a release and what features
will have to wait until the next release. I think this will make it a
little less ad hoc and more productive. I've been checking out FreeCAD
for a number of years and they don't seem to have such coordination
(to some degree each contributor has too much freedom to do as they please)
and I don't think the results are good.

In other news, one of the items I have on my list of things to do is to
create a unified API to the import/export functions. I'm wondering if it
would be reasonable to put them all into the file I/O API; after all,
the majority of software out there does this. In SolidWorks for example
I can save my drawing as a SLDDRW, DXF, or others and when I wish to
import a document I simply load it and it will be converted as appropriate.
On the other hand some things will be a bit strange - opening a DXF file for
example results in drawing primitives imported to a layer and choosing
'Save as DXF' will result in a dialog to select the layers to export.
It needs some more thought - but it's #3 on my list of things to do so
there's plenty of time to think about it.

- Cirilo