FOSDEM 2012 review

I went to FOSDEM this year. Thanks SUSE for sponsoring my trip! Here is a short review for the projects that I found interesting at this year’s FOSDEM.

SATURDAY

The Aeolus Project

Francesco Vollero – Red Hat

This is a very interesting project if you can go past how meta it is. It wants to be an abstraction over all the existing private and public cloud solutions. The aim of the project is to be able to create and control a virtual system throughout its life cycle. It can be converted from one VM image format to another and be deployed/moved from one cloud provider to another. Groups of images can be setup and controlled together. The way resources are managed and billed would also be cloud-independent.

It relies heavily on the DeltaCloud project.

Open Clouds with DeltaCloud

Michal Fojtik – Red Hat

DeltaCloud aims to be a RESTful API that is able to abstract all of the other public or private cloud APIs, allowing for the development of cloud-independent software. The project says it wants to be truly independent (esp. from Red Hat). It was accepted as a top-level Apache project.

DMTF CIMI and Apache DeltaCloud

Marios Andreou – Red Hat

The CIMI API is a specification for interacting with various cloud-resources. A lot of very big companies are part of the DMTF Cloud Management Working Group: Red Hat, VMware Inc., Oracle, IBM, Microsoft Corporation, Huawei, Fujitsu, Dell. It is currently being implemented as part of the DeltaCloud API. The presenter also showed some implementation details: a lot of the code is shared between the DeltaCloud and the CIMI API.

Infrastructure as an opensource project

Ryan Lane – Wikimedia Foundation

The talk went into some detail about the whole Wikimedia setup. It is built on top of open source projects and aims to be entirely free and available to anyone who wants to know more about it. The speaker presented some of the issues that the Wikimedia organization faced when they decided to give full root access to their machines to volunteers and how to allow for different levels of trust.

Orchestration for the cloud – Juju

Dave Walker – Canonical

Juju is a system for building recipes of configurations and packages that can then be deployed on openstack/EC2 systems. The project aims to integrate with tools like chef and puppet to be able to manage deploying, connecting, configuring and running suites of applications in the cloud.

OpenStack developers meeting

This was a rather informal discussion. 4 major distros were present: Fedora, Ubuntu, SUSE and Debian, but also some other contributors. Upstream asked about the problems that distributions face, some minor one-time occurrences were discussed briefly. Stefano Maffulli, the openstack community manager was also present and there were some heated discussions about the way the project is governed. There are still a lot of things being discussed behind closed doors. Negotiations about the future of the project and fund-gathering is done with only a few big companies at a very high level. The community, on the other hand, was very vocal about wanting to rule itself with no enterprise interference.

Rethinking system and distro development

Lars Wirzenius

Advanced the idea of maintaining groups of packages, all locked at a specific version. Having the maintainers always know which combination of versions a bug comes from would make the whole environment easier to replicate and the bug easier to reproduce. This would also, supposedly, reduce some of the complexities of dealing with dependencies.

These groups of packages would be built directly from the upstream’s sources, following rules laid out in a git repository. The speaker also said he wants to get rid of binary packages completely.

If this were to be implemented, distributions could write functional tests against whole systems (continuously built images), rather than individual binary packages and ensure that a full configuration works.

Someone from the audience mentioned that a lot of the ideas in the talk are already implemented in NixOS(nixos.org) (which looks like a very interesting project in itself).

SUNDAY

Continuos Integration/ Continuos Delivery

Karanbir Singh – CentOS

The speaker discussed the system which CentOS uses for continuous integration. I liked their laissez-faire approach to which type of functional test language they should be using. They basically allow any type of language/environment to be used when running tests. The only requirement is that the test returns 0 on success and something else on failure. Anyone can write functional tests in any language they want (they just specify the packages as requirements for their test environment). People can choose to maintain different groups of packages along with the tests associated to them.

The Apache Cassandra Storage Engine

Sylvain Lebresne

