AutoQA 0.4.7 released

AutoQA 0.4.7 has just been released and deployed!

What are the major changes?

• Upgradepath and depcheck tests won’t crash when there is a broken Bodhi update in which some packages are marked with updates-pending Koji tag and some are not.
• Bodhi comments now emphasize that AutoQA results are purely informative, we don’t block anything.
• AutoQA now correctly detects modified Bodhi updates and runs tests again for them.
• Upgradepath no longer reports failures when you want to push to F(N)-updates repository and F(N+1)-main repository contains lower version of your package.

We also heard your complaints about sending you too many emails through Bodhi comments (one for every test result for every arch). Our current framework architecture does not allow miracles, but we plan to work hard in the next several weeks to alleviate at least some of the symptoms. And in the long-time perspective, it will be even better. The purpose of AutoQA is to help you, not to discourage you. Please continue to feed us with your comments, they are very helpful – email your ideas to autoqa-devel. Thanks.

And finally, our fun mascot 🙂

Happy weekend.

LinuxExpo Prague 2011

Yesterday I attended Linux Expo / Open Source Conference 2011 in Prague. Together with my colleagues (Jaroslav Řezník, Vítězslav Humpa, Jiří Eischmann) from Red Hat we formed a crew of a small Fedora stall at this conference. A few other Red Hat guys (Luděk Šmíd, Jan Pazdziora, Petr Kovář) prepared presentations for this conference.

Our task was to present Fedora to people, give away some small treats (CDs, stickers, pins) and discuss anything about Fedora with visitors. We decided to attract them by showing the two major desktop environments that will be present in Fedora 15 – Gnome 3 and KDE 4.6.

Let’s see some photos!

The main rush-hour was in the morning, where many students came and asked about Fedora project. But even in the rest of the day we were all constantly busy. Many people came to get their hands on the upcoming Gnome 3 and asked about the differences. We have met a lot of people that came to discuss their experiences with open source world or asked for advice with some Linux-related problems.

We were not alone there, our competitors were all around us 🙂

In the evening after the conference ended we moved to a pub where we tasted Bernard beer and talked about our interests together with competitor colleagues. I met a bunch of people I had known before only virtually, so I’m very glad for that.

AutoQA – upgradepath vs updates to multiple Fedora releases

If you are a package maintainer, you probably need sometimes to push the same update to several Fedora releases. But upgradepath may report failures for some of your updates. What’s wrong?

Let’s imagine this situation:

Packages in stable updates:

• foo-1.0-1.fc14
• foo-1.0-1.fc15
• foo-1.0-1.fc16

Now you decide to propose these updates:

• foo-1.1-1.fc14
• foo-1.1-1.fc15
• foo-1.1-1.fc16

The result may be following:

• foo-1.1-1.fc14 – upgradepath will FAIL because Fedora 15 still contains just foo-1.0
• foo-1.1-1.fc15 – upgradepath will FAIL because Fedora 16 still contains just foo-1.0
• foo-1.1-1.fc16 – upgradepath will PASS since there is no Fedora 17

The effective result is that you have to first push the update to the highest Fedora version (Rawhide) and only then you will see upgradepath produce PASS result for the update going to the previous version of Fedora.

You probably guessed that the reason for this behavior is that upgradepath considers every update individually, not as “set of updates”. In the future we would like to improve that and prepare these “set of updates safe to push” for RelEng team. But currently the aforementioned behavior was the one that was quick and easy to do. We plan many improvements in the future.

What are the implications?

1. If you want to have certainty that your update doesn’t break upgradepath constraint, push to the highest Fedora release first and then consequently to lower ones. Or at least inspect upgradepath logs if there is really no other issue with your update than this one.
2. If you want to push update for a single Fedora release, you don’t have to push for the others. Read Minor release bumps for old branches.
3. Upgradepath is re-evaluated for all pending updates regularly (and very often). If your update received a FAILED result, correct the situation and in a short time you should receive PASS result. If you update still fails, we will inform you only once in 3 days to avoid spamming.
4. Don’t forget that AutoQA results are purely informative, they do not block your actions.

Git Tip of the Day – see changes while committing

The series continues! 🙂

You’ve surely seen this scenario:

You have just prepared the patch and you want to commit it. But when you run:

$ git commit

and you want to describe the changes, you are not sure whether you remember all of them. So you must fire up another terminal, display the diff and ensure the commit message covers all the major points.

But there’s a nice solution:

$ git commit -v

This will display the diff inside the commit message editor, so you can go through all the changes in the same window in which you’re describing them. I find it very convenient.

Some of you may probably even want to create an alias for it:

$ git config --global alias.ci 'commit -v'
$ git ci

Oh, so nice.

Happy gitting!

Git Tip of the Day – pruning stale remote-tracking branches

In the last month I read “Pro Git” book. Sometimes I stumble upon something really interesting or useful I didn’t know before. I decided to share some tips with you from time to time, since it can help all of us in our day-to-day work. If you have some further tips, don’t be afraid to share.

Today’s menu of git tips says “pruning stale remote-tracking branches”:

You probably know git remote command. It shows information about your remote repositories. Try this one out:

$ git remote show origin

What you might not know is that this command allows you to prune all your local branches that track an already-deleted remote branch.

I often remove remote feature branches after the changes have been merged into master and the branch is not needed anymore, in order to “tidy up”. But if you checked out that branch into your local one and set it as tracking, git pull won’t delete such local branches for you. So how do you know which local branches doesn’t exist on the server anymore? Easily, just run:

$ git remote prune origin --dry-run

and you’ll receive a list of your stale remote-tracking branches. If you run it without –dry-run option, it will remove them for you.

Happy gitting!

AutoQA vs Bodhi – round 2

As you probably noticed not so long ago we announced that AutoQA would be sending comments to Bodhi and inform package maintainers about the results of important test cases (depcheck and ugpradepath). We enabled the functionality and disabled it again very soon due to a number of problems that were discovered. Good news – we’re going for round two!

In the first run we discovered some bugs in our test code, but we also found a number of packages that were incorrectly tagged as pending updates even though they had been in the stable repository for a long time already. The former problem should be solved by AutoQA 0.4.6 (and 0.4.5) which we are releasing today. The latter problem was fixed on Bodhi side by Luke Macken (huge thanks for quick response). Hopefully now the package maintainers won’t receive any alerts about already pushed package updates, only about the newly proposed ones.

AutoQA Bodhi comments should be re-enabled today. As mentioned before we will quickly disable them if something goes wrong, fix the problem, then re-enable them again. If you don’t receive any AutoQA results for your package, don’t be surprised. However if you receive results but they seem to be wrong, please tell us so that we can investigate: autoqa-devel or #fedora-qa. Thanks!