Release system / web page generation

[Søren Hauberg]

Hi All

For waaay too long I've been working on changing the release system.
Well, "working" isn't really the right word as I haven't actually done
much work due to lack of time.

To those that don't remember, the reason why we don't allow individual
package maintainers to release their packages when it suits them, is
that the HTML generation is from the old monolithic days. This means
that the current system needs to generate the HTML pages for _all_
packages at once.

Carlo and myself have been working on changing this, such that HTML
pages can be generated for individual packages. The code for this is
available in the 'generate_html' package.

For a long time essential parts of this code has been incomplete, but
I've recently been taking a stab at this once more. You can check out
the results at

  http://octave.sf.net/test

This test site is only showing three packages (the ones I happened to
have installed). It is also missing a bunch of stuff:

  * Doxygen documentation.
  * The Octave manual.
  * The help texts of all functions that come with core Octave.

Do you have any comments on this page? I've made some changes here and
there to simplify the HTML generation; I hope I haven't changed anything
that people cared about (if so, speak up).

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Thomas Treichl]

Søren Hauberg schrieb:

> Hi All
>
> For waaay too long I've been working on changing the release system.
> Well, "working" isn't really the right word as I haven't actually done
> much work due to lack of time.
>
> To those that don't remember, the reason why we don't allow individual
> package maintainers to release their packages when it suits them, is
> that the HTML generation is from the old monolithic days. This means
> that the current system needs to generate the HTML pages for _all_
> packages at once.
>
> Carlo and myself have been working on changing this, such that HTML
> pages can be generated for individual packages. The code for this is
> available in the 'generate_html' package.
>
> For a long time essential parts of this code has been incomplete, but
> I've recently been taking a stab at this once more. You can check out
> the results at
>
>   http://octave.sf.net/test
>
> This test site is only showing three packages (the ones I happened to
> have installed). It is also missing a bunch of stuff:
>
>   * Doxygen documentation.
>   * The Octave manual.
>   * The help texts of all functions that come with core Octave.
>
> Do you have any comments on this page? I've made some changes here and
> there to simplify the HTML generation; I hope I haven't changed anything
> that people cared about (if so, speak up).
>
> Søren

Just have to say, very, very nice pages! That few icons on the website make it
even look more friendly. I'll try that generate_html* package myself, soon. Well
done.

Ok, some questions:

  - What do you mean by Doxygen documentation? Is it the Coda script?

  - My opinion is that the Octave manual should _not_ be part of OF, but
    there should be a link to the website of the Octave project where the
    manual can be found.

  - The help texts of all functions that come with the core Octave should be
    part of the GNU Octave website, not of the OF website, too. Maybe it is
    useful to create another link to the Octave website then.

Meanwhile best regards

   Thomas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 11:15 +0200, skrev Thomas Treichl:
> Ok, some questions:
>
>   - What do you mean by Doxygen documentation? Is it the Coda script?

No, I mean class descriptions generated by doxygen. We have these on the
current site at

  http://octave.sourceforge.net/doxygen/html/index.html

>   - My opinion is that the Octave manual should _not_ be part of OF, but
>     there should be a link to the website of the Octave project where the
>     manual can be found.

I both agree and disagree. I think it is nice to have all the
documentation available in one place where everything looks the same. If
we link to www.octave.org the user will get something that looks
different from Octave-Forge. I think that will just create confusion.

That being said, I think it is silly to duplicate the documentation on
multible sites. Personally, I'd like to merge www.octave.org and
octave.sf.net into one site, so there is less to maintain.

>   - The help texts of all functions that come with the core Octave should be
>     part of the GNU Octave website, not of the OF website, too. Maybe it is
>     useful to create another link to the Octave website then.

The problem is the 'See also's in the function help texts. If you look
at a help text for a function from a package that references some
function in core Octave, where should you go when you click on said
link? If it'll be confusing if you get sent of to www.octave.org.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Paul Sundvall]