A lot of interesting concepts about the optimizations that were made in the Cassandra project in order to speed up writes and make reads twice as fast (almost as fast as reads): different levels of caching, queuing writes, merge sorting the read cache with the physical data on reads etc.

Freedom, Out of the Box!

Bdale Garbee

An interesting project about making a truly free easily available software as well as hardware system. Some interesting concepts are used in this project like GPG keys for authentication, but also for the trust required to provide a truly decentralized peer based network, free from DNSes.


I’ve been to a few other talks that I can’t remember anything from either because of the bad quality of the presentation or because I didn’t have the prerequisite knowledge to understand what they were talking about. Next time I should also take notes.

A lot of the talks were recorded and are available over here (with more coming): FOSDEM 2012 videos. The quality of the recordings (esp. in the main room) is sometimes even better than being there live. The voice is clearer and there is no ambient noise. Also, as it was really cold in most of the rooms – I had to keep my jacket and hat on.

Comments

Copr final report

Fedora Summer Coding is now over for me and I’m really glad of what I learned and coded this summer.

Our initial goal was to develop a TurboGears2 Web app and JSON API for Fedora Copr. When finished, Copr should provide everyone with a place to build Fedora packages and host custom repositories for everyone to enjoy. This is a project that should prove quite popular in the Fedora Community when it gets released and I’m glad to have played a role in its development.

At first I worked on the web app, modeling the database and the relationship between coprs and repos and packages and then developing the JSON API. When the midterm came, my mentor and I decided that I should also contribute to the other parts of Copr. The original schedule had a simple command-line client planned, but we went further than that. In the end all of the functionality of the JSON API also got implemented in a client library (based on and very similar to python-fedora) and in a command-line client. I also got to dive into python-fedora’s and repoze.who’s internals in order to get basic HTTP authentication working for TurboGears2.

My latest work has been on the func module. This is the buildsystem part of Copr. Func minions running this module will be commanded by headhunter (Copr’s scheduler) to build packages in mock and then move them into repositories. The module also creates, updates and deletes package repositories and will check the built packages for Fedora conformance (e.g. licensing) – this last part is not yet implemented. I got to play with virtual machines and func and mock and createrepo.

There is a more synthethic overview of all the different things that got implemented on the wiki.

Overall, I’m really glad of what I learned this summer. This project really got me involved in a lot of different levels of the architecture of a web service and a lot of different technologies. Some of the things I worked on looked really scary at first, but as I went nearer and read more code the mist slowly vanished.

My mentor, Toshio Kuratomi was great as always. This isn’t the first project I’ve had him as my mentor. He was always there to talk to and always had great answers to all of my questions. He had great patience in answering and explaining anything I asked about. Our discussions were mostly about the architecture of the app we were building, but he also gave me great tips on the inner workings of python-fedora or on deploying the web app. I felt I had a lot of liberty to decide the way things will get implemented. Regardless of whether we will ever work together again, Toshio will always be a great inspiration for me as a programmer and as a person.

Comments

Fedora Summer Coding midterm

This midterm scared me when I found out about it on Friday when I looked at the schedule I had set myself. However, I have done the work that I should have done by this point in the project. When I wrote the proposal I had assumed that the buildsystem would already be built before me starting coding on the TG app, but that is not the case. Therefore I could only code the user-facing JSON interface that interacts with the DB as it would if the buildsystem would provide it with packages and repos. Except that there are no packages and repos at this stage.

So for this midterm, we’ve got working Copr CRUD, dependency handling and release/repo editing on a Copr. I also coded the Package CRUD, which basically allows for uploads of SRPMs, stores the info in the db and also allows for information retrieval and deleting packages. Actually building packages and retrieving packagebuilds will have to wait for the buildsystem to be built.

After I finish polishing things a bit, I will probably start working on a basic client and then maybe move on to working on the buildsystem part of Copr. That should be loads of fun especially since I haven’t done anything quite like this before. So it will be hard, but fun :).

If anyone wants to check out what Copr looks like so far, you’ll just have to install TurboGears 2.0.x and then:

 $ bzr branch bzr://bzr.fedorahosted.org/bzr/copr/devel
 $ cd devel
 $ python setup.py develop
 $ paster setup-app development.ini

