Community SSU/Development

m (Moved from gitorious to github)
m (Protected "Community SSU/Development": Excessive vandalism ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite)))
 
(2 intermediate revisions not shown)

Latest revision as of 23:48, 24 March 2018

Contents

Source

The Community SSU source is held in a Github project: 

 https://github.com/community-ssu

Importing a module...

At the start of adopting a package into the Community SSU, the original source for the package, as shipped in Nokia's PR1.3 needs to be identified. This can come from two places:

  1. Git repository on maemo.gitorious.org or garage.maemo.org (preferred)
  2. Source tarball from repository.nokia.com

...from git

TBC

...from tarball

TBC

Once imported, contact Andre Klapper to get a component created in Bugzilla, under the "Maemo 5 Community SSU" product.

Version Scheme

CSSU versions consist of the upstream version +0cssuX where X is an incremental counter for the cssu release In case of nokia packages from the maemo sources this usually will look like 

 realupstream+0m5+0cssu0

For packages where we consider ourself upstream the version string is a simple version.

Packages where we consider ourself as upstream: 

 hildon-*, camera-ui, community-ssu-enabler, libcpaboutcssu

How to contribute

As a community developer, you can help the project by submitting your own changes or by simply reviewing other people's changes and provide your advice and comments to their commits.

Contributing your own changes

This section assumes you are familiar with the git source version control system. If you aren't, it's recommended that you start learning it, as it's going to make your life easier; if you just need to contribute small changes you can probably live without it and directly send your changes to the Community SSU maintainers and stop reading here.

Cloning a repository

First of all, get the source code of your module as explained in Source. If the module is not part of the http://gitorious.org/community-ssu project, you can ask the Community SSU maintainers to import the module for you.

From the http://gitorious.org/community-ssu page, find the module you are going to work on and click on the "Clone repository" button. Following gitorious's suggestions, pick a name for your new personal clone and wait for the repository to be created. Then, it's time to get the code into your computer. Supposing that you named your cloned repository <my-repo> and that the original repository is called <repo> and your name is <me>, follow these steps: 

git clone git://gitorious.org/community-ssu/<repo>.git <repo>
cd <repo>
git remote add <me> git@gitorious.org:~<me>/community-ssu/<my-repo>.git
git fetch <me>


Work on your own repository

We recommend that you always work on a branch other than master, and keep master in sync with the master branch of the original repository. So, when you are about to work an amazing feature that you'd call <my-feature>, follow these steps (here we are using the same naming conventions we used in the previous paragraph): 

git checkout master
git pull
git checkout -b <my-feature> <me>/master

Your <my-feature> branch is now active, and all the changes that you'll make with the git add and git commit commands will operate on this branch. When you wish to save your changes to the remote repository, you can do that by 

git push <me> <my-feature>


Submitting your changes

After you are done with your changes and you have committed them to your local branch, push them to the remote repository: 

git push <me> <my-feature>

Now your changes should be visible also in your cloned repository at the gitorious website. Go to the website, find your repository and click on the "Request merge button". You'll be prompted to enter a description, the target repository and branch (you usually don't need to change these) and you must select your <my-feature> branch from the drop-down "Source branch" box. When compiling the description, please take some time to explain all what is not obvious from the code itself (hopefully, very little) and also mention if and how you have tested your changes.

One of the Community SSU maintainers will review the code, and write some comments about it. You shouldn't expected your changes to be applied as they are: on the contrary, be ready to receive some questions, suggestions, and criticisms. Don't take them personally; instead, take them for what they are, that is technical arguments. They don't mean that people are not grateful for your contribution.

Reviewing the code

From the http://gitorious.org/community-ssu page, click on the "Watch" button of the modules of your interest. From now on, all activities happening in the repositories you selected, such as pushes, merge requests, comments, etc., will appear into your gitorious activity feed. Unless you frequently check the gitorious website, we recommend that you create a subscription for its RSS feed or go to the gitorious e-mail preferences page and enable e-mail notifications.

Once you get a notification that a merge request has been created, you can follow the link which is present in the notification itself and see the changes in question. If you are not satisfied with the quality of the code, or more simply you don't understand the some parts of the changes, you are more than welcome to add a comment. You can either comment to the whole change by commenting on the bottom of the page, or write inline comments by clicking on the line number next to the relevant piece of code.


In-built Applications

Main article: Community SSU/Development/In-built_applications


Here you can see a list of included applications in the Community SSU, including information about them (open/closed source), new features and fixes, work on open-source replacements.


Notes

Set of notes and action points from the discussions about Community SSU on #maemo-ssu freenode.

Main participants:

  • lcuk
  • MohammadAG
  • Jaffa
  • Venemo
  • lma
  • x-fade
  • rst38h
  • crashanddie

and more

Discussion topics

  • finding source locations and identifying GOOD patches
  • submitting potential patches to a central testing source
  • making a new mp-generic* meta package
  • discussing with lma about current N8x0 community SSU problems and workarounds and insight
  • looking into getting the wiki sorted
    • need wiki editor :P
  • looking at how to manage the patchsets
    • we know the N900 Fremantle system works well using git tags
    • the 8x0 patchset currently contains 10 local based quilts
  • we need a gitorious group to cover these Done: http://gitorious.org/community-ssu

Build Sources

We must gather together and list the main giturl sources and tags used to build from.

for instance: http://gitorious.org/modest/modest tag 3.4.8

This allows us to reproduce builds and get source to the same location we build from. 

<lcuk> how many packages for n8x0 are you looking at including in an ssu?
<lcuk> and how have you considered looking at updating the system so far - you said its all manual at the moment
<lma> I have 10 (source) packages at the moment
<lcuk> do you mind listing them 
<lma> busybox dnsmasq loudmouth modest osso-pdf-viewer osso-software-version tinymail community-ssu-enabler xorg-server kernel-diablo

This has started at http://gitorious.org/community-ssu

Technical

  1. How to work out value of Maemo-Required-Free-Space header in mp-fremantle-community-pr?
Retrieved from "https://wiki.maemo.org/Community_SSU/Development"