Project Infrastructure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Project Infrastructure

John W. Eaton
Administrator
At OctConf, a few of us discussed project infrastructure and what we
could do to consolidate some of it and maybe make things easier to
manage, especially for the group web pages that must currently be
uploaded using CVS(!).

I think some people also wanted to know just what resources we are
using, who can manage them, and so on.  My best attempt to answer that
question is here:

   http://wiki.octave.org/Project_Infrastructure

Could someone fill in more details about Octave Forge?

Some conclusions from our discussion, as I recall them:

   * no one likes the savannah trackers but moving bug reports to
another system will be a lot of work

   * we need a better way to handle patches that will allow more
detailed and transparent code review

   * uploading web pages with CVS is ridiculous and must be fixed

   * it's confusing to have our infrastructure spread over so many
different systems (I'll try to add some info to the wiki page about why
things are currently distributed the way they are)different )

   * we probably won't be able to fix all of this at once, but it would
be nice to at least eliminate the problem of uploading web pages with CVS


So, the one action item that we agreed to start with is

   ==> Move the web pages from gnu.org back to octave.org where we can
at least manage them however we choose.

I think the master version should remain in Mercurial.

What is the best way to deal with publishing?  I can imagine that it is
best to manage editing and publishing separately, but maybe that isn't
really important?  Should the pages be published when they are committed
to the hg archive at octave.org?  Now that we are using Jekyll, should
the processing steps be done locally or on the web hosting system?

As a related issue, maybe this would also be a good time to think about
merging the Octave Forge site with the Octave web site?  Would that help
users?  Would it be any easier to manage if we did this?

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Project Infrastructure

Olaf Till-2
On Wed, Mar 29, 2017 at 12:14:11PM -0400, John W. Eaton wrote:
> Could someone fill in more details about Octave Forge?

Done.

> As a related issue, maybe this would also be a good time to think about
> merging the Octave Forge site with the Octave web site?  Would that help
> users?  Would it be any easier to manage if we did this?

Surely dreamhost doesn't provide multiple hg and git repositories,
repository access regulations, and release trackers?

So, since the repository and release infrastructure would have to
remain on sourceforge anyway(?), I currently don't see an advantage in
moving the website to dreamhost. It's just another commercial hosting
provider, with probably a different specific set of flaws. It would
only be a physical (on hard disk) vicinity to Octave, apart from maybe
a name change of the website to something without 'sourceforge' in it.

Maybe I see it wrong.

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
|  
Report Content as Inappropriate

Re: Project Infrastructure

John W. Eaton
Administrator
On 03/29/2017 02:10 PM, Olaf Till wrote:

> On Wed, Mar 29, 2017 at 12:14:11PM -0400, John W. Eaton wrote:
>> Could someone fill in more details about Octave Forge?
>
> Done.
>
>> As a related issue, maybe this would also be a good time to think about
>> merging the Octave Forge site with the Octave web site?  Would that help
>> users?  Would it be any easier to manage if we did this?
>
> Surely dreamhost doesn't provide multiple hg and git repositories,
> repository access regulations, and release trackers?

No, though they could probably be installed.  But anyway, I'm not
proposing to move all infrastructure to dreamhost.

> So, since the repository and release infrastructure would have to
> remain on sourceforge anyway(?), I currently don't see an advantage in
> moving the website to dreamhost. It's just another commercial hosting
> provider, with probably a different specific set of flaws. It would
> only be a physical (on hard disk) vicinity to Octave, apart from maybe
> a name change of the website to something without 'sourceforge' in it.

It's not only about where it is hosted, or whether they are hosted and
developed together, but about whether having what appears to be a single
web site will provide a better experience for users.  People used to be
constantly confused by having both Octave and Octave Forge projects.
Were they the same?  Different?  Was Octave Forge a different version of
Octave?  Why aren't the Octave sources on Octave Forge?  Why can't I
find packages on the Octave site.  Etc.

For the users, I think it would be good if we had a single web site,
where everything appears under the same domain name.

jwe


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Project Infrastructure

Mike Miller-4
On Wed, Mar 29, 2017 at 14:50:59 -0400, John W. Eaton wrote:

> It's not only about where it is hosted, or whether they are hosted and
> developed together, but about whether having what appears to be a single web
> site will provide a better experience for users.  People used to be
> constantly confused by having both Octave and Octave Forge projects. Were
> they the same?  Different?  Was Octave Forge a different version of Octave?
> Why aren't the Octave sources on Octave Forge?  Why can't I find packages on
> the Octave site.  Etc.
>
> For the users, I think it would be good if we had a single web site, where
> everything appears under the same domain name.

Maybe, maybe not. I haven't been following closely, but the Forge
project is working through its own reorganization. It may end up being
more than one collection of packages, and some package maintainers may
want to be more closely affiliated with Octave than others, some may
value autonomy and differentiation more than others.

I think it might be advantageous to users to have a unified web
interface for Octave and packages, but that doesn't necessarily mean
unified hosting, either for docs or code or both.

