On 05/19/2011 03:03 AM, Vincent van Ravesteijn wrote: > > > about the model so even my dumb brain > gets it. it was written that only maintainer is expected to > determine whats go > into-stable trunk and what does not and that we will benefit from > better review > model so i naturally wonder what does it mean. > > > It means exactly what it says. The maintainer will decide when to move a > feature into trunk-stable. In the meantime a feature can mature until it's > really finished and/or doesn't introduce bugs. > For what it's worth, my sense is that your idea is that there should be two things that both, in some way, correspond to current trunk. Let's call them trunk-devel and trunk-stable.
(i) trunk-devel is actually more like current trunk. People would be asked to develop stuff in a gitbranch, but they would be free to merge their changes into trunk-devel when they thought they were ready, much as we do now. This is what the adventurous would be encouraged to use for testing. (ii) trunk-stable is really what's new; changes only go into trunk-stable when the maintainer is convinced they are fully cooked. One could think of trunk-stable as intended always to be rc-quality, so that, if we decided to release next month, the only question would be: what is there in trunk-devel could be gotten ready by then? People who want or need access to new features could use trunk-stable without any real fear of instability, including instability from massive refactorings. The reason to develop features, etc, in gitbranches is that it makes maintaining this kind of set-up much easier. I think when it's put that way, it seems sensible. Am I missing something? Richard
