Re: Octave-Forge: requirement for a maintainer Makefile for release

[Philip Nienhuis]

Carnë Draug wrote:
> On 11 November 2016 at 22:09, Philip Nienhuis <address@hidden> wrote:
> > Carnë Draug wrote
> > > Hi everyone
> > >
> > > As you will know, there is a requirement that Octave Forge packages to
> > > have a clone of their repository in our project at sourceforge with,
> > > at the very least, the state for the package releases.  However, this
> > > sometimes doesn't happen and releases are requested with files that
> > > are missing in the repository.
> > >
> > > Many of the packages now have a Makefile at the root of the package
> > > for maintainer tasks such as making a release.  I would propose to
> > > make this a requirement to solve this issue --- since hg and git export
> > > would not export files and changes not commited --- and to reduce the
> > > work required for pushing a release --- since I would not have to check
> > > this myself.
> > >
> > > The plan would be that package maintainers would provide a revision
> > > hash (or maybe a revision tag), and whoever is pushing the release
> > > would build the actual release tarball.  The package maintainer would
> > > still
> > > be responsible to upload the html documentation.
> > >
> > > The only issue I see is with packages that may require a special tool
> > > or a specific version of the tool.  Even different versions of autoconf
> > > could generate slightly different configure scripts.  However, I am
> > > guessing that in practice this will not happen and can be handled at
> > > the time if they do.
> > >
> > > Anyone has any more thoughts on this? Anyone opposes?
> >
> > If I interpret your motive correctly, the things you're after is better
> > quality control (QC) and shifting the burden of QC from you to the package
> > maintainers.
> > The QC aspects solved by your suggestion comprise missing files, outdated
> > files (not updated in the repo), autoconf & configure having been run and I
> > might overlook a few things. In summary, the more "administrative" parts.
> >
> > OK I agree that QC shouldn't be a primary task of the Octave-Forge admin;
> > maybe a responsibility but if so a responsibility that can at least be
> > delegated.
> >
> > I doubt if effective QC can be done by the same person as the one who
> > created the code & package in the first place (=package maintainer).
> > Yet automating boring parts of it, if only by requiring a Makefile with
> > predescribed contents, may help catch the basic errors.
> > Can makefiles be used to check if an on-line repo is up-to-date?
> >
> > As to separating the release tarball from the html tarball: my experience is
> > that distributed responsibilities just don't work reliably.
> > Can a makefile be used to create (and upload) package html (by invoking
> > Octave)? (I'd guess yes)
>
> makefiles are just a list of commands.  If you can write it, then you can
> have your Makefile do it.  All Makefiles at the moment also create the
> html so that is already done.  In theory you could also have code to create
> a new ticket on the release tracker and upload it.
>
> Note that I am not asking for a standard Makefile across all repos.  All
> I am proposing is that at least a "dist" target must exist to recreate
> the release tarball.  I would say this is more about reproducibility than
> quality control.

Reproducibility is a form of QC.

> > One of the things with the current Makefile setup is that it also generates
> > a release tag.
> > I usually wait with a release tag until the release is finally on
> > Octave-Forge as it sometimes happens that additional bugs are discovered and
> > fixes are needed while the release waits on the release tracker; to avoid
> > "gaps" in the release numbers. But maybe release version gaps isn't such a
> > big deal.
>
> I just checked all Makefiles in Octave forge and not a single one tags the
> release.  Some tell you to tag the release but none actually does it.  Even
> if they did tag the release, tags are just a line in file that you can change
> afterwards if the release fails review for some reason.

You're right, I just checked in of-mapping. And it can be rolled back. 
Sorry for the confusion.


Some things I do not understand about the first two paragraphs in your 
original post:
AFAIU missing files are a primary motive, right?

Now, even if the OF site admin were to make a release based on some 
revision of the on-line repo using a package makefile, there's no 
guarantee that the on-line repo revision is "complete". The OF package 
maintainer may still have forgotten to check in files into his local 
repo before syncing it to the on-line repo. A makefile won't help there.

A more robust check would be if all OF packages would contain a test 
suite that covers the entire package contents. Or something like lint to 
check & follow all function calls.

Not that I am opposed to a makefile with a dist (+ html) target; it'll 
help to run autoconf/bootstrap etc (I remember to have forgotten that 
myself before uploading a package) and -most of all- automates a lot of 
work.

Philip