OF package maintainers please vote: Scope of OF?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OF package maintainers please vote: Scope of OF?

Olaf Till-2
Dear all,

there is no new person authorized to initialize a vote on Octave
Forge, but maybe you see the need for it, although I'm not the right
person to start it.

After a controversial discussion in the thread "...looking for a new
leader..." and a similarly controversial off-list discussion
initalized by Julien with Oliver and me, I think the first principal
issue to decide on is the following:

There are two different main concepts proposed for OF:

1. Simply maintain a list of packages, hosted elsewhere.

2. Continue to execercise some central control onto contained
   packages, making the package maintainers potentially bound to some
   majority- or admin-decisions.

For 2., two subvariants have been proposed:

2.1. In addition to the controled packages, maintain a list of
     independent packages, checked only for some formal structural
     conformance, which are primarily hosted elsewhere. OF contains
     'copies' of the external repositories, synchronized at least at
     release time. The package maintainer has exclusive control, if OF
     decides to fork the package, a different package name must be
     used.

2.2. Only the controled packages are contained in OF.

Of course, each choice requires that some person(s) is(are) willing to
maintain OF. If this is the case can only be seen later.

I think the OF package maintainers should decide on this. If you vote,
please indicate which OF package(s) you maintain.

Please indicate if you prefer 1. or 2..

In case of 2., please indicate if you prefer 2.1. or 2.2.


