On Wed, May 18, 2011 at 10:58 PM, Pavel Sanda <sa...@lyx.org> wrote: > Vincent van Ravesteijn wrote: > > I don't know why you think I want to impose bureaucratic controls. > > when i read: > > For the future, I propose that developers create a branch, and indicate > > when it is ready to be merged with 'development' (i.e. to be committed > > to trunk). After that, you and me decide when it merges into either > > branch_20x or trunk-stable. > > it looks somewhat complicated compared to the current process of "svn ci" > and check dev-list for echo. >
Current process is like: "dumping code and if people are not around at the time to echo, it will stay there forever, and someone else can later clean up the mess when bugs start to appear". If that's what you prefer.... > > > Did I say that I want you to ask my permission before committing > > something ? > > Did I say you have to wait for my review ? > > no. but you are not enough verbose I've been writing huge mails about this.... > 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. > > > So, what if the person maintaining trunk-stable would be busy. > > Why would you care when your feature gets merged exactly into > > trunk-stable ? > > if its just the busy part from the clause then no. > Don't understand. > > > 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. > sometimes 'proper code' is personal taste and even professional coders > do not agree between each other. so my question remains. > Are you saying that if someone asks you to change this this and that, you want to be able to not do it and still have your code in the next release ? So you will let future developers figure out why you coded something in this way, rather than that someone politely asks you to comment and describe what you did when you committed it, so other people can actually review the code because they can understand it. > > > Did I say you need to ask permission ? Did I say you need to wait before > > doing something ? > ... > > You somehow think that you need permission before pushing a feature ? > > one reading of "After that, you and me decide when it merges to > trunk-stable" > is like that. its actually connected to the question above and if i get it > completely wrong, then sorry. > It's not like asking the maintainer for "permission". it's more like "if there are no serious comments on a patch, if there are no bugs introduced and if it is understandable to others", it will automatically get merged into trunk-stable after some period of testing. > > > >> 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. > > why? > Because in this way, it has no advantages to use branches at all. Vincent
