Good day,

We are currently testing the next release of Scubuntu. The testing should be finished by no later than 29 May 2009.

Release on 1 June 2009

It seems some is using SAGA GIS in  scubuntu. I found the thread: http://sourceforge.net/forum/message.php?msg_id=5838388

Survex and Therion Viewer in ubuntu. Cave exploration apps.

Might be of interest to us:

http://freegeographytools.com/

Names are important - just ask any ship-builder to name their latest creation “Titanic” if you don’t believe me. The Ubuntu community realised this early, and adopted a convention for naming the versions of their desktop offering that (surprise surprise!!!) does not rely exclusively on numbers to set apart their newer releases from the older ones. In keeping with the spirit of capturing the publics imagination, I proposed that we use cool-sounding science-y names for Scubuntu.

A list of possible candidates can be found on the  wiki over here. Please feel free to suggest alternate names (for example, “Silicon” is not as impressive sounding as “Steel”).

After two preview releases,  version 1 of Qunatum GIS (Qgis) has been released. The release seems to have gone by without much fanfare. The source  for  1.0 is available, but there has been no mention of the Qgis site. This version will most likely go to into the next release of scubuntu.

Two main issues were discussed, best practices and Open LoCo week

Best Practices

- Do we have a problem with best practices?
- Always good to know what other teams are doing
- For example, the successes of the French Team release party
- Create a wiki page that has provides information how teams have successfully planned events.
- Would have a LoCo sprint help?
- Get together a few big LoCos and see what their processes are
- Start talking now about what should be discussed at a sprint in the future
- How do we get people to share best practices since its boring?
- BEER!
- Have cross-LoCo meetings.
- The main problems are that LoCos don’t know the existing documentation exists
- Get the big LoCos to kick off best practices documentation
- Focus more on LoCos this cycle
- Maybe a separate LoCo specific planet?
- No, we want to get as many eyeballs as possible

LoCo Open Week
- We will do this

Improve communications
- Get LoCos talking about mundane details best pricing on t-shirts, will spur conversations and ideas

Here are  some terms that I heard being used frequently, I am no sure I know what they all mean. It may that some have had their meaning changed

• triage
• upstream
• loco (not Mexican/Spanish)
• jams
• sprint
• use case

There are many more. Please free to add more.

Xubuntu is trying to grow it’s community, much like scubuntu! I attend the session with some of the developers (Coddy, Jannis). Their plans are not that far different with us. Here are some of the notes from Day 4 session:

•  Create social networking groups & communities (Facebook, last.fm, linkedIn, etc.)
• Improve the content on the “Get Involved” pages (Wiki)
• Ensure that there is contact information so users know (Wiki)
• Minimize the amount of information presented to the user at once (on the Wiki)

My concern was that there seems to be too much emphasis on the wiki, blogging and IRC. While it is great to have all these channels, the not so technically inclined users may not even know what these are. There is probably an opportunity in there somewhere to drive home the message about these tools.

As mentioned in a previous blog post, there is no easy way to package. Anyone who wants to package needs to learn a great deal to contribute packages to Ubuntu. As someone who actually has packaged software for Ubuntu (well, for Scubuntu), I can attest that the level of knowledge needed to contribute a package is extremely high.

My previous blog mentioned “drive-by” packaging - which is people who merely want to package a single thing and then move on. The session Making Jams Rock also raised this issue. Some people simply want to package their pet project and then move on. I’m actually writing this as the discussion is in session, and unfortunately the session is for making jams rock, which is non-trivially different from getting more packages.

A few suggestions to aid in making jams rock were tossed out - for example an ISO image that people can burn which has movies that teaches how to package, or slides perhaps. However I believe that an automated packager to allow people to package their single pet project and move on would greatly simplify the packaging process . Especially useful would be something that stores the submitters info so that they can be informed when the package breaks.

Because packaging is almost fully automatic provided a small number of constraints are met, perhaps a PoC script might help. Launchpad already helps a great deal by doing a lot (signing, etc) and the helper applications (deb* scripts) also help a lot as well, but the process is hairy for even a trivial package that does not even need compilation (such as software composed entirely of text files, such as bash/python/etc scripts).

It would be nice to have a drive-by packager, so perhaps I’ll have a look at this later.