Feel free to give arguments for a choice (I'll do it also in my vote),
but please keep your vote at a prominent position in your e-mail. You
can also give arguments in a sparate e-mail before you vote, or if you
don't vote, or if you aren't a maintainer at all. In fact it could be
advisable to first read some arguments and to vote afterwards.

I hope this works... if it works, I think one week is enough for vote
collection. That is all very informal...

Olaf

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Olaf Till-2
OF packages maintained by me: optim, parallel, database, struct

my vote: 2.2.

Some argumentation:

On Tue, Jan 10, 2017 at 01:51:28PM +0100, Olaf Till wrote:

> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>    packages, making the package maintainers potentially bound to some
>    majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>      independent packages, checked only for some formal structural
>      conformance, which are primarily hosted elsewhere. OF contains
>      'copies' of the external repositories, synchronized at least at
>      release time. The package maintainer has exclusive control, if OF
>      decides to fork the package, a different package name must be
>      used.
>
> 2.2. Only the controled packages are contained in OF.
To my experience, some coordination between Octave and the packages is
beneficial, or even necessary. For coordination to be feasible, some
central control of packages is necessary. So 2.

Maintaining an additional list of external packages is additional
work. And maintaining the 'copies' of the external repositories is
even more work, with a potential for problems with synchronization. If
we promote external packages, we promote increasing this additional
work, and maybe even promote a status change of packages from
controled to external. A list of external packages can be hosted
elsewhere, but IMO does not belong to OF. So 2.2.

Olaf

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

jbect
In reply to this post by Olaf Till-2
Le 10/01/2017 à 13:51, Olaf Till a écrit :
Dear all,

there is no new person authorized to initialize a vote on Octave
Forge, but maybe you see the need for it, although I'm not the right
person to start it.

After a controversial discussion in the thread "...looking for a new
leader..." and a similarly controversial off-list discussion
initalized by Julien with Oliver and me, I think the first principal
issue to decide on is the following:

There are two different main concepts proposed for OF:

1. Simply maintain a list of packages, hosted elsewhere.

2. Continue to execercise some central control onto contained
   packages, making the package maintainers potentially bound to some
   majority- or admin-decisions.

For 2., two subvariants have been proposed:

2.1. In addition to the controled packages, maintain a list of
     independent packages, checked only for some formal structural
     conformance, which are primarily hosted elsewhere. OF contains
     'copies' of the external repositories, synchronized at least at
     release time. The package maintainer has exclusive control, if OF
     decides to fork the package, a different package name must be
     used.

2.2. Only the controled packages are contained in OF.

Of course, each choice requires that some person(s) is(are) willing to
maintain OF. If this is the case can only be seen later.

I think the OF package maintainers should decide on this. If you vote,
please indicate which OF package(s) you maintain.

Please indicate if you prefer 1. or 2..

In case of 2., please indicate if you prefer 2.1. or 2.2.


Feel free to give arguments for a choice (I'll do it also in my vote),
but please keep your vote at a prominent position in your e-mail. You
can also give arguments in a sparate e-mail before you vote, or if you
don't vote, or if you aren't a maintainer at all. In fact it could be
advisable to first read some arguments and to vote afterwards.

I hope this works... if it works, I think one week is enough for vote
collection. That is all very informal...

I am co-maintainer of the (externally hosted !) stk package, and (more or less implicitely) the maintainer of the generate_html and gsl packages.

I vote for option 2.1.

OF is already, and should remain IMHO, a mix of self- and externally hosted packages (with a set of rules to maintain coordination of the OF package ecosystem as a whole).

More on this in a separate thread.

@++
Julien

Reply | Threaded
Open this post in threaded view
|

Proposal for a team of admins

jbect
Le 10/01/2017 à 14:58, Julien Bect a écrit :
I am co-maintainer of the (externally hosted !) stk package, and (more or less implicitely) the maintainer of the generate_html and gsl packages.

I vote for option 2.1.

OF is already, and should remain IMHO, a mix of self- and externally hosted packages (with a set of rules to maintain coordination of the OF package ecosystem as a whole).

More on this in a separate thread.

I take this opportunity to propose myself as one member of an "admin team" that would continue and expand the work that was done by Carnë.

I give below some details about my view of OF, and especially the "controversial" (quoting Olaf) issue of externally-hosted packages.  What I propose is in the spirit of option 2.1 in Olaf's email. Should any of the other options prevail, I would obviously not be volunteer for becoming admin anymore.

Concerning decision making, when needed: I think that things should continue to work as they already do: most of the time, decisions are made by reaching a consensus through a discussion on the mailing list.  Whenever a clear consensus can not be reached, the admin team (currently, the "OF leader") makes a decision.

Which is why I believe that the admin team should have odd cardinality.  I propose a number of 3 or 5 people, depending the number of people that will declare themselves interested (and in agreement with what I propose).

Based on the view he expressed in- and off-list, I think that Oliver (Heimlich) shares a similar view of OF, and I hope he will confirm that he wants in.  Who else would be interested?

I think that one of the firsts tasks of the new admin team (beyond handling pending releases ;-) will be to clarify the roles, tasks and permissions in the OF project, which is a prerequisite for a better distribution of the workload among a larger set of people.

Feel free to use this thread to propose your participation or explain why you like/dislike what I propose (some arguments have already been given elsewhere).

@++
Julien

-----

Concerning self- versus externally hosted packages

As I said above, OF already is de facto, and should remain IMHO, a mix of two types of packages:

a) Some of them have their main development repository within the OF project on SourceForge: optim, signal, image, etc.  Any OF dev can participate in their development and has read/write permissions on the main repo.  This is the "central development model".

b) Some of them have their main repository somewhere else (my own stk package, for instance ; or the symbolic package that Colin McDonals develops on github).  For these "externally hosted packages", we keep a clone of the repo on SourceForge, which is synchronized from time to time (at least when releases happens). They have to obey all the rules of the OF project (structure of packages, no duplication of function names, reproduicibility of build from source, etc.).  But if someone wants to truly get involved in their development, he has to go and ask permission wherever the primary repo is (or make a clone and then issue a pull request, demanding on each particular package's workflow).

I am OK with this way of doing things, and would like to push things a little further in this direction.  More precisely, what I propose is:

1) to acknowledge officially this "dual model" on the OF website.  Knowing that they can keep some control over their package while becoming part of OF might make it more attractive for package developers to contribute.

2) to clarify which package follows which model (perhaps will we find that there is a need to distinguish between more than two types of packages, but two is OK for a start);