And you should have a working Copr. You can run the unit tests with the nosetests command and all 52 of them should run fine. Yay!

Congratulations to everyone who is finishing their FSC adventure today! I’ll still be coding for another month or so.

Comments

Copr design - being all things to all people

Lots of things happened this third Fedora Summer Coding week. Most people are already wrapping up, but I feel like I’m still at the beginning.

The biggest accomplishment of this week has got to be the fact that we (I and my mentor, Toshio) settled on a stable design for representing Coprs, Repos and their relationships. It was harder than it might seem, since we’ve got all these different entities in Fedora: we’ve got repos that you could look at as being either a directory with a release and an architecture or a repofile that is the same across releases and arches. When talking about releases we’ve got Fedora releases (e.g. Fedora 13, Fedora 14) and then we’ve got the packages for other distros with their own releases: EPEL and OLPC.

Now, on top of all of this we’ve got Coprs and (at least) two groups of users for the API: the end-users of the Coprs – the people that install the repos and the packages and the developers of the packages in the Coprs. The end users shouldn’t have to deal with the intricacies of the Copr/Repos/Releases model; ideally they’d just have one big button per the distribution they’re using, so they can install the repo once and have it work even after they’ve upgraded their distro three times or reinstalled five times (which is sort of how a repofile works). The package developers on the other hand could get hurt by the differences between different distro releases and their different packages – when depending on different package versions for example.

So finally we get to Coprs which should basically be a collection of packages that are available for one or more distros with each one having one or more releases. The package maintainer gets to create a Copr and choose a number of releases which they want to support with that Copr. One Copr can depend on as many other Coprs as needed. When the maintainer creates a Copr, the Copr App will automatically create repos for all of the specified releases and for each of the architectures that are supported by the buildsystem.

Everything I said until now is already implemented at the level of the TurboGears App which will provide the API for the web interface and any number of JSON clients. The schema is built and the database insteraction works fine, but repos don’t actually get created, because that’s not part of my proposal and will be handled at a different level. Oh and it’s all unit tested!

This week wasn’t just designing and building though, I spent a lot of time digging through TurboGears2 and its sub-packages’ documentation for things that should make the code simpler: raising JSON errors from nested functions, sending list arguments to JSON functions via WebTest post requests and even returning a flat list from a SQLAlchemy query on a single table column. All of these things seem to me like they should already be implemented and easy to use which makes me waste time searching for them. In fact they either are bugs or require coding them myself (at least from what I understand so far). I’ll have to investigate further, especially now since the weekend is over and I hope there’ll be more people answering questions on IRC and on issue trackers.

This next week I’ll mostly start worrying about what happens when a package maintainer submits a package to be built and that package has the right dependencies available in some releases, but not others, even though the Copr should support all of them. Will she have to submit different SRPMS for each release or should the Copr have the same version of the package in all of its releases? This will be a matter of settling upon a contract that the Copr provides its users and how uniform the Copr’s content has to be.

Fedora Summer Coding! Yay!

Comments

CRUD for Coprs and testing

This last week I worked on the first controller for the Copr TG App. There is now a JSON API to CRUD Coprs in the TG App’s database. It also supports adding/removing Copr dependencies. And everything in this first controller is (mostly?) tested with nose unit tests. The happy thing is I’m still on schedule, though I’m not ahead of it anymore, which I actually expected.

I encountered a couple of problems while setting up testing. I installed python-fedora’s FAS authorization repoze-who plugin and wasted a lot of time trying to get that working with webtest. In the process I managed to screw up something in my TurboGears installation. Since I was already too deep down the rabbit’s hole I gave up on it. (I also figured out that I don’t actually need to test anything about the FAS integration so I don’t even need to install it). So I proceeded to install TG2 inside a python virtualenv which feels a lot more hygienic and will be a lot easier to replace in case of future screw-ups. I had a few problems there aswell since the documented way to install TurboGears2 without distro-packages is broken ATM, but I now have virtualenv! Yay!

