On 10/27/11 8:28 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidtjogischm...@googlemail.com wrote:
In any case, yes.. I think this is the way to go. I am
just hoping there will be a way to opt out those
components in favor of the system libraries when those
available.
me too
--- On Fri, 10/28/11, Jürgen Schmidt jogischm...@googlemail.com wrote:
snip mental dump
4) I know you want ucpp there too, but since that
stuff is used in idlc, I think I'd prefer it in
idlc/source/preproc/
as it was before. No idea if we can use the system cpp
for the rest but that
On 9/22/11 1:19 PM, Jürgen Schmidt wrote:
ok, we have several arguments for and against but no decision how we
want to move forward. Let us take again a look on it
1. we have a working mechanism to get the externals from somewhere,
check md5 sum, unpack, patch, build
1.1 somewhere is
2011/10/27 Jürgen Schmidt jogischm...@googlemail.com:
On 9/22/11 1:19 PM, Jürgen Schmidt wrote:
ok, we have several arguments for and against but no decision how we
want to move forward. Let us take again a look on it
1. we have a working mechanism to get the externals from somewhere,
check
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote:
...
i think we still haven't finished on this topic but it is
somewhat
important to move forward with our IP clearance and the
whole
development work.
So if nobody has real objections i would like to move
forward
On 10/27/11 6:13 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidtjogischm...@googlemail.com wrote:
...
i think we still haven't finished on this topic but it is
somewhat
important to move forward with our IP clearance and the
whole
development work.
So if nobody has real
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote:
In any case, yes.. I think this is the way to go. I am
just hoping there will be a way to opt out those
components in favor of the system libraries when those
available.
me too but we should move forward and we
On Thu, Oct 27, 2011 at 2:28 PM, Pedro Giffuni p...@apache.org wrote:
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote:
In any case, yes.. I think this is the way to go. I am
just hoping there will be a way to opt out those
components in favor of the system
Hi Matthias;
--- On Thu, 10/27/11, Mathias Bauer mathias_ba...@gmx.net wrote:
...
In any case, yes.. I think this is the way to
go. I am
just hoping there will be a way to opt out
those
I am OK with that, but let me attempt to dump what I
think:
1) you are not bringing in
Am 01.10.2011 00:17, schrieb Michael Stahl:
On 30.09.2011 21:24, Mathias Bauer wrote:
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
Another advantage of unpacking the tarballs: the patches will become
*real* patches that just contain changes of the original source code.
Often the patches
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
FWIW;
I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date
On 30.09.2011 21:24, Mathias Bauer wrote:
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
Another advantage of unpacking the tarballs: the patches will become
*real* patches that just contain changes of the original source code.
Often the patches nowadays contain additional files that we just
On 20.09.2011 16:36, Pavel Janík wrote:
Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external
tarballs in the VCS, but then we moved them out and it worked very
well. There never was a
FWIW;
I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date versions there
would not be much trouble.
just my $0.02,
The problem with bringing the 3rd party software completely into the SVN tree
and modifying it in the tree has to do with the license the updated software is
under. In that case, there *is* a code provenance issue and I believe it
crosses a line that the Apache Software Foundation is unwilling
The idea (not originally mine) is to have keep only compatible
licensed code under an isolated (3rdparty) directory.
I think on the long run we should try to use the system versions
of such software when available, and every linux/bsd distribution
is probably doing that for LO already.
Pedro.
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
FWIW;
I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien jhrecht...@web.dewrote:
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janíkpa...@janik.cz:
Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
Maybe Heiner will say more, but in
Proposed way to move forward
1. put the externals under .../trunk/ext_sources
.../trunk/ext_sources
.../trunk/main
.../trunk/extras
2. adapt configure to use this as default, disable the download (maybe
reactivate it later if we move to a DSCM)
3. keep the process with checking the md5
On 22.09.2011 13:19, Jürgen Schmidt wrote:
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtienjhrecht...@web.dewrote:
On 09/20/2011 05:26 PM, Rob Weir wrote:
...
Placing all the external tarballs in the VCS is a real killer if using a
distributed SCM like git or Mercurial, thats why we
2011/9/22 Pavel Janík pa...@janik.cz
Proposed way to move forward
1. put the externals under .../trunk/ext_sources
.../trunk/ext_sources
.../trunk/main
.../trunk/extras
2. adapt configure to use this as default, disable the download (maybe
reactivate it later if we move to a DSCM)
don't know if it is what you are looking for but
wget http://svn.apache.org/viewvc/incubator/ooo/trunk/main/
filename?view=co
should download the head version.
Then we should be able to have both things solved - files in SVN and with a
relatively small change in the download script also
2011/9/22 Pavel Janík pa...@janik.cz:
Proposed way to move forward
1. put the externals under .../trunk/ext_sources
.../trunk/ext_sources
.../trunk/main
.../trunk/extras
2. adapt configure to use this as default, disable the download (maybe
reactivate it later if we move to a DSCM)
3.
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org wrote:
I was thinking something similar. We only need to use the SVN
interface to the files when we're adding or updating. But we can have
bootstrap continue to download via http. The location, using
Juergen's proposed location,
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org wrote:
I was thinking something similar. We only need to use the SVN
interface to the files when we're adding or updating. But we can have
bootstrap continue to download via
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com:
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org wrote:
I was thinking something similar. We only need to use the SVN
interface to the files when we're adding or updating.
hi,
Based on this result, an other trunk will be like the following if IBM
symphony checked in:
/ooo/symphony-src/trunk/main
/ooo/symphony-src/trunk/extras
/ooo/symphony-src/tags
/ooo/symphony-src/branches
thus it introduces a problem:
How to merge the two trunks of symphony-src and ooo-src?
On Thu, Sep 22, 2011 at 3:18 PM, Rob Weir robw...@apache.org wrote:
It is possible that we have this wrong. Adding in site/ and ooo-site/
brings in a different convention. They have are set up to have
trunk/tags/branches underneath them. That is fine, because the
website does not release
On Thu, Sep 22, 2011 at 9:40 AM, Shao Zhi Zhao zhaos...@cn.ibm.com wrote:
hi,
Based on this result, an other trunk will be like the following if IBM
symphony checked in:
/ooo/symphony-src/trunk/main
/ooo/symphony-src/trunk/extras
/ooo/symphony-src/tags
/ooo/symphony-src/branches
thus it
You can get anything off of the web interface of SVN at the individual level
without it being in a working copy, though of course it has to be somewhere
local while it is being processed in a build.
But if you check-out the trunk, you get everything that is in the trunk HEAD
(or a specified)
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janíkpa...@janik.cz:
Have we ever considered using version control to...uh...manage file versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external tarballs
in the VCS, but then we moved them out
Hi,
I like this idea.
From a developer point of view I only have to checkout ext_sources once and
reference it from all my trunks using the already existing configure-switch
'with-external-tar=path to ext_sources'
when we will have such repository, we will surely modify the current
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand armin.le.gr...@me.com wrote:
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote:
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
...
What do others think about a structure where we have ext_sources
besides
trunk.
incubator/ooo/trunk
Would we be able to do this? What if the flaw was related to code in
ext_sources?
Then we patch it. Patch will be in the trunk/main, as always.
And if not us, in the project, what if some downstream consumer of
AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But
we've
On 20.09.2011 15:58, Rob Weir wrote:
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grandarmin.le.gr...@me.com wrote:
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote:
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
...
What do others think about a structure where we have ext_sources
besides
+1
- This will make it easier to update the BSD/MIT unrestricted stuff.
- Hopefully it also means we will eventually stop depending on GNU
patch for the build.
Welcome Oliver!
Great job Juergen: it's the first code replacement and a very
necessary one for OO forks too (unless they want to
Have we ever considered using version control to...uh...manage file versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external tarballs
in the VCS, but then we moved them out and it worked very well. There never was
a reason to track external.tar.gz files
Ai2011/9/20 Pavel Janík pa...@janik.cz:
Have we ever considered using version control to...uh...manage file versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external
tarballs in the VCS, but then we moved them out and it worked very well.
There never
38 matches
Mail list logo