3) to clarify the rules that OF packages must satisfy and, ultimately, to provide a tool to check these rules. This should help people to provide "OF-compliant packages", and help the admin team (or a larger release team, if need be) in the release process. I'm thinking of something like "R CMD check --as-cran" in R, with the associated documentation (http://r-pkgs.had.co.nz/check.html).

Among the set of OF rules that all package must respect, there should be "coordination rules" such as not having duplicated function names across packages.  Such rules are meant to preserve the coherence of the OF package ecosystem as a whole.

-----

Concerning releases

I am not in favor of giving to *any* package maintainer permission to handle its own releases.

However, should the admin team prove to be too small to handle the releases in a reasonable time, I would propose to create a "release team", which would be composed of the admin team together with a set of confirmed package maintainers.

This team would have the necessary permission to handle releases, and share a set of rules on the wiki (and, ideally, some software tool to check at least some of them automatically).



Reply | Threaded
Open this post in threaded view
|

Re: Proposal for a team of admins

jbect
Le 10/01/2017 à 15:12, Julien Bect a écrit :
Le 10/01/2017 à 14:58, Julien Bect a écrit :
I am co-maintainer of the (externally hosted !) stk package, and (more or less implicitely) the maintainer of the generate_html and gsl packages.

I vote for option 2.1.

OF is already, and should remain IMHO, a mix of self- and externally hosted packages (with a set of rules to maintain coordination of the OF package ecosystem as a whole).

More on this in a separate thread.

I take this opportunity [...SNIP...]


Sorry for hijacking this thread, that was not my intention.  Please follow up here : http://octave.1599824.n4.nabble.com/Proposal-for-a-team-of-admins-td4681364.html.

Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Nir Krakauer-3
In reply to this post by jbect
I maintain the econometrics, mvn, and splines packages.

I vote for option 2.1
insofar as it corresponds to the status quo, which is working well enough, in my experience.

The problem for now is simply that we don't have someone who wants to have the whole administration burden, which we can solve by having multiple authorized people in a release team, specifying policies, and increasing automation (as we have been doing with makefiles).

Nir
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

PhilipNienhuis
In reply to this post by Olaf Till-2
Olaf Till-2 wrote
Dear all,

there is no new person authorized to initialize a vote on Octave
Forge, but maybe you see the need for it, although I'm not the right
person to start it.

After a controversial discussion in the thread "...looking for a new
leader..." and a similarly controversial off-list discussion
initalized by Julien with Oliver and me, I think the first principal
issue to decide on is the following:

There are two different main concepts proposed for OF:

1. Simply maintain a list of packages, hosted elsewhere.

2. Continue to execercise some central control onto contained
   packages, making the package maintainers potentially bound to some
   majority- or admin-decisions.

For 2., two subvariants have been proposed:

2.1. In addition to the controled packages, maintain a list of
     independent packages, checked only for some formal structural
     conformance, which are primarily hosted elsewhere. OF contains
     'copies' of the external repositories, synchronized at least at
     release time. The package maintainer has exclusive control, if OF
     decides to fork the package, a different package name must be
     used.

2.2. Only the controled packages are contained in OF.

Of course, each choice requires that some person(s) is(are) willing to
maintain OF. If this is the case can only be seen later.

I think the OF package maintainers should decide on this. If you vote,
please indicate which OF package(s) you maintain.

Please indicate if you prefer 1. or 2..

