Hi Jonas :)
* Jonas Häggqvist <rasher_at_rasher.dk> dixit:
> Development now continues in trunk, and when bugs are found that are present
> in the stable branch, they should be backported (carefully) and
> point-releases should be made (perhaps depending on the severity of the bug,
> either immediately or once a few bugs have been fixed). Only bug fixes go
> into the release branch - if necessary as work-arounds rather than proper
> fixes if the fix is too involved and risks introducing new bugs.
IMHO, this is the only source of problems I see in the model you
propose. In order for this to work, the differences (e.g. new features)
between the stable branch and the trunk must be kept small. This means:
- Only one feature at a time. As long as the feature "works", the
trunk becomes the stable branch again. Bad, very bad, because a current
feature would stop the development of lots of features.
- Fix only minor bugs, that will be easily backported to the stable
branch. I think this is what you had in mind. The point releases will be
just bugfix releases and people will upgrade without fear: nothing
should be broken in point releases as they only contain minor bugfixes.
- Fix all bugs and give the backporters hell. Nice if they don't
know where you live ;))
The problem with backporting is that from time to time, writing a
proper backport of some bug fixes will be just impossible. I don't think
this will be ever happen in rockbox as the internal "framework" (sorry,
I can't think of a better name) API is stable and small. I mean, this is
not the linux kernel, where a bugfix in 2.6.x won't be easily backported
to 2.4.x due to architectural changes.
While I don't have much time to contribute major chunks of code, I
think I can do backports, as long as they are not VERY big and complex.
Think of it as the "patch monkey" in the linux kernel.
Raúl Núñez de Arenas Coronado
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
Received on 2007-08-09