Hi Eric; --- On Fri, 11/18/11, eric b <[email protected]> wrote:
> > > > I personally don't understand well how those CWSs > worked or how they are integrated. > > > One released version of OpenOffice.org was named "a > milestone". Between one milestone and the next one, we > integrate several cws (the number may vary). > > We could summarize : milestone N + > several cws's == milestone N+1 > That's the main thing VCSs do. But what I read CWS started in CVS and were adapted to work similarly in SVN and Hg. If I download a CWS, will I get a diff or a code tree? The nice thing in SVN you can merge from the current code and you can keep in line with the upstream code. > More about one cws : > > Formaly, this is a set of changes, based on a milestone. > More precisely, a cws is a branch (not sure with the term) > based on a milestone, defined during it's creation. The main > idea is that the developer can commit changes without break > HEAD. When the cws is confirmed ok ( e.g. the feature works, > no breakage on any OS, and no known issue introduced and so > on, the cws is ready for integration. At the end, was the > release engineer who decided which cws's can be integrated, > to define the next OpenOffice.org milestone. > We usually do it the other way around: you first merge current (trunk) into you branch, test it well, and then merge it back upstream. I still have some more reading to do in the SVN handbook but I have the impression that you guys reinvented the wheel all along :). Not that anything is too easy: FreeBSD used CVS and perforce for a long while before deciding to move to SVN and some people like git too. > The drawback is, that the dev must not take a too long time > to add the new code: when enough of other cws's are ok, they > can be integrateed, and new milestones appear in meantime. > Waiting too long means the dev will have to resync the cws > with a more recent milestone, because the diff will no > longer apply. > > FYI, one link who could help you. > http://wiki.services.openoffice.org/wiki/ChildWorkSpace > Thanks, this is a summary of how this has worked for FreeBSD: http://youtu.be/66enuplpZxw so I expect this is basically the same issue, but at a different level. > > > > I would personally prefer if just use SVN branches > exclusively from now on. > > > > I think SVN branches is similar, but since code is commited > a bit randomly, there is no certitude the code is the same > between the time I checkout and the time I want to commit my > diff. e.g. the part of the code I'm working on can be > obsolete e.g. somebody modified the same files as the one I > was working on. > This is never easy but SVN does help: it knows when files have moved or if some simple changes still apply. > > > > I think OOo has not really used this historically, but > in other projects developers have their own branches and can > do work without disrupting the main tree. > > I think we are discussing about the same idea :-) > :). > > > > > >> Obviously, some parts of the IP clearance could be > achieved > >> this way too. > >> > > > > As I see things the absolute priority is to go through > the IP clearance process and before that nothing significant > will be integrated. > > > > > My proposal was to "organize" more the IP clearance. > IP clearance is one a life time thing and it's the great bottleneck for a release at this point. I think the wiki +bugzilla works well enough for now. The problem is that Wiki+bugzilla is not a sustainable development model for what follows. > > I'm not sure to I agree: introduce gnumake4 will > introduce a lot of issues build breakers and more. OK, I was under the impression that gnumake4 was actually small but I can live without more stuff being integrated. > That's why I'd prefer build using an old but working well > tool and introduce build breakers later. > OK. I do think after 3.4 we should integrate everything from Oracle that makes sense. > > More IP clearance goes, and less I see something buildable, > but 'm probably wrong. > hmm .. We are not really breaking things but we are cutting things from the build. Some changes are really nice: OOo is very bloated and getting rid of some of the GNU stuff like regex and glibc makes sense and a lot of stuff is not really used at all. > > > Indeed ICU, is a nice mess. Worse: I bet a lot > of the binaries we build are maybe completely useless since > years, and help to provide a bloated set. > > > > Right now I think the road ahead is as follows: > > > > - Continue with IP clearance only (I estimate 2-3 > weeks but it's only a guess). > > - Once that is over we have to discuss what features > can be recovered: > I forgot: we have to run flawfinder, a security audit tool that produces lots of false positives but that nevertheless sometimes detects some hazards. > > There is one important step (I didn't see it) : we > must provide robust and well working instructions to build > OOo, everywhere, because what counts is the number of people > building, and able to say : no problem, or there is one > breaker. > Yes we have to document well the requirements and the build steps. I personally use two flavors of scripts for my test builds. > > More urgent : fix crashes, and boring (for the user) > issues > Are we really too bad on those? The main boring issues for me have always been: 1) OOo is too slow to get up running. 2) The compatibility with MS-Office is not too good: margins don't match, colors look different. but those are not going to be fixed in 3.4. > > > > This surely requires more discussion and thinking, but > that's about all the planning I have in mind ATM. > > > > Yes, sure : let's organize a bit. > Yes, I'll read more about SVN and branching. Pedro.
