Re: step by step guide to update code in a package

[mike . t . miller]

On Sun, Aug 12, 2018 at 18:23:11 +0530, octavecontrib wrote:
> Hi,
> Based on information from the wiki
> https://wiki.octave.org/Contributing_to_the_development_of_packages/modules
> I am trying to update some code in certain functions in the 'control'
> package of Octave.
> 
>    1. I cloned the control package repository using mercurial.
>    2. I made a commit to my local repository to have a save state to go
>    back to.
>    3. I modified the relevant .m file.
>    4. The main Makefile has an option to build ('all'), check ('check') and
>    run Octave ('run') with the modified files.
>    5. The 'run' option in the Makefile however opens octave in no-gui mode.
>    But the changes I made have to do with figures and plotting.
>    6. So, I opened Ocatve separately and 'addpath()' both 'inst' and 'src'
>    folders in my local repository.
>    7. Upon trying to run some scripts to test, Octave complained of missing
>    functions.
>    8. So, I copied the 'PKG_ADD' file containing the 'autoload()' functions
>    from the released package folder
>    
> ('/usr/lib/x86_64-linux-gnu/octave/packages/control-3.0.0/x86_64-pc-linux-gnu-api-v51')
>    to my local repository.
>    9. I tested my modifications.
>    10. I committed the modifications to my local repository.
>    11. ???
> 
> Questions
> 
>    - Is there a STEP BY STEP tutorial or guide for package modification?

Not really, but you may have a good start at establishing one.

>    - Is there some established WORKFLOW for package modification? (steps 6
>    and 8 above don't seem proper)

Personally, step 5-6 is not a problem for me. In the signal package,
step 7-8 is not a problem because the 'make all' target creates the
PKG_ADD file (and 'make clean' removes it) necessary for running all
compiled functions. The same could easily be done in the control
package.

>    - I want to know if the steps 1-9 above are correct and what to do next
>    to submit the changes to the package maintainers.

I'm not sure what step 2 means, making a commit before making any
changes? Is this about unfamiliarity with mercurial or distributed VCS
in general?

I would add a step like

  - Add one or more relevant unit tests to the .m file, and verify that
    'test func' and 'make check' passes all tests.

And to answer your question about what to do next,

  - Use 'hg export' to create mercurial patch files that you can submit
    on the Octave Savannah bug tracker or patch tracker. Alternatively,
    you may host your mercurial branch on a public repository (on
    bitbucket or sourceforge, for example) and mention the branch
    location in a bug report or patch ticket as a pull request.

-- 
mike

signature.asc
Description: PGP signature