Now the next step is to figure out the right relationship between Coprs and Repos and write some code to manage Repos transparently for the user. I also have to learn to write more frequent status updates.

Comments

The late Fedora Summer coder

I started my Fedora Summer Coding last week. Although most people started almost two months ago, I chose (and was allowed to – Yay, FSC!) a different schedule because I just finished college last week.

This summer I’ll be working on a new project for Fedora – Copr. Fedora Copr will allow any Fedorian to have their own package repository with packages built and hosted by Fedora’s Infrastructure. My mentor this summer will be Toshio, I’ve always enjoyed working with him and this summer will be no different. Here is my actual FSC proposal. Although the things written in that proposal are turning out to be a bit inaccurate, it’s still a good bird’s eye view of what I’m going to do this summer.

So about the first week. Things started really slow. I did a lot of orientation, certainly more than I thought I would. I hadn’t used TurboGears2 before, though I had worked with TurboGears 1.x on Fedora’s pkgdb. When I started out I had only a TG2 automatically generated skeleton app – well it’s mostly the same now, though at least I now know a lot more about what’s in there. The fact that I had to start it up myself meant I had to learn a lot of things about TG2 that I would’ve normally just copied from other parts of a fully-functional project. And that was a great experience. In a way it’s fulfilling to be able to pioneer things in this way ;). I’m trying to only ask my mentor questions about designing the actual app and solve my “How do I … in TurboGears/Python?” questions elsewhere. My mentor has always given me a lot of independence when working on things and that feels really good, though at times I feel inexperienced. There’s the thought that the project I’m working on will be used by a lot of technical users and I’m really not sure what my decisions’ impact will be on the whole project.

I’m mostly on time with my mock-up schedule because I had set the first week for orienteering. I also wrote the DB schema for Coprs, though that was on the second week. That doesn’t mean I’m ahead of schedule however, because I’ll probably have a lot to work on the Copr controllers, and a lot of documenting and designing.

I’m proud that I setup testing after a day of wading through the scattered documentation of TurboGears2 testing. There’s mostly no documentation on testing on the TurboGears2.0 docs website. So I went to the python nose webpage. But they don’t have any info on the TurboGears2 web helpers which I needed to use. So I went to pylonshq docs about testing, but they use a slightly different syntax because they’re using paste.fixture. I finally found the TurboGears2.1 testing docs which was what I really needed. It turns out that TurboGears 2.x uses WebTest.

So now I have testing. My project is not supposed to have any web interface at this point, so writing tests is the easiest way to prove that things are actually working.

This next week I’ll probably get some work done on Copr controllers. Implementing the ability to CRUD Coprs and Repos.

Comments

Beginning packaging for Fedora

With GSOC now over, which I should write a blogpost about soon, I’ve taken a break from pkgdb and web programming and started developing another skill.

The fact that this page is empty has been bugging me for too much time, so I set out to fix it. I also wanted to find out more about the packaging process and the road of a package before it gets accepted into fedora’s official repos which is a bit complex. This knowledge would also help me better understand the parts of pkgdb which packagers interact with.

It was not my first time trying to make a package for fedora. I think this is actually my third time. I’d given up before, scared by all the different tools and scattered documentation. In a previous life, I had made some AUR packages, but the experience is a lot different. I’m now starting to get used to all the different tools that I was scared of before, like mock and rpmlint and I can now find my way around the fedora wiki for package related information. There is a wealth of information in the wiki, but you need a lot of patience.

I started slow, with quite a complex application to package: Calibre. Having all those different distros is great when you’re a packager, because you have somewhere to look for help and the Debian package of calibre helped me a lot. It took me about two days to get a somewhat acceptable version of calibre packaged, which I then posted to redhat’s bugzilla. The following days I found more small apps to be packaged and it became easier and easier for me to do it. Last night for example, I was just browsing Hacker News as usual when I found a link to facebook’s opensourcing of their web server framework . I just rushed to the download and installation instructions page and I quickly got it packaged. I’m not saying it’s perfect, it probably needs a lot of improvement, but it was fun to do. It’s fun to think that you’re making things easier for someone and learning a lot at the same time. I now have 5 packages waiting to be reviewed and I’ve found someone willing to sponsor me into the packager group. Anyone in a package-review mood? ;)