Nice work!
I appreciate your efforts towards a per-package release system. The
layout is nice and the only thing that I think is wrong is the title of
the page, which I guess should be "Octave package: Image" and not
"Function Referene: image".
The new layout works fine as is, in my opinion. I like the coloured boxes.

I have some suggestions (see it as a wishlist or starting point for
discussion!)

*does the package name has to be repeated in the yellow box as well as
on the top of the page?

*can the green box display the latest version number, and have a smaller
text below with a link to older releases? (if there are is such
functionality). If there is something broken in a package version, I
think users will appreciate being able to easily find an older version.

*is it desirable/possible to have links to external packaging of the
octave packages? Like pointers to debian package, macports etc. C.f.
http://www.macports.org/ports.php?by=name&substr=octave-image and
http://packages.debian.org/sv/source/lenny/octave-image

*should there be a link to bugs for the package? For now, it can lead to
the bugs page http://octave.sourceforge.net/bugs.html but there will
maybe be a bug tracking system for the octave packages in the future.

*should we include a pointer to the repository? something like
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/image/

paul

17 okt 2009 kl. 23.58 skrev Søren Hauberg:

> Hi All
>
> For waaay too long I've been working on changing the release system.
> Well, "working" isn't really the right word as I haven't actually done
> much work due to lack of time.
>
> To those that don't remember, the reason why we don't allow individual
> package maintainers to release their packages when it suits them, is
> that the HTML generation is from the old monolithic days. This means
> that the current system needs to generate the HTML pages for _all_
> packages at once.
>
> Carlo and myself have been working on changing this, such that HTML
> pages can be generated for individual packages. The code for this is
> available in the 'generate_html' package.
>
> For a long time essential parts of this code has been incomplete, but
> I've recently been taking a stab at this once more. You can check out
> the results at
>
>  http://octave.sf.net/test
>
> This test site is only showing three packages (the ones I happened to
> have installed). It is also missing a bunch of stuff:
>
>  * Doxygen documentation.
>  * The Octave manual.
>  * The help texts of all functions that come with core Octave.
>
> Do you have any comments on this page? I've made some changes here and
> there to simplify the HTML generation; I hope I haven't changed anything
> that people cared about (if so, speak up).
>
> Søren
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Octave-dev mailing list
> Octave-dev@...
> https://lists.sourceforge.net/lists/listinfo/octave-dev

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 11:53 +0200, skrev Paul Sundvall:
> Nice work!
> I appreciate your efforts towards a per-package release system. The
> layout is nice and the only thing that I think is wrong is the title of
> the page, which I guess should be "Octave package: Image" and not
> "Function Referene: image".

That's a bug. I'll fix it; thanks.

> *does the package name has to be repeated in the yellow box as well as
> on the top of the page?

No, I guess not. Which one would be best to remove?

> *can the green box display the latest version number, and have a smaller
> text below with a link to older releases? (if there are is such
> functionality). If there is something broken in a package version, I
> think users will appreciate being able to easily find an older version.

Adding a version number should be easy. Links to older releases is
somewhat harder as I'm not sure we can automatically determine which of
the previous releases we should link to. We could link to

  https://sourceforge.net/projects/octave/files/

but I'm not sure how much that helps.

> *is it desirable/possible to have links to external packaging of the
> octave packages? Like pointers to debian package, macports etc. C.f.
> http://www.macports.org/ports.php?by=name&substr=octave-image and
> http://packages.debian.org/sv/source/lenny/octave-image

Again, this is not something that can be hard to determine
automatically. I would guess that people that get their Octave-stuff
from e.g. MacPorts would look there in the first place instead of
looking at our site. Is that assumption correct?

> *should there be a link to bugs for the package? For now, it can lead to
> the bugs page http://octave.sourceforge.net/bugs.html but there will
> maybe be a bug tracking system for the octave packages in the future.

