On Sun, Jan 8, 2017 at 7:39 PM, Oliver Heimlich <address@hidden> wrote:
On 08.01.2017 22:33, Olaf Till wrote:
> On Sun, Jan 08, 2017 at 08:41:55PM +0100, Julien Bect wrote:
>> Le 08/01/2017 à 17:31, c. a écrit :
>>> On 8 Jan 2017, at 16:59, Julien Bect <address@hiddenfr > wrote:
>>>> My opinion about the second option (transforming OF into a collection of externally hosted repos and/or tarballs) : this would be very drastic change of philosophy,
>>> I think this is one moment where we have the opportunity to make "drastic" changes ...
>>
>> Sure, it is.
>>
>> But this is in my opinion a case where a slightly more formalized decisional
>> structure could help. Because, here, once all the arguments will have been
>> exposed in this (or other) threads, who is supposed to make a decision?
>
> It would be good if we had a voting system. But as for the above
> question, I doubt that it is a matter of formal decision at all.
>
> The question is not whether to publish a list of known
> packages. Everybody is free to do that. How this is best done is a
> separate topic.
>
> The question is rather whether or not the concept of a central web
> site with some coordinated consistency of packages should be given up.
It's an obvious question nowadays, after the rise of Github. It has
never been easier for an individual person to develop and release your
own software. Downstream distributors (and even users) may pick up your
package, and so should Octave-Forge (or any other list of known packages)?
I find it invaluable:
- As a new Forger your first code drafts and releases get reviewed
(mailing list and release tickets), which lowers the entry barrier, and
gives you valuable information to start your project,
- Because you are immediately part of a bigger project, new packages
gain broader attention,
- You can use the bug and patch trackers from GNU Octave. Yes, the
savannah web interface is not state of the art. And yes, the package
maintainer can't even change the status of her bugs. However, there is
much less communication overhead with “upstream” (=Octave) and you can
get attention and hints from core developers easily,
- You can follow activity from other package developers in the project
activity tracker [1] and learn from them,
- Once you loose interest in your package, it is more likely to be
picked up by somebody else,
- Core developers can grep through package's code in one place, and
packages can be made ready for a new Octave release,
- There is an edited list of reasonable package names – although this
could always be improved, “miscellaneous” I am looking in your direction ;-)
- Users can address package related questions in a single help mailing list.
So, I'd clearly favor to keep the central development model.
The main features of Octave-Forge currently are:
1. a central place for documentation of packages
2. you can install packages with “pkg install -forge”
3. it is very likely that the packages work in a recent version of Octave
The first point can easily be achieved by compiling a list of packages
and hosting their documentation anywhere. For the second point I would
already presume that (at least) you have a central naming scheme, with
categorization of maintained and unmaintained packages. For the last
point I don't know a working solution except to review the releases as
it has been done in the past. Yes, you could create verification tools
and such. But these can't replace a good advice from the experienced
developer to the less experienced. Not everybody has a degree in
computer science and I guess most problems inside release tickets are
related to version control and packaging. I'd say people, who write
Octave functions for a package, know what they do. Thus, formal errors
with making a release are the most likely to occur.
We must face the fact that we don't have a lot of infrastructure (build
/ verification tools) and manpower to maintain the website. Carnë has
devoted his time to review and upload all the package releases, but
there was no progress otherwise recently and Carnë's time obviously is
limited. To nominate a new leader would hopefully stimulate development
of OF (pick up new ideas, inspire people who work to implement them) and
result in a team where the maintenance burden can be divided.
I'm fine with how things went for package maintainers in the past.
However, I'm not fine with the situation where a single person has to do
all dull work. I am eager to help out with whatever the plans are for OF
after this discussion.
Oliver
[1] https://sourceforge.net/p/octave/activity/
I have a different idea.
The list of pkgs is very long.
I think we should separate them int 2 or 3 different groups.
Group 1:
All the general pkgs that an undergrad Engineering student would use.
Signal Statistics Control Symbolic etc. (about 10 pkgs)
Group 2:
All the pkgs that are more for grad work:
Dicom Fem-fenics Msh Mpi etc
Group 3:
???
If we separated them into these groups then we can handle each group in a different way.
Group 1 could be managed much like we have been doing.
Group 2 could be maintained and released by an individual.
Group 3 ?
As it is there are too many, and with so different skills needed, that the job got too big.
Just my 2C worth
Doug