kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #00297
Re: Re: Subversion Repository
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
"Richard A Burton" <richardaburton@...>
-
Date:
Wed, 30 May 2007 17:15:31 +0100
-
H=domainkey-signature:
received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
-
In-reply-to:
<f3ja51+101ki@eGroups.com>
I think better to make branches (and packages, RPMs, ebuilds, ... ) for:
Components libraries.
Components datasheets (bad idea to attach this with GPL program).
Help sources (Help for end user must be in HTML, PDF or CHM format).
Maybe something else (add what are you think.)
Agreed. As far as the Debian packages are concerned we already package
all the documents separately in individual language packs, so you
don't need to download any if you don't want to. We build from a
single source package and produce several doc packages, a binary
package and a common package. The binary is separate because Debian is
available on many hardware platforms and so it is policy to put
binaries in separate packages, one per arch, to the common data (if
there is more than just a small amount).
http://packages.debian.org/stable/source/kicad
At the moment it this all comes from a single source package, because
we take what is shipped as a release (it's obviously important that
the docs match the version of the code for example). But at the moment
we are just looking at the source repo layout. Generally I'd say
everything should be kept together in a single source package,
everything that is required to build the binary release. I'm not
suggesting changing how the binaries are shipped in general (thought
it sounds like this is something you want to address).
If you want my thoughts on binary packages I'd say the way we
currently do it for Debian is probably a good model.
One other idea: if you wanted to you could split the models and
library out completely. They could then have their own separate
versions and releases (so model packs can be updated/expanded more
frequently than code change releases). In this case they should go in
a separate svn area and have their own versioning. As all this stuff
is release independent (to a reasonable extent) it could be handled
separately.
All this stuff eat bandwidth, traffic, time and money when users
download single big package.
For end users better to download only what required for work with program.
Agreed, as above.
I hate CHM format of help, because when I read it, I can't increase
fonts or print only what I want.
The best format for documentation is HTML or PDF (IMHO). HTML is
preffered because it can be easy maintained by developers online in
Wiki and make PDF from HTML is not so hard.
I have no strong feelings either way on this. I don't actually use the help.
Richard, if you want, I can add you to developers at
kicad.sourceforge.net and you can make what is required for better
packaging of KiCad.
Thanks, that would be good. My userid is raburton.
Richard.
Follow ups
References