Vincent van Ravesteijn wrote: > If a maintainer can make sure that a branch remains stable, why wouldn't > it be a good thing to keep the codebase for the next major release stable > as well.
maintainer of stable branch is able to make it stable because he usually allows only bugfixing and not much new features not to speak about code refactorization. its because of the stability reasons why people usually start think about some branch and not just trunk. to impose levels of bureaucratic controls on trunk looks like some NASA project and not our lyx hobby kitchen. > > i dont completely get whats the purpose of this stable-trunk. > > do i understand correctly, that in this proposal: > > - instead now chaotical (but you can also read it self-organized) team based > > decisions whats in trunk, will be delegated in fact on a single man? > > if he is busy or stubborn then what? it would also somehow dissolve the > > meaning of what we meant be giving @lyx.org, that is trust that the man > > is capable to contribute things to the codebase without father behind his > > back. > > With all do respect, not many of us are professional coders, and we would > benefit from having a more efficient review process. And I think that > another model will facilitate this. it really matters what exact review scenario do you propose. there was time when anything needed big boss Lars OK to go in. at the end the frustration of other devs errupted so trunk was opened more closer to nowadays situation where small set of people are freely allowed to push things into trunk and its up to their intuition whether its enough problematic to ask or not. it looks like that the old "one patch" per "one feature" and "wait for my review, i'm just little busy right now" monster emerges just under different name, god bless branching kingdom :) it didn't work and i'm against moving back to the old kind of situation, if thats what you propose. so it boils down to the question whether the movement of code through these layers is evoked by "this code didn't caused bugs yet" or by "please changes this this and that and when i'm happy/finished with review it can go". > This is a completely different issue. But I can say some things: in the > last months before the release nobody is not allowed to do anything, so > they don't do anything. or they are frustrated enough to fix the rest of issues ;) but we are really on theoretical ground, i dont know. > > another important thing to have. because i dont think that eg > > baum/remove-deadcode > > should have anything to do with branches. "clean commit history" is nice, > > but not > > holy grail and we shouldn't annoy devs doing small catches for the > > branch-everywhere > > philosophy. > > Why is it an annoyance ? Create a branch, commit your stuff and push > the branch. when there is some small fix then i simply push it into trunk and dont want to keep in mind when-where to merge something and even more ask about somebody permission whether these lines please him in order to merge. i respect this scenario for branch but it would be tiresome to do for trunk as well. > When using git, you have to create a new branch anyway > whenever you do some coding yourself, so that the original branch > can track the remote branch easily. no i can just stay in small-bugfixes branch, which will be automatically merged once a day. > the maintainer should make sure he will merge it on top. But this > does not happen too often I guess. i'm afraid the responsible guy will slowly become tired by this, but since its currently not my responsibility, take the fun :) > An example of a workflow: > > git checkout -b vfr/new-feature > git commit hack1 > git commit hack2 > git push origin vfr/new-feature > > #ah I made a typo the problem is that you never know when or whether this situation come. if you wait too much you will spend your time on resolving the conflicts and you need to carry in your mind what needs to be pushed. so where is the trigger that small thing should be merged into the common tree? (all time i speak about small things, larger features are for branch, granted). pavel