My journey into the packaging world has been enlightening so far and the good thing is I’m just beginning. There’s a whole new world to be discovered out there and also another part of the fedora community.

Comments

FUDCon Berlin

I just got back from this year’s EMEA FUDCON in Berlin with Nicu . I didn’t have time to write anything while I was there because so much was happening all the time.

FUDCon and LinuxTag

LinuxTag wasn’t really the purpose of our visit, but we got free tickets so I checked the place out for a while. There were lots of booths and some speeches (mostly in German). There were also some activities, but I really didn’t get to any of them since most appeared to be German-only. I was a bit disappointed, eLiberatica had way better talks and guests.

FUDCon was nice. The first day was a little slow to start, but the BarCamp session the next day was very interesting and diverse. More of that would’ve been nice. Some of the cool topics I enjoyed were: koji at CERN, git for hackers, Fedora EKG and UI Design. The last day was mostly random hacking by people who already had something to work on. I did a bit of pkgdb hacking on my own and then went Berlinxploring.

Berlin

The city was awesome. I haven’t been to a lot of different countries, but right now Berlin is my favourite. Its public transportation is awesome, the people are polite, friendly and everyone can speak English. There were a lot of trees everywhere, the temperature was really cool and there were wild bunnies in the parks! I separated from the crowd two times to go visit the city and I got to see some stuff I would’ve missed otherwise. It was also cool because what I did was basically ride the train and get off whenever I would see something interesting. I went to the Brandenburg gate and the Governmental district and also got a closer look of the bombed church. I also went to a cool flea market.

German Beer

The best part of the whole conference were the nights out at the restaurant, I think. I and Nicu were lucky to tag along to a few people from Red Hat before the majority of people had arrived. We got to see some nice places that way, especially thanks to Jesse’s iphone. I got to eat indian food, assembly line sushy and we were also at the local Zoo. I soon found out that my English was a bit slow and so I couldn’t keep up with their constant witty joking so I sort of gave up and switched into listening mode.
The nights-at-the-restaurant got better and better as more people arrived. We went to a small restaurant right under the railways for free pizza (thanks Red Hat!) where I met a few of the newly arrived people and had some interesting chats mostly about fedora and Red Hat.
The next day we went looking for a Sudanese restaurant, but ended up at a Cuban restaurant with cool waitresses. I got to taste the first real German beer and socialised with some of the other European guys which was really fun.
The last night was the best night. We had interesting discussions about fonetics(!), German beer, the Dutch language and RMS among other things. They also had the greatest dark German beer, which I forgot the name of. Real traditional German beer really doesn’t compare with any other beer. It’s a whole different beverage and an awesome one.

Conclusion

Overall I think it was a great experience. I got to meet a lot of interesting and smart people from all over the world who all shared a passion for their work and for Fedora.
So these are sort of the words to Nicu’s photos which explain the rest, only better.

Comments

eLiberatica - the aftermath!

Wow, what an event! It was way more awesome than I expected. This is probably one of the later posts to get to the planet from eLiberatica because I wanted to form a complete opinion on the event.

eLiberatica is the first big open source and free software conference I’ve been to. The scale of it is quite amazing for something this far East in Europe and especially for my country. Some high-profile guest even said that he was astonished at the presence of very influential, key FLOSS personalities that aren’t present at some bigger events.
the booths

We (ajoian , nicubunu, alexxed and myself) had a whole booth for fedora and we really made the best of that opportunity, I think. We had a lot of SWAG. Nicu had printed some posters for the event which really helped beautify the booth and had also printed some fedora business cards for each of us. We had fedora t-shirts and a lot of CDs sent by Max (thanks Max!). These were the most helpful for starting conversations with passers-by. We even helped out the Ubuntu people when they ran out of cds on the first day!

