Hi Pedro,
Le 18 nov. 11 à 19:26, Pedro Giffuni a écrit :
Hi Eric;
--- On Fri, 11/18/11, eric b <[email protected]> wrote:
Disclaimer: this list is not
easy to read, and if the topic was already discussed. In this
case, thanks in advance to provide me the right link
:-)
Hi,
I perfectly know the importance of the IP clearance, but in
parallel, we'll need to work on the code, say "partialy" (e.g. vcl
+ sd + slideshow only). In OOo we used child work
spaces in that purpose, but I'm not sure we defined something
similar yet with Apache OpenOffice.org.
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
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.
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
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.
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.
The big question is how much will we do between the IP clearance
and 3.4. There are a few CWSs that could be integrated (mst had
proposed a few) and I would particularly favor gnumake4 as that
would be in the direction of getting rid of dmake which we will
have to do sooner or later.
I'm not sure to I agree: introduce gnumake4 will introduce a lot of
issues build breakers and more. That's why I'd prefer build using an
old but working well tool and introduce build breakers later.
I think for practical reasons, once the IP clearance is done we
will replace a few of the features with "free" components and after
that we will just do the release but
any feature or even bug fixes will be left for after 3.4.
More IP clearance goes, and less I see something buildable, but 'm
probably wrong.
This means 3.4 will have some very outdated components. I am
particularly concerned about ICU, but I already made up to the idea
it is unavoidable.
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:
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.
I remember what did the MAc os X port success : lot of people
building and building again.
1) the COIN solver.
2) Update the wpdlib support?
3) Perhaps put back MySpell in addition to Hunspell.
4) Maybe update some non-critical components (ICC?).
- We branch 3.4 and only do finishing touches there. trunk can
start doing aggressive CWSs merging, cleanups, new features, etc.
More urgent : fix crashes, and boring (for the user) issues
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.
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
