Contributing to the development of packages/modules: Difference between revisions

From Octave
Jump to navigation Jump to search
m (β†’β€ŽOne shot contribution: use codeline templae)
(added brut text from mail conversation about fixing old unmaintained packages)
Line 29: Line 29:


Looking forward for your next contribution!
Looking forward for your next contribution!
== Maintaining unmaintained packages ==
Being a package maintainer would not mean you have to fix all the bugs, only that you get the last word about applying patches from others and including new functions that other users will submit. You don't have to fix bugs, just tell them to use the bug tracker until someone that cares tries to fix it.
About the difference between old and new releases, Octave Forge used to be one single large project. Now each package is released indidually and have their own independent development. As such, there used to be Makefile everywhere as variables would propagate. When the split was made, unmaintained packages, such as video, kept the old Makefiles (because no one removed them). The Makefile at the root of package for example does nothing.


== See also ==
== See also ==

Revision as of 13:32, 10 October 2012

All OctaveForge packages (this name will change as soon we have Agora online running) are hosted in this site. Here we discuss how you can contribute to the development of those packages. Lets say you have found a bug in a function of one package and you know how to fix it.

One shot contribution

In the OctaveForge site you can look for the package in question and get the latest version of the function you want to fix. This version could be unreleased, that is, it is not yet listed in the OctaveForge website and you will not get it by doing pkg -forge install my_package in the Octave prompt.

You can use this function in Octave if you copy on top of the old one (or rename the old one to *_old.m), but be careful because it may require other new functions. Anyway, you can get the latest and coolest version of any package from that site.

Once you have the newest version of the function, check if it still has the bug you found. If it doesn't somebody solved it already. If the problem still there go on an fix it!

Once you have fixed the bug, you can send a patch with your changes. How do you this? Check the developers help page.

Checking out the svn

You can also checkout the package in question using svn. For example if you wan to checkout the general package you would run

svn co https://octave.svn.sourceforge.net/svnroot/octave/trunk/octave-forge/main general general_to_debug

This will create a folder general_to_debug in your current directory. You can hack away as much as you can and then produce the patch and send it to the mailing list.

Contributing new file or bundle of files

There is a third way of contributing to OctaveForge. Lets say you do not want to be a developer but you have one or a bundle of functions you want to share with the commuity. You can use the features request forum (this will be also replaced by Agora when it is up and running). Upload your file (compressed if it is more than one) and lets us know that you did it by sending a mail to the mailing list. If there is anybody interested they will look at your code and give you suggestions. Speed up that process by adding a GPL compatible license, preferably the latest GPL.

Being a forger

If you want to be a more permanent member of our community, you can also request to be a Forge developer (name may change) following these instructions.


Let us know if there are more questions

Looking forward for your next contribution!

Maintaining unmaintained packages

Being a package maintainer would not mean you have to fix all the bugs, only that you get the last word about applying patches from others and including new functions that other users will submit. You don't have to fix bugs, just tell them to use the bug tracker until someone that cares tries to fix it.

About the difference between old and new releases, Octave Forge used to be one single large project. Now each package is released indidually and have their own independent development. As such, there used to be Makefile everywhere as variables would propagate. When the split was made, unmaintained packages, such as video, kept the old Makefiles (because no one removed them). The Makefile at the root of package for example does nothing.

See also