The booth activity was more fun than I had expected. I didn’t think I would enjoy talking to people about fedora so much. We had people ask us to come to their town and “do something about fedora”. We told them we’d come and hold presentations when they would be ready and we gave them some free LiveCDs to spread around in the meantime. I hope we’ll have some new local fedora communities spring up. I’m especially hopeful of the guys from Iași who are active contributors to different opensource projects, mostly xwiki .

There were two other cool booths that were very engaging with the passers-by: the Mozilla booth and the Romanian Free Software Communities booth which was more of an Ubuntu booth actually, but that was good since a lot of people were interested in that.
the speakers

I only went to a few speeches as the booth activity and the new people I met were too engaging. I think Jeroen‘s speech was awesome and his message was very clear. It was a great complement to the discourse we were holding at the booth – telling people that fedora is all about contributing, not just using a stable, already tested linux distribution. A lot of people were ubuntu users, especially the ones in the Politehnica University (the host of the event) who are taught Ubuntu in class (there are no linux machines at my university :| ). Everyone kept asking how fedora is better than ubuntu. It was an honest question since many of them didn’t have experience anything else and I hope we succeeded in getting our message accross.

There were other awesome people, too. There was Monty – the founder of MySQL who told us about his new project to give MySQL back to the community: MariaDB . There was the president of fsfe and the OpenSource Diva – Danesse Cooper who both gave great philosophical speeches. There was David Axmark who had a great presentation about his awesome new project to create a stripped-down version of MySQL for webshops called Drizzle – I think this will be a great project to watch evolve. I didn’t get to spend too much time on the openagile track, but I went to Corey Haines ‘s talk about software craftsmanship in an agile context which I enjoyed.
the friends

contributors
The most awesome part of the entire conference, I think, were the people I met. There were a lot of people I only knew from online discussions. Some of them I had known for years, but had never met. I had a revelation with a couple of people who I didn’t like online, but prooved to be very nice people in real life.

I met some fellow Romanian Google Summer of Code guys for this year and last year with whom I hope to meet again.
I met a few Eau de Web guys – a small python/zope web company especially Alex who’s blog I had been reading and who turned out to be an even cooler guy than I expected. We discussed a lot of interesting python things. (I almost got him to switch from his OS X + virtual Debian setup to fedora. But I hope I’ll have another swing at it soon).
I met an old friend, Vlad who gave me an awesome idea for an enhancement to the fedora business cards that I’ll hopefully have time to implement this summer.
The guys from the other Romanian communities were cool people and I hope we’ll interact better and do more awesome FLOSS stuff now that we’ve met face to face. These were people from Software Liber, rosedu and the cool lonely guy from openSUSE Romania who had a taste of our fedora CDs, literally (the opensuse community is just starting out in Romania).
Last, but not least, the Romanian Fedora community was awesome. We got along really well and had a lot of fun. We made some really nasty videos with the fedora sign that I was going to post, but I changed my mind when I actually looked at them :), you can look at nicubunu’s pictures, though.
miscellaneous

I added 3 more O’Reilly books to my I hope I’ll read them this summer reading list: Beautiful Code, Masterminds of Programming and SQL and the Relational Theory.

This conference and the people I talked to really influenced me I think, career-wise. I got a lot of motivation and a great yearning to sometime be able to work with people such as the ones I met there. I’ll probably slip into a bit of a depression now that the event is over and I’m going back to real life and ignorant school people. That’ll hopefully be over in less than two weeks and I’ll have time to work work work == fun fun fun for the Fedora Project.

The good news is I’m going to FUDCon Berlin with Nicu. I hope to meet a lot of cool fedorians there aswell.

Comments

Fedora Business Cards

A few days ago, me and a few friends from Fedora Romania decided we’d like some fedora business cards for the upcoming eLiberatica conference. Ian Weller had already developed an official template and even created a cool python generator script and packaged it.