There has been talk about making a bug tracker for core Octave, but I
don't remember discussing this for Octave-Forge.

> *should we include a pointer to the repository? something like
> http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/image/

I think potential contributors should be able to navigate the SVN
themselves. So, _I_ think the 'SVN' link in the top menu should be
enough.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Thomas Treichl]

Søren Hauberg schrieb:
> søn, 18 10 2009 kl. 11:15 +0200, skrev Thomas Treichl:
>> Ok, some questions:
>>
>>   - What do you mean by Doxygen documentation? Is it the Coda script?
>
> No, I mean class descriptions generated by doxygen. We have these on the
> current site at
>
>   http://octave.sourceforge.net/doxygen/html/index.html

Where are the sources of the doxygen docu, are they included in Octave's source
files or are they at OF?

>>   - My opinion is that the Octave manual should _not_ be part of OF, but
>>     there should be a link to the website of the Octave project where the
>>     manual can be found.
>
> I both agree and disagree. I think it is nice to have all the
> documentation available in one place where everything looks the same.

Yes this is true but it must not look the same, I'd say.

> If
> we link to www.octave.org the user will get something that looks
> different from Octave-Forge. I think that will just create confusion.

YesNo, I partially agree because I also often see people asking for the usage of
a special command on the wrong list, eg. a command that belongs to OF and not to
Octave - then people always are encouraged to ask again at the OF mailing list...
What I'd like to say is, if we make separation clearer (what is OF and what is
GNU Ocatve) then people also better can separate between OF and GNU Octave and
maybe are less confused.

> That being said, I think it is silly to duplicate the documentation on
> multible sites. Personally, I'd like to merge www.octave.org and
> octave.sf.net into one site, so there is less to maintain.

It's not just that, but people do already get documentation enough (at least I'd
say). I can't talk for the Windows colleagues but eg. I'm packing liboctave.pdf,
octave-faq.pdf, octave.pdf and refcard-{a4,legal,letter}.pdf into the GNU Octave
Mac binary dmg. I think that people also get all that documentation with Fink,
HMUG or Macports on a Mac. On Linux systems I'd say that you can install all the
GNU Octave documentation that you want...

And finally, we need another maintainer at OF for posting the GNU Octave manual.

>>   - The help texts of all functions that come with the core Octave should be
>>     part of the GNU Octave website, not of the OF website, too. Maybe it is
>>     useful to create another link to the Octave website then.
>
> The problem is the 'See also's in the function help texts. If you look
> at a help text for a function from a package that references some
> function in core Octave, where should you go when you click on said
> link? If it'll be confusing if you get sent of to www.octave.org.

That definitely is a problem I was not thinking about...

   Thomas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 12:17 +0200, skrev Thomas Treichl:
> Where are the sources of the doxygen docu, are they included in Octave's source
> files or are they at OF?

They are just extracted from the core Octave source code. Many people
find these pages helpful for figuring out the class hierarchy in Octave.
However, no official policy has been made about having doxygen
documentation. So for now, we just keep them in Octave-Forge rather than
octave.org.

> > The problem is the 'See also's in the function help texts. If you look
> > at a help text for a function from a package that references some
> > function in core Octave, where should you go when you click on said
> > link? If it'll be confusing if you get sent of to www.octave.org.
>
> That definitely is a problem I was not thinking about...

