> > 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 ...
I don't know why you think I want to impose bureaucratic controls. Just because I want to propose to have a stable trunk branch which will only acquire features that are 'finished' or don't show any regressions and which have a proper organized commit log. > ...looks like some NASA project and not our lyx hobby kitchen. It's rocket science to have a two-stage process ? Not like I propose really complicated stuff, just a two-stage process. 1) a new feature is merged into development, 2) the feature has shown to be finished, stable, etc. and will get merged into trunk-stable which will be the release. > 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. Did I say that I want you to ask my permission before committing something ? > > it looks like that the old "one patch" per "one feature" and "wait for > my review, Did I say you have to wait for my review ? > i'm just little busy right now" monster emerges just under > different name, god bless branching kingdom :) So, what if the person maintaining trunk-stable would be busy. Why would you care when your feature gets merged exactly into trunk-stable ? > it didn't work and i'm against moving back to the old kind of situation, > if thats what you propose. Please read the other threads on what I do 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". Well, it should not be too much to expect some proper code before pushing it into the release. >> 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. Did I say you need to ask permission ? Did I say you need to wait before doing something ? Even the smallest fixes appear often to be either wrong or incomplete. If it is really a small fix, it will move through the layers quickly anyway. >> 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. Such a branch is useless. > >> #ah I made a typo > > the problem is that you never know when or whether this situation come. Often this happens quite quickly, either you realise it yourself or some fellow developer reminds you. > 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. You somehow think that you need permission before pushing a feature ? > > so where is the trigger that small thing should be merged into the common > tree? I don't know what you mean by the "common tree" ? If you mean merging a feature into development, that would be the same as the trigger that makes you commit something to svn trunk. If you mean merging with trunk-stable, that would be when the trunk maintainer feels to clean up the list of branches that need to be merged. Vincent