The problem, however, was that it only supported US-style business cards which are a bit smaller than the Romanian/Central European ones. Live and learn… It seems that there are a lot of different sizes actually.

So I got my hacking hat and dived in. The code was quite nice to look at and easy to understand. The XML in the svg templates is quite easy to hack, too. Especially when using tools like python’s minidom . It makes working with python and XML taste like javascript dom manipulation which is quite nice.

Everything went smooth, I renamed a few tags, made some modifiable (for height and width), but then I had to make the blue strip on the right of the front of the business card extendable1 . There is no way in XML to align an element to the right so I spent about an hour coming up with a sweet solution. Instead of having a big white background on which I would apply the blue band, I made a big blue background and made the white background just a little narrower. Because the white background was on top of the blue one, it could get aligned to the left (x=0, y=0 in XML) and cover just the part that needed to be white, and left a blue band at the right. Problem solved. Hoo-grah!

Now I’m waiting for an answer to the patch that I sent to bugzilla. Hopefully it’ll be accepted and will be available in Fedora, soon, so that others may enjoy and cherish the coolness that it be!

Comments

GSOC - it begins...

My Fedora proposal got accepted to this year’s Google Summer of Code Program. You can look at a short abstract here . Now I’m going to try to explain what this project is about and what I did to prepare for being accepted, hopefully without going mad about how happy I am about it.

I started work on the Fedora Project almost a year ago. One day I popped on the mailing list and then on the irc channel of the infrastructure team and asked for something to do. Luckily, Toshio Kuratomi was on the watch and after giving me a short tour of the various projects he could help me get familiar with, I picked the package database. Most of the work I’ve done so far is in the pkgdb (the search capability is the most obvious thing I worked on). The overview on the front page describes it quite well; it’s got package information and it’s aimed at package developers. It’s not a very famous part of the fedora project websites, certainly not as famous as something like packages.ubuntu.com is for ubuntu. But that’s not what it was intended for, even if that’s what attracted me to the project at first. I liked the exposure of such a website, but also the fact that, at the time, it was easier for me to understand what it did and how it worked :).

The idea of making the package database more user-friendly as opposed to developer-centric wasn’t a new one. Toshio, the main developer had been thinking about it for a long time, but I guess it never really became a priority. The idea had also been proposed for last year’s GSOC, but it hadn’t been accepted (this scared me a bit when I found out). I picked this idea on a whim when I told Toshio I wanted to participate in this year’s GSOC on pkgdb and he asked me what exactly I wanted to do. I wasn’t expecting the question, so I answered with the first thing that came to mind. Looking back, I think it was a good choice.

All my involvement with the Fedora Project owes a lot to the best possible person who could have become my mentor for GSOC. The Infrastructure Team is a great one to work with, and the Fedora contributor community is made up of a lot of smart, fun and selfless people. I say this after having spent a lot of time lurking the IRC channels, the various mailing lists, the planet etc. and to a somewhat lesser extent interacting with other contributors. However, I wouldn’t have continued contributing if it weren’t for the continuous support and guidance of Toshio. I probably wouldn’t have been able to participate in the GSOC without the many discussions (starting in February) with Toshio about the proposal and the support when explaining the idea to other community members. Having said that, I think that being familiar with the pkgdb also helped a lot with writing the proposal. I didn’t have to waste time on getting to know the code, the community, the devs as I would have if I had written a proposal for a different project. I also had a fair idea of what would constitute a good proposal and a rough idea about how it could be implemented. I think this helped with my credibility in the eyes of the mentors who ranked my proposal.

I was never convinced I would get a spot on Fedora & JBoss’s accepted proposal’s list , but it was is a great thing to dream of. The butterflies in my stomach were killing me at the end of the waiting period, especially since it had lasted for more than 2 months. I now have a summer to work full time on my hobby :).

At the end of the summer, the fedora community will hopefully have a package database with package versions, size, dependencies, rss feeds, tagging, package reviews etc. There’s even a detailed schedule from my proposal you can drool on if you’re so inclined.

And hello, fedora planet! Sorry for being late.

Comments
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.