Please! Help us to attend #LGM2013 We're really close to our goal! http://t.co/xG9J7DE1 #freeSoftware #animation #2D

This post is part of the Unity daily release process blog post suite.

After a week to let people ask questions about the daily release process, I guess it's time to catch up and conclude this serie with a FAQ and some thoughts for the future.

FAQ

The FAQ is divided in multiple sequences depending on your role in the development of ubuntu, with the hope that you will be able to find what you are looking for quicker this way. If you have any question that isn't addressed below, please ping didrocks on IRC freenode (#ubuntu-unity) and I'll complete this page.

Upstream developers What's needed to be done when proposing a branch or reviewing?

As discussed in this part, when proposing a branch or reviewing a peer's work, multiple rules have been established. The developers needs to:

• Design needs to acknowledge the change if there is any visual change involved
• Both the developer, reviewer and the integration team ensure that ubuntu processes are followed (UI Freeze/Feature Freeze for instance). If exceptions are required, they check before approving for merging that they are acknowledged by different parts. The integration team can help smooth to have this happened, but the requests should emerge from developers.
• Relevant bugs are attached to the merge proposal. This is useful for tracking what changed and for generating the changelog as we'll see in the next part
• Review of new/modified tests (for existence)
• They ensure that it builds and unit tests are passing automated
• Another important one, especially when you refactor, is to ensure that integration tests are still passing
• Review of the change itself by another peer contributor
• If the change seems important enough to have a bug report linked, ensure that the merge request is linked to a bug report (and you will get all the praise in debian/changelog as well!)
• If packaging changes are needed, ping the integration team so that they acknowledge them and ensure the packaging changes are part of the merge proposal.

When you approve a change, do not forget to check that there is a commit message in launchpad provided and to set the global status to "approved".

When do changes need to land in a coherent piece?

