Re: [Pkg-octave-devel] Concurrent maintenance of the Octave packaging

[John W. Eaton]

On  5-Oct-2011, Jordi Gutiérrez Hermoso wrote:

| How about having two separate packaging branches in hg? Say,
| packaging-stable and packaging-default. The merges should happen
| regularly in order to make the following inclusion lattice diagram
| usually true:
| 
|     packaging-default
|      /           \
|     /             \
| default         packaging-stable
|     \             /
|      \           /
|         stable
| 
| I.e. regularly merge stable onto default and onto packaging-stable
| *and* regularly merge both default and packaging-stable onto
| packaging-default. Merges are fairly cheap if they're done frequently
| and incrementally, so I don't think this is an excessive amount of
| extra work.
| 
| The packaging branches should contain the debian/ and whatever .spec
| stuff seems useful (and similar packaging information for Windows and
| Mac OS X?). The official Debian packaging can simply mirror the
| packaging-stable branch in Savannah and we can regularly push on that
| branch whatever changes the various distribution packagers deem
| necessary.
| 
| On the Octave side, we can regularly maintain the packaging-default
| branch so that the packaging is "always ready", so that when a new
| major Octave release happens, we can use what has been collaboratively
| maintained there as the basis of a new Debian packaging.

I'm probably missing something, but I don't understand the need for
the packaging-{stable,default} branches.  Are those in Octave hg
archive?  And separate from the current stable and default branches?
I don't understand why they need to be separate from the normal stable
and default branches.

| We can also keep more than one .spec for Fedora, for SuSE, and
| whatever else, but we don't need to distribute them in tarballs.

Right, if having these files in the tarballs would cause confusion and
trouble, then I agree, we don't have to include them in the tarball
distributions.  But if these files are part of the Octave sources,
then it seems we will be more likely to test them more frequently and
ensure that they work.

If maintaining them as part of Octaves hg archive is unacceptable,
then can we come up with some way to download and test the packaging
as (an optional) part of the build process?  I'm just trying to find a
way that we can keep the packaging info up to date so prompt binary
packages will be more likely in the future.  It seems to me that
testing and updating the packaging info more frequently would help
with that.  So it makes sense to me that we should try to make it
easier for more people to build the packages with a simple make
target.

jwe