I think we agree that we're in some sort of grey zone here. How about
only keeping the help texts for the functions distributed with core
Octave on the Octave-Forge website (for "See also"'s)? The manual can
then be kept on www.octave.org.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 12:30 +0200, skrev Søren Hauberg:
> I think we agree that we're in some sort of grey zone here. How about
> only keeping the help texts for the functions distributed with core
> Octave on the Octave-Forge website (for "See also"'s)? The manual can
> then be kept on www.octave.org.

I've tried doing this; the result is uploaded. Do you think this is a
reasonable approach?

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Thomas Treichl]

Søren Hauberg schrieb:
> søn, 18 10 2009 kl. 12:17 +0200, skrev Thomas Treichl:
>> Where are the sources of the doxygen docu, are they included in Octave's source
>> files or are they at OF?
>
> They are just extracted from the core Octave source code. Many people
> find these pages helpful for figuring out the class hierarchy in Octave.
> However, no official policy has been made about having doxygen
> documentation. So for now, we just keep them in Octave-Forge rather than
> octave.org.

Then (again my opinion) whatever reason it is (I'm a bad guy, isn't it), the
Doxygen documentation then should also be part of octave.org because it's an GNU
Octave issue and not an OF issue. I understand that somebody has to do the work
at the core Octave team, but what is the technical problem if it would be
accessible via octave.org? And again, who would be the OF maintainer for keeping
the C++ API documentation up-to-date when a new GNU Octave is released?

*sorry for being me that bad guy ;)*

>>> The problem is the 'See also's in the function help texts. If you look
>>> at a help text for a function from a package that references some
>>> function in core Octave, where should you go when you click on said
>>> link? If it'll be confusing if you get sent of to www.octave.org.
>> That definitely is a problem I was not thinking about...
>
> I think we agree that we're in some sort of grey zone here. How about
> only keeping the help texts for the functions distributed with core
> Octave on the Octave-Forge website (for "See also"'s)? The manual can
> then be kept on www.octave.org.

Fine for me. Others?

søn, 18 10 2009 kl. 12:30 +0200, skrev Søren Hauberg:
 > I've tried doing this; the result is uploaded. Do you think this is a
 > reasonable approach?

Fine for me, exception is the C++ documentation. Others?

Best regards

   Thomas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 20:10 +0200, skrev Thomas Treichl:

> Søren Hauberg schrieb:
> > søn, 18 10 2009 kl. 12:17 +0200, skrev Thomas Treichl:
> >> Where are the sources of the doxygen docu, are they included in Octave's source
> >> files or are they at OF?
> >
> > They are just extracted from the core Octave source code. Many people
> > find these pages helpful for figuring out the class hierarchy in Octave.
> > However, no official policy has been made about having doxygen
> > documentation. So for now, we just keep them in Octave-Forge rather than
> > octave.org.
>
> Then (again my opinion) whatever reason it is (I'm a bad guy, isn't it), the
> Doxygen documentation then should also be part of octave.org because it's an GNU
> Octave issue and not an OF issue. I understand that somebody has to do the work
> at the core Octave team, but what is the technical problem if it would be
> accessible via octave.org? And again, who would be the OF maintainer for keeping
> the C++ API documentation up-to-date when a new GNU Octave is released?
>
> *sorry for being me that bad guy ;)*

Hey, we need bad guys :-)

