So, the GSoC is over. During the summer the project changed form the initial vision quite a bit. Instead of being a simple standalone profile editor, the lockdown solution I’ve been working on requires some changes in:
- Accountsservice, where the changes are in gitorious for now.
Status — everything seems to be working, except role path validation. - Gnome control center (code tarball), where I did the work on the older version that ships with Ubuntu 12.04.
Status — as of this moment unusable. Setting and getting lockdown profiles for existing users is there, but creating a new user with profile is not functional and some polish is needed for smooth UX. - The lockdown editor itself (code tarball).
Status — Totally unusable. Very early prototype.
As a GSoC project it would be hard to call it a success. The main item — the lockdown editor itself — did not materialize.
Pitfalls during the project
- Knowing a programming language doesn’t help much if you don’t know the libraries. I thought I knew data structures in C, but glibc has its own ideas about everything and this was a new thing to learn.
Solution — get to know the environment before taking up the task. - Moving targets. At the beginning of this project, there was just the lockdown editor, now it is a lockdown delivery system, where the editor itself is not really that important. It is hard to stick with a floating schedule.
Solution — before making a proposal, talk with interested parties and find out what they want. - Exams and GSoC don’t blend well. One month of the GSoC period was wasted in exams.
Solution — start working on the project before the GSoC even starts to get some breathing space. - Working with the cutting edge cuts badly. During the project several times I tried to get gnome-control-center to compile with jhbuild. Most of the time it failed to compile (to get to g-c-c, about 100 modules must be compiled beforehand). The only time it did compile, it crashed and burned.
Solution — if you are not an expert in the environment, don’t work with master.
In short — don’t just jump in with proposal in the last minute. It will hurt.
Interesting things I learned
- GOTO statements are OK in some situations.
- Code comments are not really necessary. Just read the code and an epiphany will hit you. </sarcasm>
- Sometimes pre-existing code is like math — you don’t understand it, you just get used to it.
Future perspective
For this all to have any meaning at all, these things have to happen:
- distributions must ship with the new accountsservice, which is not even merged upstream (quite likely to happen);
- changes made in g-c-c must be merged in master (should be possible with some pain);
- gdm should support all this lockdown sorcery (yes, I didn’t mention gdm before, but someone will have to code the support for all this);
- distributions should have the these packages included (like Ubuntu, which just loves to ship the latest gdm. Or was it lightdm? Oh my!</sarcasm>).
In short, these changes will most likely not see daylight in the next round of distribution releases.
Conclusion
By normal project criteria, my project has failed, but in its new form it seems more useful than at the beginning. It is behind schedule, but I expect this to be working as intended in the 3.8 GNOME release.
Pingback: The 2012 Google Summer of Code fruits! | woGue
Sounds like the project hasn’t failed, but is a solid work in progress. Sorry if it didn’t get there as far as GSoC is concerned though. But there’s lots of us eagerly anticipating the features you’re working on