openSUSE:Build Service Junior Jobs
tagline: From openSUSE
This page is about smaller open development tasks for the Open Build Service. These tasks are a good start to dive into OBS development and Ruby on Rails development.
We have collected the following tasks:
- 1 Help us to raise our quality
- 2 Show more status information in web user interface
- 3 Publisher improvements
- 4 Senior Jobs
Help us to raise our quality
The OBS comes with test suites to validate our code. The test suite is running before we deploy or package releases. So a good test suite will lead to a good product. Unfortunatly there are plenty areas which are not covered by the testsuite yet, but luckily it is easy to write more tests. Check here to learn how to run and develop tests.
Show more status information in web user interface
The backend knows already a lot of data like history and status informations which are not visible in the web client. These informations can get requested in via the API already, but are not accessible via our clients yet.
This means also that you do not need an own full Open Build Service for development. You just need to run a local web client on your system, which uses our official Open Build Service instance behind api.opensuse.org. You can read here how to run it on your system.
Show history of requests
The project and package pages could contain tabs for showing the past request for the project or package. "accepted" requests are in interest in first place. feature request.
Manage project sign key in web interface
Add a view for the signkey in projects. Details can be found in the feature request.
Improve Package Page
The package page currently shows all current sources, but nothing else. However the backend system know a lot more about it:
- Open submission requests: Submission requests are requests to merge a change into the package. This can be seen with "osc sr list" command already. However a nice way to see open submission requests for the package, an easy way to see the changes and to approve or decline would be nice.
- Merged source link: The web client always show "unexpanded" sources. This means that packages with source links show the "_link" file plus patches. The backend offers to expand the source link, this means to show the sources with applied patches. It would be nice to have switch to show the merged sources in this view also. Almost done by Jan Loeser.
- Commit log: A log of source commits could be shown. Maybe also with displaying the diff. And maybe even a function to revert to this state :)
- You lack a package dependency to be able to build your package ? A wizard could help here a lot, it should search for this dependency and than offer:
- Add further repo to build against (when package exists for your platform there)
- source link the package (if it got not yet built for your platform yet)
The Open Build Service publisher is a relative simple perl script, so it is an easy way to dig into the backend source.
nu file support in publisher
zypper supports since openSUSE 11.1 the nu files. These are repo descriptions which allows to add further repos. This means, when a user adds the KDE:KDE4.3 repo and the packager decides later that he wants to build this against KDE:Qt46, zypper will automatically use this repo as well.
This was all too easy and boring for you ? We have also tasks which need extensions in the backend, in the api front-end and web client. This means you need a local instance of the Open Build Service for developing.
Improve Monitor Page
- Add Scheduler Statistics: The scheduler collects already all kind of statistics for performance tuning. The file $BUILD_SERVICE_ROOT/info/schedulerinfo.$arch contains informations about used resources of the scheduler, events to process and also which are the projects which take most resources. This should become requestable via source and repository server, in the api and become displayed in the web client.
- Add repo setup status: The scheduler does find out about dependency loops between packages and repositories. This information is currently not stored anywhere but would be very helpful for developers. The job is to stored this information on disk, make it requestable in src, rep server and api. And last but not least display it in the Web interface platform page.