Some time ago it was discussed if we should host the Doxygen stuff on
www.octave.org. In general most people thought it would be nice to have,
but one mayor issue is the message it sends to put the Doxygen stuff on
www.octave.org. It might give the impression that the C++ API is stable
which is far from the case. So, the last time this was discussed it was
decided (at least that's what I remember) that Doxygen should not go on
www.octave.org until the API is more stable or at least until a subset
of the API was declared stable.

So, I would like have the Doxygen stuff on www.octave.org, but I'm not
sure if that's possible. I guess I should start a thread on the
maintainers list about this.

If the Doxygen can't go on www.octave.org I still think it should be
available at octave.sf.net. A lot of people like this documentation, so
I think it should be available somewhere.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[dbateman]

Søren Hauberg wrote:

> søn, 18 10 2009 kl. 12:30 +0200, skrev Søren Hauberg:
>  
>> I think we agree that we're in some sort of grey zone here. How about
>> only keeping the help texts for the functions distributed with core
>> Octave on the Octave-Forge website (for "See also"'s)? The manual can
>> then be kept on www.octave.org.
>>    
>
> I've tried doing this; the result is uploaded. Do you think this is a
> reasonable approach?
>
> Søren
>  

Good work.. The function reference navigation bar with the categories
and alphanumeric in the navbar isn't quite as nice as it used to be
though.. Any chance of having the old navbar back, or does that go
against each package is managed separately?

D.


--
David Bateman                                dbateman@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 18 10 2009 kl. 23:48 +0200, skrev David Bateman:
> Good work.. The function reference navigation bar with the categories
> and alphanumeric in the navbar isn't quite as nice as it used to be
> though.. Any chance of having the old navbar back, or does that go
> against each package is managed separately?

I guess it should be possible, but it would require more server-side
scripting. The 'Categorial' tab on the current site ended up just
listing the packages we have available, so I never really thought that
part worked out too well, which is why I didn't replicate that. I've
tried to minimise server-side scripting as I've often felt that the
Sourceforge servers were slow enough in the first place. Whenever I need
a list of packages or list information from several packages at once I
need to use server-side scripting (due to the idea that maintainers
should be able to upload packages independently of each other). So, if I
should re-add the old 'Categorial' view then every page in the
documentation would require server-side scripting.

As to the alphanumeric list, then I guess that shouldn't be to hard to
re-add. I really liked getting rid of the tab-system is the code for it
was quite terrible (due to IE compatibility). But if people would like
to see the tabs again, then I guess I could resurrect the code.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Carlo de Falco-2]

On 18 Oct 2009, at 20:10, Thomas Treichl wrote:

> Then (again my opinion) whatever reason it is (I'm a bad guy, isn't  
> it), the
> Doxygen documentation then should also be part of octave.org because  
> it's an GNU
> Octave issue and not an OF issue.

Well, that's not completely true in my opinion. The doxygen docs are  
there as a guide for writing extensions to Octave using the C++ API  
and extensions usually go into octave-forge.
I see the doxygen docs as a complement to the "Coda" tutorial...

> I understand that somebody has to do the work
> at the core Octave team, but what is the technical problem if it  
> would be
> accessible via octave.org? And again, who would be the OF maintainer  
> for keeping
> the C++ API documentation up-to-date when a new GNU Octave is  
> released?

Well, the API documentation has until now been more or less kept in  
sync with the development snapshots rather than with the Octave  
releases...

> *sorry for being me that bad guy ;)*

sorry if I sound even worse ;)
c.



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Carlo de Falco-2]

On 17 Oct 2009, at 23:58, Søren Hauberg wrote:

> Hi All
>
> For waaay too long I've been working on changing the release system.
> Well, "working" isn't really the right word as I haven't actually done
> much work due to lack of time.
>
> To those that don't remember, the reason why we don't allow individual
> package maintainers to release their packages when it suits them, is
> that the HTML generation is from the old monolithic days. This means
> that the current system needs to generate the HTML pages for _all_
> packages at once.
>
> Carlo and myself have been working on changing this, such that HTML
> pages can be generated for individual packages. The code for this is
> available in the 'generate_html' package.
>
> For a long time essential parts of this code has been incomplete, but
> I've recently been taking a stab at this once more. You can check out
> the results at
>
>  http://octave.sf.net/test
>
> This test site is only showing three packages (the ones I happened to
> have installed). It is also missing a bunch of stuff:
>
>  * Doxygen documentation.
>  * The Octave manual.
>  * The help texts of all functions that come with core Octave.
>
> Do you have any comments on this page? I've made some changes here and
> there to simplify the HTML generation; I hope I haven't changed  
> anything
> that people cared about (if so, speak up).
>
> Søren

Søren,
Sorry I didn't have time to contibute more,
but it seems you have managed to do a really great job!
I really love this!
Now, what would be really needed to start thorough testing would be a  
description of the precise steps that a package maintainer would need  
to do to publish a new version of his/her package. Before you move the  
new design to the production website I'd like as many as possible of  
the package maintainers to try to update their packages and to hear  
thei impressions on the procedure required for doing that.
If you want I can prepare a short description to add on the OF  
developers guide.
If I understand correctly the steps to follow would be:

1) bump the version number in the package DESCRIPTION file
2) produce a tar.gz of the package and add it to the sf release system
3) generate the function reference HTML files with generate_package_html
4) delete the contents of the folder containing the package help on  
the www sever
5) upload the new help files

Am I missing something?
c.




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

man, 19 10 2009 kl. 10:28 +0200, skrev Carlo de Falco:
> Søren,
> Sorry I didn't have time to contibute more,
> but it seems you have managed to do a really great job!
> I really love this!

You're not given yourself enough credit here. The server-side scripting
stuff is mostly your work and idea, and this is what simplified things
enough for me to finish them on my limited time schedule.

> If I understand correctly the steps to follow would be:
>
> 1) bump the version number in the package DESCRIPTION file
> 2) produce a tar.gz of the package and add it to the sf release system
> 3) generate the function reference HTML files with generate_package_html
> 4) delete the contents of the folder containing the package help on  
> the www sever
> 5) upload the new help files

These are indeed the steps. Just to add some details:

Step 3) is done using the SVN version of the 'generate_html' package. To
do this, you should install the to-be-released package on your system
and run

  generate_package_html ("miscellaneous", :, "octave-forge")

(replace "miscellaneous" with the name of your package). This generates
a directory called 'htdocs' in which you will find a directory with the
name of your package. This is the directory you should upload to the
webserver. Nothing else needs to be done.

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Carlo de Falco-2]

On 19 Oct 2009, at 10:42, Søren Hauberg wrote:

> man, 19 10 2009 kl. 10:28 +0200, skrev Carlo de Falco:
>> Søren,
>> Sorry I didn't have time to contibute more,
>> but it seems you have managed to do a really great job!
>> I really love this!
>
> You're not given yourself enough credit here. The server-side  
> scripting
> stuff is mostly your work and idea, and this is what simplified things
> enough for me to finish them on my limited time schedule.
>
>> If I understand correctly the steps to follow would be:
>>
>> 1) bump the version number in the package DESCRIPTION file
>> 2) produce a tar.gz of the package and add it to the sf release  
>> system
>> 3) generate the function reference HTML files with  
>> generate_package_html
>> 4) delete the contents of the folder containing the package help on
>> the www sever
>> 5) upload the new help files
>
> These are indeed the steps. Just to add some details:
>
> Step 3) is done using the SVN version of the 'generate_html'  
> package. To
> do this, you should install the to-be-released package on your system
> and run
>
>  generate_package_html ("miscellaneous", :, "octave-forge")
>
> (replace "miscellaneous" with the name of your package). This  
> generates
> a directory called 'htdocs' in which you will find a directory with  
> the
> name of your package. This is the directory you should upload to the
> webserver. Nothing else needs to be done.
>
> Søren

While thinking about the release procedure I realized that, as the  
release of all packages will not be done all at once anymore, it will  
not be possible to track down the SVN release
number corresponding to a given package version.
So what about adding an (optional) field named "Octave-Forge SVN  
release #" to the DESCRIPTION file format?
c.




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

man, 19 10 2009 kl. 10:48 +0200, skrev Carlo de Falco:
> While thinking about the release procedure I realized that, as the  
> release of all packages will not be done all at once anymore, it will  
> not be possible to track down the SVN release
> number corresponding to a given package version.
> So what about adding an (optional) field named "Octave-Forge SVN  
> release #" to the DESCRIPTION file format?

I think this is something a lot of people will forgot (I have a feeling
I might be one such person). I wouldn't object to making this, but
unless we have a way of doing it automatically, then I think it should
be optional (as you suggest).

Søren


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Carlo de Falco-2]

On 19 Oct 2009, at 11:12, Søren Hauberg wrote:

> man, 19 10 2009 kl. 10:48 +0200, skrev Carlo de Falco:
>> While thinking about the release procedure I realized that, as the
>> release of all packages will not be done all at once anymore, it will
>> not be possible to track down the SVN release
>> number corresponding to a given package version.
>> So what about adding an (optional) field named "Octave-Forge SVN
>> release #" to the DESCRIPTION file format?
>
> I think this is something a lot of people will forgot (I have a  
> feeling
> I might be one such person). I wouldn't object to making this, but
> unless we have a way of doing it automatically, then I think it should
> be optional (as you suggest).

Yes, it should definitely be optional also because with the new  
release system
it is not strictly necessary anymore to have all packages developed  
using the OF SVN repository...

> Søren

c.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Carlo de Falco-2]

On 19 Oct 2009, at 10:28, Carlo de Falco wrote:

>
> On 17 Oct 2009, at 23:58, Søren Hauberg wrote:
>
>> Hi All
>>
<...>
>> For a long time essential parts of this code has been incomplete, but
>> I've recently been taking a stab at this once more. You can check out
>> the results at
>>
>> http://octave.sf.net/test
>>
>>
<..>

>>
>> Søren
>
> Søren,
> Sorry I didn't have time to contibute more,
> but it seems you have managed to do a really great job!
> I really love this!
> Now, what would be really needed to start thorough testing would be  
> a description of the precise steps that a package maintainer would  
> need to do to publish a new version of his/her package. Before you  
> move the new design to the production website I'd like as many as  
> possible of the package maintainers to try to update their packages  
> and to hear thei impressions on the procedure required for doing that.
> If you want I can prepare a short description to add on the OF  
> developers guide.
> If I understand correctly the steps to follow would be:
>
> 1) bump the version number in the package DESCRIPTION file
> 2) produce a tar.gz of the package and add it to the sf release system
> 3) generate the function reference HTML files with  
> generate_package_html
> 4) delete the contents of the folder containing the package help on  
> the www sever
> 5) upload the new help files
>
> Am I missing something?
> c.

Søren,

After a loooooooong time I finally got a chance to try doing this,
the patch to add the upload procedure to the developers webpage is  
attached.
I would have applied it myself but I did not have write permission on  
that file.
Also, the description of the procedure is only theory as in practice I  
could not
really run it because of some errors:

1) I do not have enough privileges to delete the contents of
/home/groups/o/oc/octave/htdocs/test/nurbs
2) generate_package_html does not seem to work properly on my system:
---------------------------------
 >> pkg load generate_html
 >> generate_package_html ('nurbs', 'nurbs-html', 'octave-forge')
