octave-maintainers
[Top][All Lists]
Advanced

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

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


From: Juan Pablo Carbajal
Subject: Re: Octave Forge: Package groups and properties defined, RFC.
Date: Thu, 9 Mar 2017 18:40:22 +0100

On Thu, Mar 9, 2017 at 1:54 PM, Julien Bect
<address@hidden> wrote:
> 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
Sounds much better to me. We can discuss problems and their solutions
when they arrive.
Thanks!



reply via email to

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