In case of 2., please indicate if you prefer 2.1. or 2.2.
(I'm maintainer of the io- and mapping packages and someday I might take over linear-algebra as well)
I have a very slight (55 % vs 45 %) preference for 2.2, because of the extra work involved with 2.1.
However if that extra work can be shifted towards the maintainers of those independent packages I think 2.1 my preference will change into 2.1.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

jbect
Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :
> I have a very slight (55 % vs 45 %) preference for 2.2, because of the
> extra
> work involved with 2.1. However if that extra work can be shifted
> towards the maintainers of those independent packages I think 2.1 my
> preference will change into 2.1.

Hi Philip,

Can you explain what this extra work is, exactly ?

@++
Julien


Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

José Luis García Pallero
In reply to this post by Olaf Till-2
Hi all,

Packages maintained by me: OctPROJ and OctCLIP

My vote: option 2.1

I think offering the possibility of accept independent packages could
attract more contributors

Best regards

2017-01-10 13:51 GMT+01:00 Olaf Till <[hidden email]>:

> Dear all,
>
> there is no new person authorized to initialize a vote on Octave
> Forge, but maybe you see the need for it, although I'm not the right
> person to start it.
>
> After a controversial discussion in the thread "...looking for a new
> leader..." and a similarly controversial off-list discussion
> initalized by Julien with Oliver and me, I think the first principal
> issue to decide on is the following:
>
> There are two different main concepts proposed for OF:
>
> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>    packages, making the package maintainers potentially bound to some
>    majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>      independent packages, checked only for some formal structural
>      conformance, which are primarily hosted elsewhere. OF contains
>      'copies' of the external repositories, synchronized at least at
>      release time. The package maintainer has exclusive control, if OF
>      decides to fork the package, a different package name must be
>      used.
>
> 2.2. Only the controled packages are contained in OF.
>
> Of course, each choice requires that some person(s) is(are) willing to
> maintain OF. If this is the case can only be seen later.
>
> I think the OF package maintainers should decide on this. If you vote,
> please indicate which OF package(s) you maintain.
>
> Please indicate if you prefer 1. or 2..
>
> In case of 2., please indicate if you prefer 2.1. or 2.2.
>
>
> Feel free to give arguments for a choice (I'll do it also in my vote),
> but please keep your vote at a prominent position in your e-mail. You
> can also give arguments in a sparate e-mail before you vote, or if you
> don't vote, or if you aren't a maintainer at all. In fact it could be
> advisable to first read some arguments and to vote afterwards.
>
> I hope this works... if it works, I think one week is enough for vote
> collection. That is all very informal...
>
> Olaf
>
> --
> public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net



--
*****************************************
José Luis García Pallero
[hidden email]
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

PhilipNienhuis
In reply to this post by jbect
Julien Bect-2 wrote
Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :
> I have a very slight (55 % vs 45 %) preference for 2.2, because of the
> extra
> work involved with 2.1. However if that extra work can be shifted
> towards the maintainers of those independent packages I think 2.1 my
> preference will change into 2.1.

Hi Philip,

Can you explain what this extra work is, exactly ?

@++
Julien
Julien Bect-2 wrote
Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :
> I have a very slight (55 % vs 45 %) preference for 2.2, because of the
> extra
> work involved with 2.1. However if that extra work can be shifted
> towards the maintainers of those independent packages I think 2.1 my
> preference will change into 2.1.

Hi Philip,

Can you explain what this extra work is, exactly ?
Not exactly, but I'm thinking of e.g., maintaining the infrastructure on octave.sf.net and in Octave itself (pkg -forge) needed for those external packages, keeping repos sync'ed, that sort of things.
All of it depending on how exactly "external packages" can be integrated with Octave-Forge and core Octave.

Sorry for slightly hijacking this thread, but I I'd be in favor of having "officially" supported stable package releases on OF vetted by some OF team and all; but on each individual package page next to the download buttons for stable and previous releases an option (another download button?) for downloading unstable (bleeding edge) incl. mere bug fix package releases. The latter to be uploaded directly by package maintainers themselves w/o much action by the OF team. That DL button of course decorated by the probably unavoidably required warnings.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Juan Pablo Carbajal-2
On Wed, Jan 11, 2017 at 10:23 AM, PhilipNienhuis <[hidden email]> wrote:

> Julien Bect-2 wrote
>> Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :
>>> I have a very slight (55 % vs 45 %) preference for 2.2, because of the
>>> extra
>>> work involved with 2.1. However if that extra work can be shifted
>>> towards the maintainers of those independent packages I think 2.1 my
>>> preference will change into 2.1.
>>
>> Hi Philip,
>>
>> Can you explain what this extra work is, exactly ?
>>
>> @++
>> Julien
>
>
> Julien Bect-2 wrote
>> Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :
>>> I have a very slight (55 % vs 45 %) preference for 2.2, because of the
>>> extra
>>> work involved with 2.1. However if that extra work can be shifted
>>> towards the maintainers of those independent packages I think 2.1 my
>>> preference will change into 2.1.
>>
>> Hi Philip,
>>
>> Can you explain what this extra work is, exactly ?
>
> Not exactly, but I'm thinking of e.g., maintaining the infrastructure on
> octave.sf.net and in Octave itself (pkg -forge) needed for those external
> packages, keeping repos sync'ed, that sort of things.
> All of it depending on how exactly "external packages" can be integrated
> with Octave-Forge and core Octave.
>
> Sorry for slightly hijacking this thread, but I I'd be in favor of having
> "officially" supported stable package releases on OF vetted by some OF team
> and all; but on each individual package page next to the download buttons
> for stable and previous releases an option (another download button?) for
> downloading unstable (bleeding edge) incl. mere bug fix package releases.
> The latter to be uploaded directly by package maintainers themselves w/o
> much action by the OF team. That DL button of course decorated by the
> probably unavoidably required warnings.
>
> Philip
>
>
>
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/OF-package-maintainers-please-vote-Scope-of-OF-tp4681358p4681380.html
> Sent from the Octave - Maintainers mailing list archive at Nabble.com.
>
Hi,

I maintain geometry and help with many other packages when the
possibility appears. I have several "external packages" so I really
support option 2.1

Cheers

Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

kingcrimson
In reply to this post by Olaf Till-2
Hi,

On 10 Jan 2017, at 13:51, Olaf Till <[hidden email]> wrote:

> There are two different main concepts proposed for OF:
>
> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>   packages, making the package maintainers potentially bound to some
>   majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>     independent packages, checked only for some formal structural
>     conformance, which are primarily hosted elsewhere. OF contains
>     'copies' of the external repositories, synchronized at least at
>     release time. The package maintainer has exclusive control, if OF
>     decides to fork the package, a different package name must be
>     used.
>
> 2.2. Only the controled packages are contained in OF.

I am under the impression that some of my previous comments on this thread have
been misinterpreted as suggesting version 1.

Actually what I am advocating is something closer to 2.1/2.2:

Packages that are maintained in OF should be controlled and maintained cooperatively,
but we should also maintain a list of packages that are not.

I do volunteer to help with maintainance of both lists.

> If you vote, please indicate which OF package(s) you maintain.


I am (co-)maintainer of:

bim
msh
fpl
ocs
odepkg
mpi
nurbs
secsXd

and of a few more packages that are not part of OF but could be part of the "independent packages" list.

c.





Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

jbect
Le 12/01/2017 à 12:27, c. a écrit :

> Hi,
>
> On 10 Jan 2017, at 13:51, Olaf Till <[hidden email]> wrote:
>
>> There are two different main concepts proposed for OF:
>>
>> 1. Simply maintain a list of packages, hosted elsewhere.
>>
>> 2. Continue to execercise some central control onto contained
>>    packages, making the package maintainers potentially bound to some
>>    majority- or admin-decisions.
>>
>> For 2., two subvariants have been proposed:
>>
>> 2.1. In addition to the controled packages, maintain a list of
>>      independent packages, checked only for some formal structural
>>      conformance, which are primarily hosted elsewhere. OF contains
>>      'copies' of the external repositories, synchronized at least at
>>      release time. The package maintainer has exclusive control, if OF
>>      decides to fork the package, a different package name must be
>>      used.
>>
>> 2.2. Only the controled packages are contained in OF.
> I am under the impression that some of my previous comments on this thread have
> been misinterpreted as suggesting version 1.

I believe it was...

> Actually what I am advocating is something closer to 2.1/2.2:
>
> Packages that are maintained in OF should be controlled and maintained cooperatively,
> but we should also maintain a list of packages that are not.

I'm not sure I understand your position correctly.

Does it mean that externally-hosted packages (such as ltfat, stk,
symbolic, etc.) would not be distributed as "OF packages" anymore, but
would only appear on this other list you're talking about?


Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

kingcrimson

On 12 Jan 2017, at 13:36, Julien Bect <[hidden email]> wrote:

> Does it mean that externally-hosted packages (such as ltfat, stk, symbolic, etc.) would not be distributed as "OF packages" anymore, but would only appear on this other list you're talking about?

No, I am proposing to add an additional cathegory for packages that are really separate from Octave Forge.
c.
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

kingcrimson

On 12 Jan 2017, at 13:50, c. <[hidden email]> wrote:

>
> On 12 Jan 2017, at 13:36, Julien Bect <[hidden email]> wrote:
>
>> Does it mean that externally-hosted packages (such as ltfat, stk, symbolic, etc.) would not be distributed as "OF packages" anymore, but would only appear on this other list you're talking about?
>
> No, I am proposing to add an additional cathegory for packages that are really separate from Octave Forge.

BUT, I do think that, if given the option, many maintainers of "EHP" would prefer to move their ackage in the new cathegory.
They should not be forced to do so, though.

> c.

c.



Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Nir Krakauer-3
> No, I am proposing to add an additional category for packages that are really separate from Octave Forge.

For that, it would be simplest just to link to the existing list at http://wiki.octave.org/Packages#Other_Packages
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Oliver Heimlich
In reply to this post by Olaf Till-2
On 10.01.2017 13:51, Olaf Till wrote:

> Dear all,
>
> there is no new person authorized to initialize a vote on Octave
> Forge, but maybe you see the need for it, although I'm not the right
> person to start it.
>
> After a controversial discussion in the thread "...looking for a new
> leader..." and a similarly controversial off-list discussion
> initalized by Julien with Oliver and me, I think the first principal
> issue to decide on is the following:
>
> There are two different main concepts proposed for OF:
>
> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>    packages, making the package maintainers potentially bound to some
>    majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>      independent packages, checked only for some formal structural
>      conformance, which are primarily hosted elsewhere. OF contains
>      'copies' of the external repositories, synchronized at least at
>      release time. The package maintainer has exclusive control, if OF
>      decides to fork the package, a different package name must be
>      used.
>
> 2.2. Only the controled packages are contained in OF.
>
I maintain the following OF packages: interval, strings, and vibes. The
last-mentioned is developed (and released) externally.

My opinion is that we should target on concept 2.2 for OF. Reasoning: I
want to keep the concept of commonly developed packages, helping each
other to make high quality releases, and stay in touch with Octave core
during development, which lowers the entry barrier for people like me. I
gave several reasons for this in my mail dated January 9 (01:39 CET).

As a consequence, we have to “get rid” of externally developed packages
on OF. It's a matter of respect to developers who wish to be free to
make releases on their own. We should support this, but should not burn
out ourselves doing so. Also I believe we have no right to restrict
others who don't want to agree with the rules dictated by OF.

Dropping externally developed packages from OF immediately would be a
bad service to the community. So I suggest the following plan:

- Keep status quo (concept 2.1) for today with a new leader (and
possibly team of admins) for OF.
- Develop a package database, where registered users may enter
meta-information about their just released external packages (cf.
concept 1). It shall be possible to enter OF packages into this
database, and OF packages might get flagged (“seal of quality”).
- The database shall be free for anyone to enter their packages with a
minimum amount of criteria to be fulfilled (complete meta-data including
maintainer contact information, download URL and documentation URL, no
duplicate package names). Any quality checks (if any at all) shall be
automated and there shall be no need for approval of uploads (though the
admin team might take down dangerous/illegal entries once they get to
know them). The database should not be hosted on OF and be maintained by
a different team. The database shall contain only meta information, in
particular no file hosting or repository hosting will be included and
must be set up by the package maintainers elsewhere (Github, Bitbucket,
Savannah.nongnu.org, SourceForge).
- Once the database is up and running, Octave core should get a “pkg
install -fancynewdatabase <packagename>” switch, lookup the URL of the
package tarball, download the package from an external URL and try to
install the package.
- Then we can deprecate any externally developed packages on OF and no
longer accept releases for them until the maintainer decides to put her
package under control of OF again.
- Improve the package database with automated checking tools and more
features. A lot of these might come as a byproduct from a fresh team for
OF (see first bullet), who have to agree on some rules and can formalize
these in formal checks.

AFAIC we have at least Olaf, me, and maybe Philip(?) and CdF(?) would
support this plan and take care of OF with concept 2.2. Who else?

Nobody has voted for option 1 yet, so I see a problem that we are
missing the new package database (meta repository), which is required to
get away from 2.1. Maybe we can build on top of some existing software
(like a tailored version of the FSF free software directory).

Best
Oliver


signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

PhilipNienhuis
Oliver Heimlich wrote
On 10.01.2017 13:51, Olaf Till wrote:
> Dear all,
>
> there is no new person authorized to initialize a vote on Octave
> Forge, but maybe you see the need for it, although I'm not the right
> person to start it.
>
> After a controversial discussion in the thread "...looking for a new
> leader..." and a similarly controversial off-list discussion
> initalized by Julien with Oliver and me, I think the first principal
> issue to decide on is the following:
>
> There are two different main concepts proposed for OF:
>
> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>    packages, making the package maintainers potentially bound to some
>    majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>      independent packages, checked only for some formal structural
>      conformance, which are primarily hosted elsewhere. OF contains
>      'copies' of the external repositories, synchronized at least at
>      release time. The package maintainer has exclusive control, if OF
>      decides to fork the package, a different package name must be
>      used.
>
> 2.2. Only the controled packages are contained in OF.
>

I maintain the following OF packages: interval, strings, and vibes. The
last-mentioned is developed (and released) externally.

My opinion is that we should target on concept 2.2 for OF. Reasoning: I
want to keep the concept of commonly developed packages, helping each
other to make high quality releases, and stay in touch with Octave core
during development, which lowers the entry barrier for people like me. I
gave several reasons for this in my mail dated January 9 (01:39 CET).

As a consequence, we have to “get rid” of externally developed packages
on OF. It's a matter of respect to developers who wish to be free to
make releases on their own. We should support this, but should not burn
out ourselves doing so. Also I believe we have no right to restrict
others who don't want to agree with the rules dictated by OF.

Dropping externally developed packages from OF immediately would be a
bad service to the community. So I suggest the following plan:

- Keep status quo (concept 2.1) for today with a new leader (and
possibly team of admins) for OF.
- Develop a package database, where registered users may enter
meta-information about their just released external packages (cf.
concept 1). It shall be possible to enter OF packages into this
database, and OF packages might get flagged (“seal of quality”).
- The database shall be free for anyone to enter their packages with a
minimum amount of criteria to be fulfilled (complete meta-data including
maintainer contact information, download URL and documentation URL, no
duplicate package names). Any quality checks (if any at all) shall be
automated and there shall be no need for approval of uploads (though the
admin team might take down dangerous/illegal entries once they get to
know them). The database should not be hosted on OF and be maintained by
a different team. The database shall contain only meta information, in
particular no file hosting or repository hosting will be included and
must be set up by the package maintainers elsewhere (Github, Bitbucket,
Savannah.nongnu.org, SourceForge).
- Once the database is up and running, Octave core should get a “pkg
install -fancynewdatabase <packagename>” switch, lookup the URL of the
package tarball, download the package from an external URL and try to
install the package.
- Then we can deprecate any externally developed packages on OF and no
longer accept releases for them until the maintainer decides to put her
package under control of OF again.
- Improve the package database with automated checking tools and more
features. A lot of these might come as a byproduct from a fresh team for
OF (see first bullet), who have to agree on some rules and can formalize
these in formal checks.

AFAIC we have at least Olaf, me, and maybe Philip(?) and CdF(?) would
support this plan and take care of OF with concept 2.2. Who else?
To me it looks like something between 2.1 and 2.2.

I like the idea that there are more or less "official" OF packages that (1) feature some quality control, (2) to the outside world suggest that they belong, or relate closely, to Octave, and (3) feature, or suggest, some sort of continuity: if the maintainer goes AWOL some other maintainer can easily take over (at least in theory).  
So OF packages have the aura of being closer tied to Octave than to its creator / its maintainer du jour.

Such packages should (IMO) at least have a repo on OF (to guarantee the continuity).  Where the actual development takes place is irrelevant, as long as there's an OF repo synced with the external repo.

I have no strong opinions further than that..

Philip
Reply | Threaded
Open this post in threaded view
|

Re: OF package maintainers please vote: Scope of OF?

Sebastian Schöps
In reply to this post by Oliver Heimlich
Oliver Heimlich wrote
> 1. Simply maintain a list of packages, hosted elsewhere.
Nobody has voted for option 1 yet, so I see a problem that we are
missing the new package database (meta repository), which is required to
get away from 2.1. Maybe we can build on top of some existing software
(like a tailored version of the FSF free software directory).
I was in favour of 1 at a time nobody volunteered for maintaining OF (including me). Now, since we have competent and motivated people for the job (thank you guys), I do not see why we should not continue with OF.

However, moving away from sourceforge would be great as the collaboration among among projects is way better at gitlab, github or bitbucket (but this is another topic...).

Olaf Till-2 wrote
2.2. Only the controled packages are contained in OF.
I do not see why we need to pull the external packages into OF since this might require more effort for both the OF maintainers and package maintainer. It might increase the quality but not all package maintainers are looking for this "service".
I vote for 2.2 instead 2.1. However, then we need an easy installation from 3rd party sites e.g. by

(a) url (pkg install -url http://somewhere/package") or
(b) package name ("pkg install -external name").

Known third party packages could be maintained as a xml-file in the OF repository (name, author, version, url, possibly description).

Sebastian

P.S.: Carlo, Jacopo and I have already started maintaining odepkg at bitbucket. We plan to push releases to OF.
Reply | Threaded
Open this post in threaded view
|

RE: OF package maintainers please vote: Scope of OF?

John Donoghue-3
In reply to this post by Olaf Till-2
> Message: 1
> Date: Tue, 10 Jan 2017 13:51:28 +0100
> From: Olaf Till <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Subject: OF package maintainers please vote: Scope of OF?
> Message-ID: <20170110125128.GA32329@till>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear all,
>
> there is no new person authorized to initialize a vote on Octave Forge,
but
> maybe you see the need for it, although I'm not the right person to start
it.
>
> After a controversial discussion in the thread "...looking for a new
leader..."
> and a similarly controversial off-list discussion initalized by Julien
with Oliver

> and me, I think the first principal issue to decide on is the following:
>
> There are two different main concepts proposed for OF:
>
> 1. Simply maintain a list of packages, hosted elsewhere.
>
> 2. Continue to execercise some central control onto contained
>    packages, making the package maintainers potentially bound to some
>    majority- or admin-decisions.
>
> For 2., two subvariants have been proposed:
>
> 2.1. In addition to the controled packages, maintain a list of
>      independent packages, checked only for some formal structural
>      conformance, which are primarily hosted elsewhere. OF contains
>      'copies' of the external repositories, synchronized at least at
>      release time. The package maintainer has exclusive control, if OF
>      decides to fork the package, a different package name must be
>      used.
>
> 2.2. Only the controled packages are contained in OF.
>
> Of course, each choice requires that some person(s) is(are) willing to
> maintain OF. If this is the case can only be seen later.
>
> I think the OF package maintainers should decide on this. If you vote,
please
> indicate which OF package(s) you maintain.
>
> Please indicate if you prefer 1. or 2..
>
> In case of 2., please indicate if you prefer 2.1. or 2.2.
>
>
> Feel free to give arguments for a choice (I'll do it also in my vote), but
please
> keep your vote at a prominent position in your e-mail. You can also give
> arguments in a sparate e-mail before you vote, or if you don't vote, or if
you
> aren't a maintainer at all. In fact it could be advisable to first read
some
> arguments and to vote afterwards.
>
> I hope this works... if it works, I think one week is enough for vote
collection.
> That is all very informal...
>
> Olaf
>

Maintainer for windows and zeromq package

2.1

I can also volunteer my help on OF if neede


12