octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OCL package 1.0.0 released


From: Olaf Till
Subject: Re: OCL package 1.0.0 released
Date: Thu, 5 Dec 2019 22:43:29 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Wed, Dec 04, 2019 at 10:17:42PM +0100, Matthias W. Klein wrote:
> So I think the OF repo should, as a next step, become a clone of the
> existing SF repo; I would do this by pushing my local repo to the empty
> OF repo. Will this give the correct result?

Yes, it should.

> > IMHO the package is a candidate for the 'community' group. In testing,
> > I explicitly request help of others (something has already been
> > done). Most testing is usually to be expected when you initiate a
> > release at OF.
> 
> It's controversial. I can see arguments for both 'community' and
> 'external': The OCL package is mainly C++ code depending on
> octave core sources, which would favor a community package status. On
> the other hand, OCL - especially depending on third-party OpenCL drivers
> - has shown to not always be plug-and-play, which would make an external
> status suitable.

As you can read at our 'Developers' page, not the issues you mention,
but others, are supposed to be a base for deciding between 'community'
and 'external'.

If you want to decide together with others what is the best way to
develop the package, and you are willing to sometimes follow a
decision although you think another would be better, choose
'community'. If you want to decide everything yourself, choose
'external'. But in the latter case, not all of us may be motivated to
help. Note also that an external package may cause a problem if it
provides a very desirable functionality and its owner stops
maintainance or develops the package into a direction not thought
ideal by the Octave community.

> > - Please study the directives for maintainers at our web page. You
> >   should add a Makefile at the root level of your package, with
> >   targets for releases and so on. This could point into the respective
> >   existing targets of your src/Makefile, but that's not usual. If you
> >   like, you can use (modifiy) the template root level Makefile from
> >   our web-page.
> 
> Many of the directives have been familiar to me for the project layout.
> So far I have, nevertheless, chosen a somewhat uncommon directory
> structure in the repo. This is mostly due to the fact that, for
> the usual repeated incremental code developing and testing, I am using
> 'make' for partial rebuilts. However, I made sure that 'make dist'
> creates the correct installable release tarball. Other aspects can be
> discussed with interested collaborators.

I don't understand why this hinders you to add a root level Makefile
for the release-related stuff. src/Makefile should still be there, of
course, and you are free to use it as you like. A decent additional
root level Makefile makes things easier for the person who has to
check and publish the release. Indeed, it is a 'hard' requirement for
all OF packages.

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]