Also remember that there are some things hosted on the Forge project
that GNU Octave may not be able to or willing to host, such as
MSVC-built Octave binaries, macOS binaries, etc.

--
mike

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Project Infrastructure

Olaf Till-2
In reply to this post by John W. Eaton
On Wed, Mar 29, 2017 at 02:50:59PM -0400, John W. Eaton wrote:

> It's not only about where it is hosted, or whether they are hosted and
> developed together, but about whether having what appears to be a single web
> site will provide a better experience for users.  People used to be
> constantly confused by having both Octave and Octave Forge projects. Were
> they the same?  Different?  Was Octave Forge a different version of Octave?
> Why aren't the Octave sources on Octave Forge?  Why can't I find packages on
> the Octave site.  Etc.
>
> For the users, I think it would be good if we had a single web site, where
> everything appears under the same domain name.
I can't imagine that the domain name alone will be decisive. It is
common that sites have different domain names for different tasks.

I think what you actually propose is dropping the web identity 'Octave
Forge'? -- Pracically meaning, among others, that its home page would
disappear, and only some of its subpages would survive in a changed
form, being linked to directly from the Octave homepage or a
'packages' subpage?

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
|  
Report Content as Inappropriate

Re: Project Infrastructure

siko1056
John W. Eaton wrote
My best attempt to answer that
question is here:

   http://wiki.octave.org/Project_Infrastructure
Thank you very much for this jwe, that is exactly what I was looking for! I added some URLs to get the full picture without looking up oneself.

John W. Eaton wrote
   * no one likes the savannah trackers but moving bug reports to
another system will be a lot of work

   * we need a better way to handle patches that will allow more
detailed and transparent code review
I agree, Savannah is free (libre), but hasn't been updated for about 10 years [https://en.wikipedia.org/wiki/Savane_(software)] but little patched for security issues [http://git.savannah.nongnu.org/cgit/savane-cleanup.git/log/] and I don't see that this will change in a closer future. Compared to other free (beer) project hosting sites [sourceforge, bitbucket, gitlab, github, ...] that also encourage free software development, is simply not state of the art. Actually everything can be hosted there [https://bitbucket.org/mtmiller/octave/commits/all] (sorry Mike for "stealing" your repo) and we can make use of "pull-request" instead of Savannahs patch tracker and might become more responsive to user requests.

All we have to consider is to stay independent. Means, we should clone the hg-repo to savannah and hg.octave.org, and should be able to export/save the bug reports and pull requests, if the modern hosting service decides to become less free or alike. Moving everything from Savannah is not required from my point of view. We can simply make a cut, new issues are reported at the new service and old ones are handled at Savannah.

But this discussion will come up at every OctConf and I agree to jwe, that there are far lower hanging fruits to grab first.

Olaf Till-2 wrote
John W. Eaton wrote
   * it's confusing to have our infrastructure spread over so many different systems

[...]

It's not only about where it is hosted, or whether they are hosted and
developed together, but about whether having what appears to be a single web
site will provide a better experience for users.  People used to be
constantly confused by having both Octave and Octave Forge projects. Were
they the same?  Different?  Was Octave Forge a different version of Octave?
Why aren't the Octave sources on Octave Forge?  Why can't I find packages on
the Octave site.  Etc.
 
For the users, I think it would be good if we had a single web site, where
everything appears under the same domain name.
Mike Miller wrote
Maybe, maybe not. I haven't been following closely, but the Forge
project is working through its own reorganization. It may end up being
more than one collection of packages, and some package maintainers may
want to be more closely affiliated with Octave than others, some may
value autonomy and differentiation more than others.

I think it might be advantageous to users to have a unified web
interface for Octave and packages, but that doesn't necessarily mean
unified hosting, either for docs or code or both.
I can't imagine that the domain name alone will be decisive. It is
common that sites have different domain names for different tasks.

I think what you actually propose is dropping the web identity 'Octave
Forge'? -- Pracically meaning, among others, that its home page would
disappear, and only some of its subpages would survive in a changed
form, being linked to directly from the Octave homepage or a
'packages' subpage?

Olaf
I think Octave forge should remain an entity, especially now, as there happened such a great change in it's administration.

The point is, we're wasting a lot of energy in duplicating effort. There is a wiki, there is a static website, and there is an Octave forge website, all with a different layout and web-address. As a new user it took me some time to see through all of this. All of them have great features (wiki is dynamic), forge has a great function reference (https://octave.sourceforge.io/docs.php why should this feature not be available to a "standard" Octave user, not knowing about Octave forge and only the manual https://www.gnu.org/software/octave/doc/interpreter/Function-Index.html?).

I would come to the conclusion, that octave.org should be only more or less a landing page, redirecting to all of the great efforts of the Octave project, like currently the wiki does (but I find it too overloaded). Most of the octave.org subpages would perfectly fit into the wiki, if it was possible to restrict writing to them to certain admins only.

Kai.
Loading...