Some changes can happen and touch various components (even across different stacks). To avoid loosing a daily release because only half of transition landed in some upstream projects (and so, tests will fail because they catch this issues, isn't it? ;)), it's asked to ensure that all transitions are merged by 00 UTC. Then, you can start approving again transition starting from 06 UTC. We can try to make this window shorter in the future, but let's see first how this work in practice. For any big transition, please coordinate with the ubuntu-unity team team so that they can give a hand.

I have a change involving packaging modifications

As told in a previous section, just ask for the ubuntu-unity team to do some review or assisting in doing those changes.

I want to build the package locally myself

If you have done some packaging changes, or added a C symbol, you maybe want to ensure that it's building fine. Quite simple, just go into your branch directory and run $ bzr bd (from the bzr-builddeb package). This will build your package on your machine using the same flags and checks than on the builders. No need to autoreconf if you are using autotools, everything is handled for you. You will get warned as well if some installed files are missing.

I need to break an API/ABI

The first question is: "are you sure?". Remember that API changes are a PITA for all third parties, in particular if your API is public. Retro-compatibility is key. And yes, your dbus interface should be considered as part of your API!

If you still want to do that, ensure that you bump your soname if the ABI is broken, then, multiple packaging changes are needed. Consequently, ensure to ping your lovely ubuntu-unity team to request assistance. The transition should happen (if no retrocompatibility is provided) within the previously mentionned timeframe to have everything landing in coherence.

You also need to ensure that for all components build-depending on the API you changed, you bumped the associated build dependency version in debian/control.

To what version should I bump the build dependency version?

Let's say you added an API to package A. B is depending on A and you want to start using this new awesome API. What version should be used in debian/control to ensure I'm building against the new A?

This is quite easy, the build-dependencies in debian/control should look like: A >= 6.0daily13.03.01 (eventually ended by -0ubuntuX). Strip the end -0ubuntuX and append then bzr<rev_where_you_added_the_api_in_trunk>. For instance, let's imagine you added the API in rev 42 in trunk, so the build-dep will change from:

A >= 6.0daily13.03.01

to:

A >= 6.0daily13.03.01bzr42

This is to ensure the upstream merger will be able to take it.

If no "daily" string is provided in the dependency you add, please check with the ubuntu-unity team.

I'm exposing a new C symbols in my library, it seems that some packaging changes are needed…

Debian packages have a debian/<packagename>.symbols file which lists all exposed symbols from your library (we only do that for C libraries as C++ does mangle the name per architecture). When you try to build the package containing a new symbol, you will see something like:

--- debian/libdee-1.0-4.symbols (libdee-1.0-4_1.0.14-0ubuntu2_amd64)

+++ dpkg-gensymbolsvPEBau 2013-02-05 09:43:28.529715528 +0100

-4,6 +4,7

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

+ dee_analyzer_get_type@Base 1.0.14-0ubuntu2

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The diff shows that debian/libdee-1.0-4.symbols doesn't list the exposed dee_analyzer_get_type new symbol. You see a version number next to it, corresponding to the current package version. The issue is that you don't know what will be the package version in the future when the next daily release will happen (even if you can infer), what to put then?

The answer is easier than you might think. As explained in the corresponding section, the daily release bot will know what version is needed, so you just need to give a hint that the new symbol is there for the upstream merger to pass.

For than, just include the symbol, with 0replaceme[1] as the version for the branch you will propose as a merge request. You will thus set in your symbols file:

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

dee_analyzer_get_type@Base 0replaceme

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The dee_analyzer_get_type@Base 0replaceme line will be replace with the exact version we release in the next daily release.

My name deserves to be in the changelog!

I'm sure you want the world to know what great modifications you have introduced. To get this praise (and blame ;)), we strongly advise you to link your change to a bug. This can be done in multiple ways, like link bugs to a merge proposal before it's approved (you link a branch to the bug report in launchpad), or use "bzr commit --fixes lp:XXXX" so that automatically links it for you when proposing the merge for reviewing, or put in a commit message something like "this fixes bug…". This will avoid the changelog to have only empty content.

I invite you to read "Why not including all commits in debian/changelog?" from this section to understand why we don't include everything, but only bug reports title in the changelog.

Ubuntu Maintainers I want to upload a change to a package under daily release process

Multiple possibilities there.

The change itself can wait next daily release

If it's an upstream change, we strongly advise you to follow the same procedure and rules than the upstream developers, meaning, proposing a merge request and so on… bzr lp-propose and bzr branch lp:<source_package_name> are regularly and automatically adjusted as part of the daily release process to point to the right branches so that you can find them easily. Vcs-Bzr in debian/control should point to the right location as well.

Then, just refer to the upstream merging guidelines above. Once approved, this change will be in the next daily release (if tests pass).

An urgent change is needed

If the change needs to be done right away, but can wait for a full testing round (~2 hours), you can:

• Propose your merge request
• Ping someone from the ubuntu-unity team who will ensure the branch is reviewing in priority and rerun a daily release manually including your change. That way, your change will get the same quality reviews and tests checking than anything else entering the distro.

It's really urgent

You can upload right away your change then, the next daily will be blocked for that component though (and only for that component) until your change reaches upstream. So please, be a good citizen and avoid more churn in proposing your change back to the upstream repo (including changelog), pinging the ubuntu-unity team preferably.

I'm making a change, should I provide anything in debian/changelog?

Not really, as mentioned earlier, if you link to a bug or mention in a commit message a bug number in your branch before proposing for review, this will be taken into account and debian/changelog will be populated automatically with your name as part of the next daily release. You can still provide it manually and the daily release will ensure there is no duplication if it was already mentionned.

If you provide it manually, just: dch -i and ensure you have UNRELEASED for an unreleased version to ubuntu (without direct upload).

ubuntu-unity team

Note that in all following commands, if -r <release> is not provided, "head" is assumed. Also, ensure you have your credentials working and be connected to the VPN (the QA team is responsible for providing those jenkins credentials).

Where is the jenkins start page?

There it is.

Forcing a stack publication

After reviewing and ensuring that we can release a stack (see section about manual publication causes, like packaging changes to review or upstream stack failing/in manual mode). Then run:

$ cu2d-run -P <stack_name> -r <release>

example for indicators, head release:

$ cu2d-run -P indicators

Remember that the master "head" job is not rerun, so it will stay in its current state (unstable/yellow). The publish job should though goes from unstable/yellow to green if everything went well.

Rerun a full stack daily release, rebuilding everything

$ cu2d-run -R <stack_name> -r <release>

Rerun a partial stack daily release, rebuilding only some components

$ cu2d-run -R <stack_name> -r <release> <components>

/!\ this will keep the state and take into account (failure to build state for instance) and the binaries packages for the other components which were part of this daily release, but not rebuilt.

for instance, keeping dee and libunity, but rebuilding compiz and unity from the unity, head release stack:

$ cu2d-run -R unity compiz unity

The integration tests will still take everything we have (so including dee and libunity) at the latest stack with the new trunk content for compiz and unity when we relaunched this command.

Rerun integration tests, but taking all ubuntu-unity ppa's content (like transition needing publication of the indicator and unity stacks):

$ cu2d-run -R <stack_name> -r <release> --check-with-whole-ppa

This command doesn't rebuild anything, just run the "check" step, but with the whole ppa content (basically doing a dist-upgrading instead of selecting only desired components from this stack). This is handy when for instance a transition involved the indicator and unity stack. So the indicator integration tests failed (we don't have the latest unity stack built yet). Unity built and tests pass. To be able to release the indicator stack as well as the unity stack, we need the indicator stack to publish, for that, we relaunch only the indicator tests, but with the whole ppa content, meaning last Unity.

