On Tue, 7 Aug 2012 18:59:28 Abecasis Joao wrote: > On 7. aug. 2012, at 02:45, Alan Alpert wrote: > > On Mon, 6 Aug 2012 22:13:30 ext joao.abeca...@nokia.com wrote: > >> Fire-hose is a development branch, things may be variously broken at all > >> times. Typically, developers in this mailing list will be tracking that > >> branch. > >> > >> Leaky-faucet is deemed beta quality and somewhat more stable. At the very > >> least it shouldn't break as often. We can expect that more people will be > >> willing to track this branch with their own development. > > > > This is the part that I don't quite understand. This makes it sound like > > Fire- hose is the branch for destabilizing changes. Particularly > > destabilizing change sets are of course in their own branch, but the > > large numbers of normally destabilizing changes will make fire-hose mere > > Alpha quality at best. But then Thiago's email then said that fire-hose > > should be 'always ready for beta', which seems contradictory. > > Given that these are all common shared branches they should not be getting > half-baked features in. For small features it's feasible to allow that > they'll be built incrementally over a couple of commits. Anything beyond > that is a good candidate for feature development in a separate branch. > These should only hit the shared branch when they are ready for prime-time, > admittedly this is also when those features get wider exposure and more > issues are found. > > When you mention "destabilizing" changes the truth is most of the time we > don't know which ones those are. Here, we try to increase stability by > limiting the type of changes that go into each branch: only regressions > should be fixed in the leaky-faucet branch, which is similar to the patch > release policy we tried to keep in the past.
Bug fixes and regressions, I presume you mean. > > The fact that we build up a predictable release schedule means there is less > pressure to rush changes in. You know exactly when your feature will make > it to a release, as long as you get it in good shape and into fire-hose. > > As I interpret it, the bump in quality comes from merging fire-hose to > > leaky- faucet some time before the release. Unfortunately, I didn't get > > any extra detail when I zoomed in on your ascii art. Here's my zoomed in > > version of the diagram: > > > > ----------+----------------- fire-hose > > > > \ > > > > ----------+---------+------- leaky-faucet > > > > \ > > > > --------------------+------+ dripping-bucket > > > > \ 5.1.0 > > > > ~2 Months |-----------------| > > That's not the zoomed version, and you don't need it. Admittedly the > original graph had a bug by showing '+' on both sides of the merge, where > only the destination should have them. Here's a fixed, stripped down > (non-zoomed) version: > > ------------------------------------ fire-hose > \ > ---------------+-------------------- leaky-faucet > \ \ \ \ > ------+--------+--------+--------+-- dripping-bucket > \ \ \ \ > 5.1.0 5.1.1 5.1.2 5.2.0 > > (does it help?) > > Notice how merges coming from the branch above happen after a merge to the > branch below. This gives a lower bound of 4 months for a change to make it > from fire-hose to a release and an upper bound of 10 months, depending on > when the change gets into fire-hose to begin with. Let me try again then, zoomed-in on the 5.1.1 section. Because reading ascii art just doesn't seem to be my specialty. ------------------------------------ fire-hose | ------------------------------+----- leaky-faucet | ------------------------+----------- dripping-bucket \ 5.1.1 ~2 Minutes |-----------------| So the 5.1.1 release is tagged before leaky-faucet merges to beging 5.1.2, and that merge happens before fire-hose merges into leaky-faucet? And that merge from fire-hose -> leaky-faucet around the time of the 5.1.1 release doesn't reach dripping-bucket until the 5.2.0 release? If so, I might finally have figured it out. > > Note that we also seem to disagree on the time scale, but that's what '~' > > is for ;) . Am I correct in assuming that merging fire-hose to > > leaky-faucet drops the quality of leaky-faucet to whatever fire-hose may > > be, and then developer focus shifts to leaky-faucet for stabilization > > (while destabilizing elements continue to flow rapidly into fire-hose for > > the next release)? How much lead time do we allocate per release? And > > what happens if we slip, because we couldn't get it to beta quality in > > time? > > The goal here is to get to strict time-based releases, which means we don't > slip the schedule. If we make a lower quality 5.x.0 release, quality will > improve for the 5.x.1 and 5.x.2 releases. > > This is all assuming we *want* to have a minor release out every 6 months. > If we don't, then all discussion is pointless. I like the idea of strict time based releases, but given the past minor releases 6 months is optimistic. That said, we could easily have smaller minor releases that are actually minor for a change. I'm realizing now that this design is intended to transition from feature-based releases to time-based releases. Since quality is the casualty in both schemes, I'm less worried about that now ;) . > After we have tried this setup, and *if* we feel quality is consistently > down, then we need to make adjustments. We can adapt policies, be stricter > about enforcing those policies (e.g. through the CI system), or require > higher standards when accepting features into the fire-hose branch. Okay, that addresses my other concerns. This does sound like it needs us to work in branches a little more, could we please get a better process for gerrit branches than "ask a gerrit admin"? Or just relax the http://qt-project.org/wiki/Branch-Guidelines to be more permissive of working in gitorious.org branches. Thanks for taking the time to explain it to me. I think I understand it now, and it sounds like a good idea. Especially after 5.0.0, which is a good time for a developer mindset change. -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development