Re: Octave Forge: Package groups and properties defined, RFC.

[Julien Bect]

Le 08/03/2017 à 09:47, Juan Pablo Carbajal a écrit :

In [3] I see problmes with these sentences

* "If an external package is removed from Octave Forge, no new package
with the same name may be hosted at Octave Forge." I do not understand
the reason for this and I see extra work on keeping the name history
of packages without a clear benefit anbd the eventual failure to be
coherent with our own rules. Also consider: external package A evolves
to be so good at being matlab compatible that we move it to a
community package...so now it is not called A anymore? Silly, it
confuses users, and makes tracking the package harder. It sounds like
an unnecessary problematic rule.

Yes, perhaps the formulation is not "optimal"...

---- LONG STORY ----

The point is to acknowledge the fact that "external packages" remain under the control of their original maintainer/developer, as the first sentence : "Decisions on the content of external packages are solely in the authority of the package maintainer." already states.

Now, what happens if the package maintainer disagrees with some new orientation of Octave Forge, decides to develop it in a different direction, and thus stops making releases for OF?

Sure, this does not happen frequently with OF packages... But just for the sake of argument, as I see it, there are mainly two scenarios :

A) The package remains close to OF-compatible.  Someone from the OF community steps in and acts as "downstream" packager.  In this case the package can probably keep the same name (or perhaps be called octave-X explicitly).

B) The package diverges too much from OF requirements.  If the OF community wants to continue the development of an OF-package that will maintain no connection with the original project, this is the definition of a fork.  In this case, I believe that it is usual, as a minimal courtesy to the original dev/maintainer, and to avoid confusions, to use a different name.

The change of name can be made in such a way that the connection with the original project is not completely lost, so that users are not completely confused.  Think, e.g., of GNU Emacs -> XEmacs, NetBSD -> OpenBSD...

---- SHORT STORY / PROPOSAL ----

Since the first sentence already states that external packages remain under the control of their original dev/maintainer, I propose to remove the above sentence and simply write:

"If an external package X is removed from Octave Forge, previous releases of the package will remain available on Octave Forge."

and not discuss explicitly what happens next (scenarios A/B above, or any other variant).

@++
Julien