Your Name: DmitrijsLedkovs
Email Address: firstname.lastname@example.org
IRC nickname: xnox
GSoC LinkID: xnox
Launchpad ID: dmitrij.ledkov
Skype username: dmitrij0309
College-University: University of Hull, UK
Major: Electronics, MEng Mobile Telecommunications Technology
Please describe any previous Open Source development experience:
I'm maintaining Xiphos and Sword in Debian/Ubuntu. Due to this effort I've also became upstream developer of Xiphos. I did a few fixes in Ubuntu & bzr plugins. I'm currently Ubuntu Contributing Developer see my contributor application. Most (if not all) of my development experience is on launchpad & PTS.
Why are you interested in Open Source?
Hmmm... Because I'm a geek? I've started using Open Source apps because they were free, ad/malware free, stable and usually had more features. After I've switched to Ubuntu and started contributing I've learned a lot from Open Source apps.
How long will the project take? When can you begin work?
2.5 - 3 months. Can start part time before June. Full time from June.
How much time do you expect to have for this project? (weekly)
~ 40 hours. Hoping to start coding early.
Where will you based during the summer?
UK (UTC+1) or Latvia (UTC+2)
Do you have any commitments for the summer? (holidays/work/summer courses)
2-3 weeks for exams & dissertation. 1 week in August + a few weekends for linejuding Volleyball (world tour & national league).
I'm hoping to start early to minimise impact. And merge milestones separately.
Have you ever participated in a previous GSoC?
Have you applied for any other 2010 Summer of Code projects? If yes, which ones?
No. But I might apply for a couple of Ubuntu projects.
Why did you apply for the Google Summer of Code ?
I see this as opportunity to experience what is it like to be Open Source full-time developer. In the future I would like my career to involve developing open source software.
Why did you choose Ubuntu as a mentoring organisation?
- I am using ubuntu since 2007. I am ubuntu developer. I want to fix Bug #1. I love ubuntu.
I like the friendly developer & user community around ubuntu. During my previous work on ubuntu I've met and worked with awesome and cool developers =) some of which are mentors for GSoC.
- Every ubuntu developer has cool Brainstorm ideas which would be really amazing to have for ubuntu development and/or ubuntu users. These cute ideas are often put aside to the when-I-have-spare-time box of each developer. With GSoC they can become reality.
Why do you want to participate and why should Ubuntu choose you?
I want to make a significant contribution to Ubuntu. GSoC will give me opportunity to do that. Ubuntu should choose me because I am passionate, have sufficient knowledge and ready to learn fast. I want to become Motu/CoreDev in the future.
Automated optimistic merging and testing of new upstream releases.
Launchpad Entry: foo
Created: 19 March 2010
Typical workflow for packaging new releases has many manual steps. The aim of this spec is to automatically attempt merging new source code releases, do test builds and run qa checks. Generated reports will give Ubuntu developers an idea of what effort will be required to package new release.
This is a GSoC idea called "Automated optimistic merging and testing of new upstream releases".
Proposed catchy and more obscure name for this tool is CADIE - Completely Automated Developer and Integration Expert (pun).
CADIE allows Ubuntu Developers spend less time on repetitive tasks and focus more on creative side of programming.
Typical packaging workflow is:
- Find new code e.g. vcs-import, fresh tarball, new debian package release.
- Import new code e.g. using bzr merge, merge-upstream or import-dsc commands
- Do a test clean-build (ppa / pbuilder)
- Run automated checks
- Perform human review
We would want to automated all these. Unfortunately last one might require AI, so we will rely on Ubuntu Developers for that one.
Developer guide with CADIE in place for three cases: snapshot, tarballs, debian.
Target packages must have an up to date lp:ubuntu/package branch.
Packages must have one or more of:
- up to date shared history lp:debian/package
- working debian/watch file
- up to date lp:project branch link
You can have subsections that better describe specific parts of the issue.
There three planned streams for new code. If ubuntu version is smaller than Debian, Upstream Tarball or VCS a merge will be attempted with the closest next version.
How to check for new version
How to merge code
launchpadlib, Ultimate Debian Database, lp:debian/$pkg
bzr merge-package lp:debian/$pkg
uscan & bzr mu
Package <-> lp vcs-import link
bzr merge lp:$project
Last one will be possible when package branches share history with upstream branches. VCS import is targeted at packages which already package snapshots revisions.
After potential merge candidates are identified build jobs should be scheduled. Building will include
- Attempt merge
- Push to lp:~cadie/ubuntu/$m/$pkg/merge-$new-version
- Run source package tests
- Request recipe build from branch
This will rely on recipe building from launchpad. Alternatively building should be possible locally using pbuilder.
The unresolved question here whether we are going to use regular ppa or special soyuz build job with binary package mangling. Plus we want to have clean ppa for successful test binaries affecting each other, yet still have them available for testing by Ubuntu Developers. See testing.
- Lintian should be run after merge on source package creation. $bzr bd --source with lintian hook.
- Package building building should be done in "qa" mode
- dh_install --list-missing
- lintian on success
"qa" mode building can be achieved by either using soyuz/lp binary-package mangling. Or by having a funky debhelper package installed which diverts those commands and has wrappper in place to call our additional flags / tests. This needs further discussion
- Page with potential candidates / version comparison with stats. So we know how many packages are we dealing with. Starting with main and then extending with universe.
- The "queue" page with current status per package.
Reports (fail / success & log)
- Source merging
- Source package testing
- Test buildlog
- Binary package tests
Other test / reports will be possible as well. For example finding/identifying & displaying changelog, news, release notes.
Possible areas that might be touched: udd package importer, soyuz, M-o-M
- Create "Potential Candidates Page"
Create backend runner which attempts merging locally and pushing to launchpad (cron job) with reporting -> plain log files published on e.g. people.ubuntu.com
- Create script which scans for new merges, does $bzr bd --source lp:~cadie/ubuntu/m/pkg with lintian and publishes reports.
- Create script to scan for successful dsc and dput them to pbuilder / ppa. Or request branch builds using recipes.
Why did you like this idea?
I've been doing a few merges & syncs. MoM helps a lot, but it's not perfect. With this project implemented it would be easier to start working on Ubuntu because the required steps will be shown by example. And it will make Ubuntu development more fun "Spot what went wrong?" type of game =)
Why will your proposal benefit Ubuntu?
It will provide archive wide QA check of potential future package versions allowing to spot problems earlier in the development cycle.
Q: Package can be in multiple stages. Most of the scrips will output plain text logs. The status page will have to scan and get links for them and error fail. Q: For production CADIE should sit close to launchpad network wise. Where / how is M-o-M running? Q: Should I incrementally improve M-o-M to allow it for working in this mode? Q: What's BoF? Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.