In that case, the publish for the indicators will be manual (you will need to force the publication) and as well, you should ensure that you will publish the unity stack at the same time as well to have everything in coherence copied to the -proposed pocket. More information on the stack dependency in this section.

Adding/removing components to a stack

The stack files are living in jenkins/etc/. This yaml file structure should be straightforward. Note that the tuple component: branch_location is optional (it will be set to lp:component if not provided). So add/change what you need in those file.

Be aware that all running jobs are stopped for this stack.

$ cu2d-update-stack -U <path_to_stack_file>

This will reset/reconfigure as well all branches, add -S if you don't have access to them (but ensure someone will configure them still at least once)

Different level of failures acceptance.

We do accept some integration tests failing (no unit tests should fail though as ran as part of package building). The different level of those triggers are defined in a file like jenkins/etc/autopilot.rc. Those are different level of failures, regressions, skipped and removed tests per stack. The real file depends on stackname and are found in $jenkins/cu2d/<stack_name>.autopilotrc as described in the -check template.

Monitoring upstream uploads and merges

Remember to regularly look at the -changes mailing list to pick if a manual upload has been done and port the changes back (if not proposed by the ubuntu developer making the upload) to the upstream branch. The component which had a manual upload is ignored for daily release until this backport is done, meaning that no new commits will be published until then (you can see the prepare job for that component will turn unstable).

Also, ensure as you are watching all upstream merges to follow our acceptance criterias that the "latestsnapshot" branches generated automatically by the daily release process has been merged successfully by the upstream merger.

Boostrapping a new component for daily release

A lot of information is available on this wiki page.

Conclusion

Phew! This was a long serie of blog post. I hoped that you appreciated to have a deeper look of what daily release means, how this work, and also that the remaining questions have been answered by the above FAQ. I've just ported all those information on the https://wiki.ubuntu.com/DailyRelease.

Of course, this is not the end of the road, I have my personal Santa Claus wishlist like UTAH being more stable (this is under work), the daily image provisionning with success more often than now, refactorisation work taking integration tests into account, less Xorg crashes when completing those tests… This is currently adding a little bit of overhead as of course, any of this will reject the whole test suite and thus the whole stack. We prefer to always be on the safe side and not accepting something in an unknown state!

