Via Slashdot I found an explanation of the release process of OpenBSD, a process that has been a success so far (12 years). I think something can be learn from it. Specially now that KDE is starting the transition to Git, release process may get an overhaul also.
Anyway I just want to point to the slides of Theo and his video. Hope someone find it interesting.
Friday, July 17, 2009
Wednesday, July 8, 2009
DVS, I love them
Guessing that eventually KDE will move to Git and specifically to Gitorious, I created a repository there for Rubots last week.
As it seems that the transition is starting already with Amarok and Taglib coming next and as noone has so for contributed to Rubots (logically and normal in its current state), I have decided to ignore KDE SVN and work only with Gitorious.
KDE moving to a distributed versioning system is great news. We just can not foresee how powerful and beneficial this will be for the project. I can see KDE software(Amarok, plasma ...) with several branches, when release beta time comes, projects will point to their correct branch to be retrieved as beta. They can keep an always summer branch, larger changes, etc in other branches, etc.
I am particularly excited because we can lower the entrance barrier insanely. Things like a dependencies file in the projects pointing to other branches needed to compile it. So one can download one project to make some small patch and automatically any dependency will be there also. Everything can be changed, compiled and committed right away.
As it seems that the transition is starting already with Amarok and Taglib coming next and as noone has so for contributed to Rubots (logically and normal in its current state), I have decided to ignore KDE SVN and work only with Gitorious.
KDE moving to a distributed versioning system is great news. We just can not foresee how powerful and beneficial this will be for the project. I can see KDE software(Amarok, plasma ...) with several branches, when release beta time comes, projects will point to their correct branch to be retrieved as beta. They can keep an always summer branch, larger changes, etc in other branches, etc.
I am particularly excited because we can lower the entrance barrier insanely. Things like a dependencies file in the projects pointing to other branches needed to compile it. So one can download one project to make some small patch and automatically any dependency will be there also. Everything can be changed, compiled and committed right away.
Saturday, July 4, 2009
Some (stupid) analysis on bug counts
In the last week (RC released, lots of people traveling to GC summit, trunk open for development) 200 more bugs were open than closed
In the last month, +400 (meaning another 3 weeks to have a +200 bugs open)
Plasma was in about 400 bugs till trunk was open to development, now it has 445 (I think it will not reach 400 for the final release).
So, we are "losing ground" just before release, not a good thing. But I wonder how many of those new bugs are actually valid, as Aaron said, many people are using older than rc1 versions to test and report duplicates.
KDE have 150 less bugs than one year before (approaching KDE 4.1 release)!
Opening ~27000 bugs and closing ~27150 bugs
Only two developers: andresbajotierra and finex have closed around 20% of those.
This is terrific news, in one year much new code has entered in KDE but bug count remained mostly the same, meaning that bug per code line as counted by bugzilla has decreased -> KDE quality has incresed.
Konqueror, Plasma and Amarok received more than 2000 reports (meaning more than 6 reports daily). Amarok added ~400 bugs, Plasma added ~200 bugs and Amarok _decreased_ ~200 bugs.
Kudos to the Amarok team!
In the last month, +400 (meaning another 3 weeks to have a +200 bugs open)
Plasma was in about 400 bugs till trunk was open to development, now it has 445 (I think it will not reach 400 for the final release).
So, we are "losing ground" just before release, not a good thing. But I wonder how many of those new bugs are actually valid, as Aaron said, many people are using older than rc1 versions to test and report duplicates.
KDE have 150 less bugs than one year before (approaching KDE 4.1 release)!
Opening ~27000 bugs and closing ~27150 bugs
Only two developers: andresbajotierra and finex have closed around 20% of those.
This is terrific news, in one year much new code has entered in KDE but bug count remained mostly the same, meaning that bug per code line as counted by bugzilla has decreased -> KDE quality has incresed.
Konqueror, Plasma and Amarok received more than 2000 reports (meaning more than 6 reports daily). Amarok added ~400 bugs, Plasma added ~200 bugs and Amarok _decreased_ ~200 bugs.
Kudos to the Amarok team!
Friday, July 3, 2009
Rubots!
Hello planet!
I have just committed a game to playground in pre-pre-pre-alpha stage called Rubots.
The game us written in Ruby (qt-ruby so far, needs help for kde-ruby) and uses Player/Gazebo as backend.
What I am talking about? What is this software?
Gazebo
Gazebo is a robotics simulator. A .world file is created where one can introduce models (everything written in XML, not very nice but usable). This defines the 3D world of the simulation. Gazebo is done in C++ and provides an API to control de robots' actuators and read their sensors.
It also have a plugin for Player.
Player
Is a robotics middleware. One of many. The idea is create an abstraction with interfaces. For instance Position2d interface has commands to set the speed and the position of the robot. One dont really care about what is the actual architecture of the robot (how many wheels, where is the driving train), this is done by low level drivers.
This software is used to control REAL robots, is popular and has Ruby bindings.
When used together, Gazebo via its plug-in cheat Player and make it believe it is controlling a real robot when in fact it is controlling a robot inside the simulation.
So this is the idea:
Gazebo simulating a couple of robots in a battleground scenario
Player controlling and passing data around thanks to ruby bindings and Gazebo plugin
Ruby programmed robots to actually move the robots around and fight!
Think of this as Robocode in 3D and programed in Ruby.
Benefits:
- For Player/Gazebo : lot of testing. I have already found deficiencies and solve them in that software thanks to the stress of the game.
- For Ruby: The game tries not to cheat if possible, meaning the robots programmed for the game will work as it in real hardware!
- For KDE: Get a neat new game :D There are any serious KDE application done in Ruby?
Currently most code is kept in two files as it is easier to develop like this, it will eventually break into files
I have set up a site for planning.
Help and comments are very very much welcomed.
I have just committed a game to playground in pre-pre-pre-alpha stage called Rubots.
The game us written in Ruby (qt-ruby so far, needs help for kde-ruby) and uses Player/Gazebo as backend.
What I am talking about? What is this software?
Gazebo
Gazebo is a robotics simulator. A .world file is created where one can introduce models (everything written in XML, not very nice but usable). This defines the 3D world of the simulation. Gazebo is done in C++ and provides an API to control de robots' actuators and read their sensors.
It also have a plugin for Player.
Player
Is a robotics middleware. One of many. The idea is create an abstraction with interfaces. For instance Position2d interface has commands to set the speed and the position of the robot. One dont really care about what is the actual architecture of the robot (how many wheels, where is the driving train), this is done by low level drivers.
This software is used to control REAL robots, is popular and has Ruby bindings.
When used together, Gazebo via its plug-in cheat Player and make it believe it is controlling a real robot when in fact it is controlling a robot inside the simulation.
So this is the idea:
Gazebo simulating a couple of robots in a battleground scenario
Player controlling and passing data around thanks to ruby bindings and Gazebo plugin
Ruby programmed robots to actually move the robots around and fight!
Think of this as Robocode in 3D and programed in Ruby.
Benefits:
- For Player/Gazebo : lot of testing. I have already found deficiencies and solve them in that software thanks to the stress of the game.
- For Ruby: The game tries not to cheat if possible, meaning the robots programmed for the game will work as it in real hardware!
- For KDE: Get a neat new game :D There are any serious KDE application done in Ruby?
Currently most code is kept in two files as it is easier to develop like this, it will eventually break into files
I have set up a site for planning.
Help and comments are very very much welcomed.
Subscribe to:
Posts (Atom)