Ok, so we tried arranging a bug squashing weekend and we did get a noticeable ammount of bugs squashed, but the turnout wasn’t quite as good as we had hoped for. We fixed a few tickets, closed a few invalid ones, classified a few and got more assigned. We might do this again in the future though, but for more than just a few hours on a saturday.
It became more and more obvious that we would have to delay 0.1.5 a day or two, for a couple of reasons. One of them is trailfocus 2, which strictly speaking would be trailfocus 3. It’s a complete rewrite from scratch of trailfocus motivated by the excessive CPU usage of the trailfocus that lie in trunk at the moment. It did, however, revive a discussion I had with onestone at the time I wrote opacify about methods of changing paint attributes. Basicly, we both agree there needs to be a proper way of doing it, but we’ve yet to agree on what way we should do it. See http://lists.beryl-project.org for the discussion details. (dev-list)
The idea is to make it easier for plugins to deal with opacity-changes(or saturation/brightness) in a natural way. So far, there hasn’t been much of a standard, I went a bit against the wind with opacify to avoid having to calculate opacity on every paintWindow, which is how it is done on the old trailfocus-rewrite. We hope to also agree on a solution to make it easy and natural for state to override paint-changes (like exclude windows from opacify or trailfocus)
A few other reasons for the delay is snap and awaiting a unified decision on thumbnail2. Strictly speaking we’re beyond a new plugin freeze, but snap is a release criteria for 0.2.0 so that has been known all along, and there are compelling arguments for thumbnails2 too. Either way, 0.1.5 will be important, and the feedback we get from it will be vital for the quality of 0.2.0.
I’ve allways liked helping people over the net, when I’m bored I tend to fallback to that behavior and find somewhere I can be assist others. Since my involvement with Beryl, this has meant I’ve been helping a lot of people on IRC and the forum, answering on large amounts of threads and questions with what I hope is techincal insight.
This has also lead me to realise that we need to improve the FAQ, Documentation, suggestion/wishlist and trac work. There are fa too many similar bugs, threads and whatnot. I know racarr recently posted a blog about what’s feasable and not (we spoke about it on IRC before he did this), and I’ve also started to update the FAQ section of the forum whenever possible.
I’m also trying to involve more developers in this, but for this to happen properly there needs to be a little bit of self constrain on what people post. The forum is too high traffic and too much duplication and general crazyness… I’m not telling people not to post crazy ideas, I just hope they will read the new FAQ section first. Also the threads run wild sometimes… I think that the main reason for a lack of developer involvement (there are a few of us reading the forum and the ideas do eventually reach us, but hardly everyone follows the forum…) is that us devs tend to get bored with what to us might seem like silly or trivial problems.
The solution to this is of course to make the documentation good enough for there not to be any trivial and silly posts. And then there’s the wiki… I suspect this is an area that can be greatly improved. The information probably changes regularly and I can’t remember the last time I personally used anything there. I don’t even find it trustworthy to be honest. Too many third-party repositories… It essentialy needs some attention, preferably from someone highly experienced with Beryl.
So anyway, these are just a few late-night rambelings of a much too tierd monkey, I’ve set myself a informal goal though: to climb down from the number 2 spot on the “post count” list of the forum. When my input is no longer necesarry is when I’m going to be happy 