Also, on the upstream stack and daily release process as well, there are rooms for improvments, like having less upstream integration tests failing (despite awesome progress already there), I wish I can soon turn that down to 3% of accepted failure at most for unity instead of the current 7% one. Dedicated integrations tests for indicators would be awesome as well (stealing the unity ones for now and only running those involving indicators, but of course, not everything is covered). Having also some oif, webapps and wecreds integration tests is one of my main priority, and we are working with the various upstream developers to get this done ASAP so that we have a better safety net than today. On the daily release process itself, maybe freezing all trunks in a go would be a nice improvement, more tests for the system itself as well is under work and my personal goal to reach 100% test coverage for the scripts before making any additional changes. Finally, some thoughts for later but a dashboard would enable to have a higher view than just using jenkins directly for reporting, to get a quicker view on all stack statuses.

Of course, I'm sure that we'll experience some bumpy roads with this daily release process through the cycle, but I'm confident we'll overcome them and I am really enthousiast about our first releases and how smoothly they went until now (we didn't break the distro… yet :p[2]. I'm sure this is a huge change for everyone and I want again give a big thank you to everyone involved into that effort, from the distro people to upstream and diverse contributors on the QA team. Changing to such a model isn't easy, it's not only having yet another process, but it's really a change of mindset in the way we deliver new features and components to Ubuntu. This might be frightening, but I guess it's the only way we have to ensure a systematic delivery, continuous and increasing quality while getting well a really short feedback loop to be able to react promptly to the changes we are introducing to our audience. I'm confident we are already collecting all the fruits of this effort and going to expand this more and more in the future.

For all those reasons, thanks again to all parties involved and let's have our daily shot of Unity!

I couldn't finish without a special thanks to Alan Pope for being a patient first reader, and fixing tediously various typos that I introduced into the first draft of those blog posts.

Notes

[1] "0replacemepleasepleaseplease" or anything else appended to 0replaceme is accepted as well if you feel adventurous

[2] fingers crossed, touching wood and all voodoo magic required

Opening up state legal data #OpenGov http://t.co/UP9Pjbh9 How a #FreeSoftware can help : https://t.co/QGWlCAQD

I love LibreCAD :D http://t.co/KnjOTybM #freesoftware #opensource #cad

Since I upgraded to Firefox 18, I’ve had blurry fonts on some sites, including Twitter and YouTube. Today I looked a bit into the problem, and found a solution in the Firefox Support forum.

In about:config, edit keys in the following way:

1. Set layers.acceleration.force-enabled to true
2. Set layers.acceleration.disabled to false

Thanks for juanbaez for the tip!

If you don’t want to edit your configuration, I read that this is fixed in Firefox 19 as well. Downgrading to Firefox 17 reportedly works as well.

Year ago we had Linaro Connect right after FOSDEM so I decided to skip and walk to Golden Gate instead. But this year there were no conflicts!

Months before we had discussion on SzLUUG mailing list about who goes for FOSDEM. There were about 9 people wanting and we ended with five. So on Friday morning friends arrived near my house, I jumped into car, we grabbed 4th one (Tomek was in London at that time) and went to Berlin Schönefeld airport for 07:00 Easyjet flight.

And we missed it… 5-10 minutes late we were ;( 75€ per person and 10 hours later he took off from SXF airport.

But that 10h was not wasted. Berlin has very nice Technical Museum with many trains, cars, planes and other exhibitions. And they had Trabant 601 as well:

Then trip to shops (Saturn, Media Markt) in search for HTC Desire X case (Magda) and LG Nexus 4 (me). Avoid Saturn — they do not handle credit card payments at Alexanderplatz so I had to walk to the ATM. Two S-Bahns later we passed security check and went to the gate early enough to fly.

BRU airport… I think that (with exception of SXF/TXL) it is my most visited airport as it was my 5th FOSDEM and there was UDS-M around as well. But this time we took a bus instead of a train. 14€ ticket works for 72 hours so cover all trips perfectly. Few hours later we were joking that this multi country journey was exhausting as we were in Berlin, Brussels, went though Geneve (bus stop) to Luxembourg (square) and passed near London (restaurant) ;D

Hotel, drop stuff, connect chargers, went for beer event. Crowdy as usual it was. But I managed to meet some friends (but also missed lot of them) and grabbed few beers. Good spent time. Too bad that I was so tired that went back to hotel just right after midnight.

Saturday

Breakfast in St. Nicolas hotel maybe is not the best but provides enough energy to survive a day. Met several guys there, Philip gave me Kindle Paperwhite which I bought few days before (with delivery to his house to lower price) and his famous Belgium/Holland/Luxembourg guidebook. I also got Beagle pendrive from Koen.

Then overcrowded bus 71 and FOSDEM! I told Bartek where things are (but at that time I had no idea of K building) and we split. In AW building I met friends manning OpenEmbedded stand just right in front of building entry.

Circuitco had Beaglebone stand right to it:

That robot was great example what you can do with enough signals available to drive all those motors. And what you can do with 3D printers ;D

I do not know is it due to crisis or something but AW building had just half of a space for stands used…

Then I went for talks:

• “Embedded distro shootout: buildroot vs. Debian” — wasted time. Long discussion about Emdebian + short info that Buildroot works in other way. Could be nice talk if done in other way.
• “Porting Fedora to 64-bit ARM systems” — talk done by Jon Masters and his clone. As usual first “what the hell is 64-bit ARM” and then how Fedora bootstraps itself. Nice talk, got some new stuff. Have to dig for Cavium SDK.
• “Porting OpenJDK to AArch64″ — interesting it was. Two speakers, lot of technical details.
• “ARMv8, ARM’s new architecture including 64-bit” by Andrew Wafaa. Mostly to catch speaker in easy way ;D
• “Bootstrapping Debian-based distributions for new architectures” – I was lazy to go somewhere else but it was good talk.
• “Bootstrapping the Debian/Ubuntu arm64 ports” by Wookey. Kind of recycled talk from Barcelona but I like his presentations. Also first one without “what the hell is armv8″ introduction.

I also had nice discussion with Jolla guys about their system/device and would I like to test it once they will have something ready for complains. Played a bit with Firefox OS on their reference developer platform and on Nexus S and was not impressed — for example it looked like they have to learn about DPI…

Then I met OE crew and few other guys and when finally noticed that it is time to go to the hotel and drop gear there. Once arrived it was a bit to late to go somewhere and search for some event so I joined SzLUUG team and we went for a meal, chocolates and then some drinking with Kerneliusz (SzLUUG mascotte):

Sunday

Breakfast, packing gear and go for a bus which was less crowded than day before (but we are a bit late as well). As we had to leave after 14:00 I managed only two talks:

• “systemd, Two Years Later” — some Ubuntu trolling and project status. Nice talk.
• “Porting applications to 64-Bit ARM Architecture” by Riku Voipio (main AArch64 porter at Linaro). Good discussion in a room, some nice hints and suggestions. Read his recent blog post about ARMv8 porting

Then walk, tram, bus and security check. This time I did not have to take developer boards from backpack as I gave them away during event. We arrived in Berlin and (due to Michał’s fosdem flu) I drove us back home.

Summary

It was great event as usual. But distance between K building and rest was too big for sessions which are one after another. I dropped some entries from my calendar just because it would be H->K->H->K switching.

Android application for schedule was ok. Would be nice to make a bigger effort and update it to cover K building as well and add a way to see what is going on in each building/room to reduce time before sessions.

Funny part

On Saturday I realized that for some reason I may remind Jon Masters… That’s due to hardware I had with me:

• two developer boards
• two phones
• two tablets
• 3 USB chargers
• 4 microUSB cables

The good thing is that they were not of same type (except some cables) :D

Related content:

1. UDS-Q
2. Going for FOSDEM
3. FOSDEM X
4. UDS-O
5. Dublin: Ubuntu sprint and more

All rights reserved © Marcin Juszkiewicz
FOSDEM 2013 was originally posted on Marcin Juszkiewicz website

#gDocBinder Beta Program today! Full Version of gDoc Binder is up for grabs when you join and register http://t.co/G3D1MXry #freesoftware

FSFE Newsletter - February 2013 http://t.co/bMRXitcW #fsfe #foss #freesoftware #opensource

We would like to welcome some new faces to the forum moderation team:

codemaniac
ikt
varunendra
QIII

Thank you all for giving your time to help keep the forum the pleasant place it is

#FreeSoftware PC Win Booster PC Win Booster is an application that lets the user keep up… http://t.co/fRlokK8g

#freesoftware PC Win Booster - Speedup PC Optimizer | Computer Speed Booster Freeware Software... http://t.co/YTG3dbRi #giveawayoftheday

Attribute Changer lets you tweak file attributes, date... http://t.co/CjpTKRIO #Article #FreeSoftware #KnowYourPC |http://t.co/rBRuAeYo

The death of Gnome Panel

Gnome Panel (or more properly, gnome-panel) is the main dock that you would see in the Gnome 2 series desktop, and in the Gnome Fallback session (also called Gnome “Classic” in many distributions) in Gnome 3.

To provide the typical desktop experience, it’s also accompanied by Nautilus and Metacity along with a few other libraries (hence forth, gnome-panel’s friends). Gnome Panel and friends have recently been deprecated so that developers have more time to focus on Gnome Shell, the new default shell for Gnome that has a vastly simplified (and better) technology stack. Last November, Vincent Untz announced that he would stop maintaining Gnome Panel and friends beyond the 3.6 release, which means the death for it unless anyone else takes it up.

Then What

I’ve been an avid user of the Gnome 2.x series and also Gnome Fallback in the 3.x series. I’ve gotten rather good at supporting it too. We include it by default in Edubuntu, and even have an option in the installer to make it the default for installations over Unity. It provides a low-footprint, fast and simple desktop experience with very reasonable usability, while being very configurable and lockdownable. (my spell check says that’s not a word, but I don’t care).

I’ve been considering whether we should switch to having Xfce or LXDE as an alternative to Unity, but after discussing it with other Edubuntu contributors, it became clear that if I wanted to do that, I’d have to be willing to maintain it for Edubuntu by myself. In Edubuntu we’ve been pretty good at having at least 2 people being interested in any side-project we pick up and I like to keep it that way if we can. It means that if someone gets a bit busy, there’s someone who can pick up the slack for a little while. Also, Xfce and LXDE had big holes in usability, especially when it came to things like having multiple displays and running on laptops. I decided to put that project on the backburner a little since Ubuntu 13.04 will still be using Gnome 3.6, which meant that we’d have the Fallback session for one more release anyway.

The Inevitable Fork

Ikey Doherty forked off Gnome Panel to create a new environment called Consort. Metacity is forked to become Consortium. The website where the Consort desktop environment used to live seems gone now, but here’s a link to some screenshots from Google+.

This caused a bit of a stir, Vincent Untz posted a good chronology of what lead up to it and why he believes that a fork is a bad idea when the Gnome project has effectively put the upstream code up for adoption.

I’ve been interested in the Consort family since it could potentially be something that we could use in Edubuntu once the upstream gnome-panel is no longer in the archives. Also, while Gnome Shell, KDE Plasma Desktop and Unity are great and have come incredibly far in terms of stability and performance, it’s just not always for me. I want to be able to use it for myself in virtual machines, older machines and some other special cases (most notably, on LTSP).

Josselin Mouette, maintainer of Gnome in Debian, approached Ikey after some requests have been made for it in Debian. If you’ve read the post and the IRC logs linked, then you’ll probably agree that it could’ve gone a lot better. I’m not on the SolusOS IRC channel so only saw the conversation after the fact, but I was disappointing since it would need to go into Debian if I’d want to support it in Edubuntu. I think both Josselin and Ikey could’ve handled it better, but humans are just that and emotions and misunderstandings happen.

And so I Bite

I was chewing a bit on Josselin’s comment on how the former maintainer “maintainer decided to give the key to anyone who wanted to” and it’s been several weeks since Vincent invited people to take over maintainership. I decided that I’d at least be willing to do the absolute minimum just to keep the project releasable every six months so that it can be included in distributions, maintain its online presence pages, bug tracker status and keep up with component changes in the stack. So I e-mailed Vincent and explained what I’m willing to do. I had very little resistance, Vincent sent an email out to other people who are steakholders in the gnome-panel project and after a week, there were no objections. So here I am, brand new maintainer of the Gnome Fallback session and its components!

This means that the project is, at least for now, alive again. It’s not going to be part of the official Gnome 3.8 release (I still have to figure out exactly what that means), but there will be a 3.8 release of Gnome Panel and friends as tarballs and for people who maintain it in distributions, things will continue to work exactly as it did before.

Short-term Goals

• My complete primary goal for this at the moment is to ensure that gnome-panel, metacity, etc is releasable alongside the Gnome 3.8 release. This basically means making sure it builds, including any patches that we can and releasing.

Medium-term Goals

• Do something about the long buglist. The Gnome bug tracker has an ugly long list of gnome-panel bugs (939 at my last count). I want to eliminate all the stale Gnome 2.x gnome-panel bugs of which a very large amount of them are no longer relevant (at least on first glance). Then I’d like to do some regular posts to the mailing list and blog about a few prominent bugs every now and again and try to fix them and get people involved.

• Porting Metacity to GTK3. So here’s a bit of really good news. Josselin is also involved with this and one of his mid-term goals is to port metacity to gtk3. It’s something that I know would have to happen, but I don’t have the skills to do that (yet) and I’m glad that he has took this up. Josselin’s mid-term goals also include possibly adding support for the new notification  system (if necessary) and adding support for the new Gnome global menu.

• Create a nice project page with goals and to-do list, who’s envolved and what they’re doing and encourage more people to get involved. The current page is rather outdated so it would be nice to fix it. For now that mostly involved bringing the Gnome Panel Gnome Wiki page up to date.

Long-term Goals

• My pet peeve…  intelligent launcher icons. Windows 7, Mac OS X, KDE, Unity and Gnome Shell have docks that work very similarly in many ways. You click on a launcher and those same launcher entries are recycled as your window list. Gnome Panel is a bit old fashioned in this regard. Many people use 3rd party panels and launchers just to get around this. I have thought for a long time that this should be fixed in Gnome Panel and long-term, it’s something that I’d like to see happen.

• Make the stack as downstream-friendly as possible. Regarding Ikey and Consort, I don’t actually think it was a completely horrible idea at the time. We live in a free world where we use free software and anyone is allowed to do whatever they want and fork whenever they want, and while that doesn’t necessarilly mean it’s a good idea, it also doesn’t mean that we need to get all hissy about it. I’d actually be very interested in working with people who want to fork and find out why they want to fork and try to reel them in closer to upstream. In the case of Consort, I think it would be most beneficial for both projects and all their users if Consort was a branch of Gnome Fallback, rather than a fork. Both projects use Git, FFS. I’ll reach out and try to minimize duplication of effort while not blocking anyone on experimenting with new features or implementing distro-specific changes.

• More metacity features. Metacity’s compositing features have come quite a long way, there are still a few bugs that need to be sorted out, but more than that, there are many window manager features that users have become accustomed to in pretty much all the other environments. Ikey has indicated previously that he wants to do this for consortium. It’s one of the reaons I’ll be super-nice to him because I’d really prefer that he submit as much of that upstream as possible.

• Make everything worth configurable and lockdownable. There are some settings that I get requests from from the users I support so often that it’s just getting boring. The Gnome 2.x series proved to work well in educational and corporate environments. I say we should play on that strength and make it even more  so, while sticking 100% with the Gnome Human Interface Guidelines, of course.

Very Long-term Goals

Well, the fact is, Gnome Fallback will die. There’s a new project called Gnome Legacy, it implements a Gnome 2.x-like experience in Gnome 3. As time goes by, older machines become more powerful and the missing pieces will be implemented and eventually there would be no more good reason for anyone to want to run what we now know as Gnome Fallback. I think it could still have a good 3-5 years or maybe even more in it. Who knows, by then Gnome 4 might even be in development and all of this will be ancient history.

So, my very quick “Eek, I’m now maintainer of Gnome Panel!” post has become quite lengthy post, if you have any questions, I’ll respond to it in the comments.

@apw He also said "There's nobody getting rich writing software that I know of" http://t.co/NF0q82PF I say #freesoftware time has come! :-)

As many of you know, I’ve been spending some time hacking on a Lisp variant that’s fully hosted in Python. If you want to read more about it, check out the slides I prepared for Boston Python’s meetup — in particular, pay attention to the “magic REPL”.

I’ve been pondering what to do next, and the natural instinct is for me to take a step back, and properly implement a few things I’ve forgotten. Namely: Macros. Yes. Macros. It’s a Lisp without Macros.

I’ve hit a few stumbling blocks in it’s implementation, and it’s been holding me up. I’m mostly concerned with how Hy should treat quoted forms, in particular I’m concerned about loosing the distinction between a vector and a list, since both convert into Python lists.

There is of course the option to encode Lists as:

`(list foo bar baz)

but that seems wrong.

I’ve also got some concerns about “derefing” values in a quoted form — I think this is just going to result in a lot of special casing for Macros.

More to come soon.

PPC Web Spy http://t.co/Ys41t32a #adwordskeywords #freesoftware

Wow, I forgot the english version of #Fork (software development) - http://t.co/X0tz5sx4 #forking #freesoftware #sloccount #similarity

100% Give Away: Software Packages To Generate Massive Waves Of Traffic To Your Website http://t.co/yeKC1YHh

Welcome to the Ubuntu Weekly Newsletter. This is issue #302 for the week January 28 – February 3, 2013, and the full version is available here.

In this issue we cover:

• Smart Scopes
• Announcing Ubuntu User Days Feb 9-10th
• Ubuntu Stats
• Ubuntu Ohio Holds Educational Session
• The World’s Largest Barcamp is in Myanmar
• Ubuntu App Developer Blog: Develop locally, run remotely
• Jonathan Carter: Ubuntu Developer Summit for 13.04 (Raring)
• Ubuntu Classroom: Ubuntu Developer Week: Days 1-3
• Ubuntu Women: Ubuntu Women Full Circle Follow Up with Laura Czajkowski
• Alan Bell: Ubuntu Smart Scopes
• Ubuntu Classroom: Interested in helping with Quality? Several sessions next week!
• Victor Tuson Palau: [Ubuntu QML] SimpleToDo.. done!
• Charles Profitt: Friendly Needs You!
• In The Press
• In The Blogosphere
• Other Articles of Interest
• Featured Audio and Video
• Weekly Ubuntu Development Team Meetings
• Upcoming Meetings and Events
• Updates and Security for 8.04, 10.04, 11.10, 12.04 and 12.10
• And much more!

The issue of The Ubuntu Weekly Newsletter is brought to you by:

• Elizabeth Krumbach
• Jasna Bencic
• Jim Connett
• And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

It looks like after a 7-0 vote by the Fedora Engineering Steering Comittee, MariaDB will replace MySQL in F19.

No word from the Monty Program crew yet, but congrats to them, especially Colin Charles, and the Fedora community, especially Jaroslav Reznik and Honza Horak.