Hi Juergen; Oh.. I am not feeling any of this as a personal attack, email doesn't really represent what one thinks or how one feels about things.. It will be interesting to meet you in Germany... I suspect we are not very different ;).
>________________________________ > From: Juergen Schmidt <jogischm...@gmail.com> > > >> >> > Please explain where exactly your problem is to do the work on a branch. >> > >> > >> >> >> Please, when we have identified the breakage cause and iff it's clear it >> was my update I will be glad to revert it. I really need evidence though, >> the changes were thoroughly tested and you cannot ask me to revert it >> based on Rob's sudden's feelings about it. >> >> > >it seems that you don't get my point and I was not clear enough. I am not >interested in this specific case but more in a general agreement how we can >address such problems. My workflow is different to what you can expect from a professional developer for many reasons, but what I tend to do is this: - My build system is based on FreeBSD's ports tree but I do use the latest code from trunk and do frequent updates from SVN. Other people's changes do affect directly what I am doing. In a certain sense this is the same as having my own local branch but some of my changes are not ready for sharing. - AOO takes long to build here so I have time to do other stuff while I wait for a build and on occasions I can be doing two orthogonal changes. Ideally I only work on one thing at a time but I can occassionally work on two. - All my changes are tested here first. - If I think the change is ready but I am not prepared to support an eventual breakage upstream, I leave it "resting" in my system for a while. - When I think the change is very system dependent I open a bugzilla issue and let it there for someone else to review. - I only do the commit when it's ready but I need to stay available to fix any eventual breakage (shit happens - I know it just too well). Before committing I always look at svn status, svn diff, and I keep a patchset ready in case I have to revert. - I am not afraid to commit. That's what lazy consensus is about. -When failure has happened I analyze quickly a solution, even if it is not optimal. If I can't fix it, I will point out where it seems to be failing and I offer to revert. Normally, like in the python update: I was able to fix it quickly and after a while I replaced the quick fix with a better one. >> >> If I do have to revert it then I will simply drop it. It works fine here. and >> I don't have anything to fix. >> >> > > Mmh, I am sure you don't mean this serious and I hope I made already clear > that I wanted address this more general. I will explain this better: my work cycle is at most two weeks for a particular task. This is unpaid work so I don't feel like spending too much time unless it's real fun. In the case of the boost update, this is something that helps the project because we have tested patches to make boost build with both gcc and clang. This is not something I *need* to have though: I already enjoy the benefits of using it as system boost. If I fail by breaking a system I don't have access to I won't stress about it: of course I will revert but if I don't have access to such system how am I going to fix it? Someone else may take over or it will be left to rust (as happens with so many things that no one has updated in AOO). If the boost change had required fixing regressions and/or optimizing other parts of the code I surely agree creating a branch was a sound approach. I think using branches is cool, but if your changes are simple (boost either builds or it doesn't) and can be handled with a single diff it is an overkill. Just my thoughts, Pedro.
