Tag Archives: bug triaging

Triage X Bugs of the Week 1 (TXBW1)

Here is my report for the first week, (actualy I’m a little bit late, but friday loked like a better day for such reports)

  • #385803 – Reported upstream.
  • #391452 – Wontfix, there is a nicer alternative.
  • #335515 – Ping & closed.
  • #394529 – Asked for a phrasing (any native English writer can help here).
  • #252585 – I’m not sure the actual needed changes worth it, so I proposed to just document it, waiting for feedback…
  • #379480 – Ping & closed.
  • #290881 – Today’s package has changed, so reassigned and updated info.
  • #251449 – Added info, if someone is more easy with wiki stuff than bug triaging, then updating the FAQ is a work for you ;).
  • #420018 – Ping & closed.

That’s it… about 880 bugs more to go !

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Working on X isn’t that hard !

First, Hello Planet Debian !

Some words about me

I’m a new member of the X Strike Force, the debian team responsible for packaging Xorg. I basically stepped in with the openchrome driver.
I also have wider interest in free software or open source in general, but you can have a look at the rest of my blog, so I won’t bother you with too much details.

More about X

Talking with various attendant at MiniDebConf Paris, I got the impression that people think working on Xorg is hard.

I must say: It’s not !

First debian work is mostly packaging, and the developers of the applications we package (debian call them upstream) are pretty responsive, so you won’t be on your own.
Most of the work is preparing the packages for their new release, place them in experimental first, and ask for testers.
Then people test and the real work start: we receive bug reports.
Sometime seeing the report, it’s easy to point the user to test some other version, do some change, remove some old libraries in /usr/local/lib.
Sometime we need to ask for more information.

I said we, but for now unless it’s about openchrome, I can’t help much, but I follow the bugs on the X mailing list and learn from others response, I think I’ll be able to help soon.

An other way to help: TXBW

I’m sure you’ve read about RCBW, kudos to every one posting some and to every BSP attendant.
But if you thought X was hard, you certainly find the remaining RC bugs too hard (Or if not, you might want some distraction with an easier task).

So I have a proposition for you: Triage X Bugs of the Week (TXBW)

As Lucas told on his blog I’ve proposed him a patch to help triaging X bugs using UDD. And he accepted it, Thanks !

So here is the link I’m using: XSF unstable bugs sorted by date.
But remember the udd database is not live data, if you close a bug, it won’t disappear immediately.
Also please read the X Strike Force Bug Closing Procedure before starting.

To conclude my TXBW data (well TXB of the Day so to speak)

  • #233204 – pinged submitter.
  • #334461 – closed, no longer occur.
  • #204378 – proposed a development direction, if anybody is really interested in actually using XDM, please have a look.
  • #303889 – closed, ion3 no longer available to test.
  • #369389 – closed, the report details very old versions.

I hope this can be a success like the RCBW initiative is.
Currently there are hundreds of X bugs, more than a half are at least one year old so they deserve to be triaged !

The X Strike Force (still) needs you !