User talk:Elangelo

trying to check on the svn adding of modules...

Once you've written your own module you can commit these to the official moonbase. Once they have been reviewed twice by another developper they will be put into the real moonbase and all lunar users will be able to use your commited work.

There are actually 2 ways to get your modules into moonbase.

First Method - Use lvu

source : Auke Kok - mailing list

because I get the idea that the 'lvu submit' code actually works and people are happy to use it, I've made some changes to the code that require some explanation. Read and you will see how easy it will be to edit your own module changes:

Step 1: - copy a module to zlocal for editing

Suppose there is a new module out for module arpwatch. You'd have to figure out in which section this module sits, edit the module file, submit it etc. This can now be done easier with 'lvu edit':

$ lvu edit arpwatch Copied "arpwatch" from "net" Edit your module in "/var/lib/lunar/moonbase/zlocal/arpwatch"

You can now jump straight to that directory or use

$ lvu cd arpwatch

Step 2: make your changes

Make sure you *test* your module afterwards by linning it. Check 'lvu install $MODULE' and look if all files look installed OK. Make sure it works too, by running the application.

Step 3: submitting your changes

$ lvu submit arpwatch

You are presented an e-mail-template. Edit the From: line and insert an email address that is valid. You can edit the information in the template to signify whether a module is a new module, update or security update etc. Currently the default is to submit the modules to the lunar@ mailinglist. Until we have a submission handler you will need to be subscribed to this mailinglist to actually do a submission.

Step 4: remove your local changes

You might want to make sure you don't actually downgrade your module by doing a 'lunar hold $MODULE'. This will postpone any update and make sure you keep your local version installed. Once you see the update in moonbase you should remove your local copy immediately and verify that your changes have arrived properly in moonbase:

$ lvu unedit arpwatch Removed "arpwatch" from "zlocal" $ lin -c arpwatch

Second Method - svn-access

as described by Auke Kok : lunar mailinglist

Step 1: get an developper account

Sign up for an account : [1]

Step 2: install subversion

lin subversion

Step 3: checkout current moonbase =

svn co https://foo-projects.org/svn/lunar/moonbase/branches/submissions

you will be asked for your username and password

Hi devs and interested people,

I've setup a module submission queue for the new submissions in our SVN trunk. This branch will get very relaxed admission rules and I plan to allow almost public access to the "/new" directory in there. The idea is as follows:

- almost anyone can add a module in /new/. These can be updates or new modules, but no core code or other code. The modules need to be COMPLETE, so no diffs or partial files (like only DETAILS).

- module submission reviewers can be anyone who has proven to be able to write working modules and take an interest. These reviewers review the module and move the module into the /reviewed-once/ directory after it passes the first review

- a second reviewer moves it to /reviewed-twice/ and thus concludes the review process. After this the module should be cleaned up and tidy, and work correctly in all circumstances.

- a developer merges the modules in the /reviewed-twice/ dir into an appropriate section in moonbase. Most commonly, the developer doesn't compile or test the module anymore, but just scans and reads the code to spot problems.

- alternatively, all developers can decide to review modules themselves or merge them right away from /new/ into /moonbase/ at any time at his convenience.

Here's a typical reviewers SVN session work:

cd /var/lib/lunar/moonbase/zlocal svn co https://foo-projects.org/svn/lunar/moonbase/branches/submissions cd submissions svn up cd new/amodule vi * lin -c amodule ... cd .. svn move new/amodule reviewed/once svn ci

By checking out the submission queue in zlocal and using ZLOCAL_OVERRIDES=on you can put the modules in the queue in action right away. `lvu where amodule` etc. should work pretty transparently, with perhaps some sideeffects with DEPENDS, but most of the time this is not a problem.

Right now we had a few interested people sign up already. They can retreive a https login by filling in the form at:

Please note that you don't need to put in a ssh pubkey for a https login.

sofar