The Checkbox project is undergoing more changes. We had to solve the problem of bug management and feature tracking for releasing each of the many components that now make up the project. We have discussed a number of ideas, including using tags, milestones, series and lastly, to use multiple projects. Using multiple projects ended up the most direct and effective option.
We had to add a twist to that idea though, apart from the existing checkbox project, all of the new projects would have no source. Just bugs, blueprints and releases (series, milestones and tarballs). Why? Because we lead a double life and need to take that into account and splitting the project into multiple code repositories is a separate transition that we have decided not to do (at this time, though I think that's healthy for us).
So the double-life aspect. As mentioned in one of my earlier posts, Chcekbox has two kinds of releases. The one life is about our upstream role. We release tarballs, package them for Debian, get them sponsored, synchronize them to Ubuntu into the hands of everyone using the platform. The other life is organized around our PPAs, internal customers and project schedules. There Ubuntu deadlines don't matter but it also means that important bugs have two releases they are a part of. They are a part of one (or more) of the upstream components. This is important so that we can properly document what goes into each release. They are also a part of a timestamped delivery for our internal customers. They also care about tracking fixes to the issues blocking their work.
So with that we now have checkbox-project (a launchpad project group) that aggregates our entire stack. You can now see all of the bugs and milestones throughout the project. You can also see how particular bugs or features translate to upcoming, scheduled releases of particular components. We hope that this new arrangement will be more valuable for everyone who tracks our work, despite the added set of project.
No comments:
Post a Comment