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

[Carnë Draug]

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.

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

Carnë