warning: marking 'nrbkntmult' as not implemented
error: `get_alpha_database' undefined near line 200 column 41
error: called from:
error:   /Users/carlo/octave/generate_html-0.0.9/
generate_package_html.m at line 200, column 39
---------------------------------
maybe you forgot to check-in some function?

Thanks again for the nice job,
Carlo





--- developers.html.orig 2009-11-15 10:57:02.000000000 +0100
+++ developers.html 2009-11-15 10:56:07.000000000 +0100
@@ -483,6 +483,83 @@
 on the server (?), e.g., because you submitted a patch for someone else to apply.</li>
 </ul>
 
+<h3>Make a release of your package and publish its function reference</h3>
+<p>
+When you are ready to make a new release of your package you will have
+to update the website to show the package newly released as follows:
+<ul>
+  <li>
+  bump the `Version' number (and optionally the `SVNRelease') in the
+  package DESCRIPTION file
+  </li>
+  
+  <li>
+  produce a tar.gz of the package
+  <pre>
+  $ cd
+  $ cd Desktop/OF/octave-forge/extra/
+  $ svn export nurbs ~/nurbs
+  Export complete.
+  $ cd
+  $ grep -i version nurbs/DESCRIPTION
+  Version: 1.0.2
+  License: GPL version 2 or later
+  $ tar czf nurbs-1.0.2.tar.gz nurbs/
+  $ ls  *.tar.gz
+  nurbs-1.0.2.tar.gz
+  </pre>
+  </li>
+
+  <li>
+  upload the tarball to the sourceforge release system, following
+  instructions given <a
+  href="https://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download">here</a>,
+  for example:
+  <pre>
+   $ sftp cdf,octave@...
+   Connecting to frs.sourceforge.net...
+   cdf,octave@...'s password:
+   $ sftp> cd /home/frs/project/o/oc/octave/Octave\ Forge\ Packages/Individual\ Package\ Releases/
+   $ sftp> put nurbs-1.0.2.tar.gz
+   Uploading nurbs-1.0.2.tar.gz to /home/frs/project/o/oc/octave/Octave Forge Packages/Individual Package Releases/nurbs-1.0.2.tar.gz
+   nurbs-1.0.2.tar.gz                                                                                                              100%   52KB  25.9KB/s   00:02    
+   sftp> exit
+  </pre>
+  </li>
+  
+  <li>
+  generate the function reference HTML files with
+  generate_package_html:
+  <pre>
+  $ octave -q --eval "pkg load generate_html; generate_package_html ('nurbs', 'nurbs-html', 'octave-forge')"
+  $ cd nurbs-html/
+  $ ls
+  nurbs       short_package_descriptions
+  </pre>
+  </li>
+
+  <li>
+  delete the contents of the folder containing the package help on the
+  www sever:
+  <pre>
+  $ ssh -t cdf,octave@... create
+  cd /home/groups/o/oc/octave/htdocs/test
+  [cdf@shell-21002 test]$ rm -rf nurbs/*
+  [cdf@shell-21002 test]$ exit
+  logout
+  </pre>
+  </li>
+
+  <li>
+  upload the new help files:
+  <pre>
+  $ scp -r ./nurbs-html/* cdf,octave@...:/home/groups/o/oc/octave/htdocs/test/nurbs
+  </pre>
+  </li>
+  
+</ul>
+</p>
+
 <h3>Learn more about SVN</h3>
 <p>The few SVN commands shown here just scratch the surface of this
 powerful versioning package.  If you become an active contributor





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev

[Søren Hauberg]

søn, 15 11 2009 kl. 11:08 +0100, skrev Carlo de Falco:
> After a loooooooong time I finally got a chance to try doing this,
> the patch to add the upload procedure to the developers webpage is  
> attached.
> I would have applied it myself but I did not have write permission on  
> that file.

Did you try to commit your changes to SVN or upload them to the web
server? I've changed some rights on the web server, although I couldn't
change the rights of all files as I didn't have the rights.

Does anybody know if there is a way to get 'administrator'-like access
to our web space?

> Also, the description of the procedure is only theory as in practice I  
> could not
> really run it because of some errors:
>
> 1) I do not have enough privileges to delete the contents of
> /home/groups/o/oc/octave/htdocs/test/nurbs

I've tried to change rights, so please try again. Basically, I've done a

  chmod -R g+w htdocs

which used to do the trick. I do, however, get a lot of warnings like
this one:

 chmod: changing permissions of
`htdocs/short_package_descriptions/main/zenity_short_description.html':
Operation not permitted

Help would be appreciated.

> 2) generate_package_html does not seem to work properly on my system:
> ---------------------------------
>  >> pkg load generate_html
>  >> generate_package_html ('nurbs', 'nurbs-html', 'octave-forge')
> warning: marking 'nrbkntmult' as not implemented

This warning is usually due to bug in the texinfo markup of the help
text of the function in question.

> error: `get_alpha_database' undefined near line 200 column 41

I forgot to add this file, but it should be uploaded now. Thanks for
catching this.

Søren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@...
https://lists.sourceforge.net/lists/listinfo/octave-dev