--- On Fri, 10/28/11, Jürgen Schmidt wrote:
> > 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 would probably make sense.
> mmh,
On 10/27/11 8:28 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidt 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
Hi Matthias;
--- On Thu, 10/27/11, Mathias Bauer 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 *anyth
Am 27.10.2011 20:28, schrieb Pedro Giffuni:
> --- On Thu, 10/27/11, Jürgen Schmidt 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
On Thu, Oct 27, 2011 at 2:28 PM, Pedro Giffuni wrote:
>
>
> --- On Thu, 10/27/11, Jürgen Schmidt 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
>> > availab
--- On Thu, 10/27/11, Jürgen Schmidt 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 can change it a
On 10/27/11 6:13 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidt 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
--- On Thu, 10/27/11, Jürgen Schmidt 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 with this
> prop
2011/10/27 Jürgen Schmidt :
> 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, unpac
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 configur
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 p
--- On Fri, 9/30/11, Mathias Bauer wrote:
>
> I'm not against unpacking the tarballs and applying the
> patches, but we should keep the patches somewhere so that
> updates could be done with the same effort as today.
>
This could fly.
I like having the patches around. I would only request
th
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 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 ve
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 v
e-
> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
>
> Sent: Wednesday, September 28, 2011 08:32
> To: ooo-dev@incubator.apache.org
> Subject: Re: handling of ext_sources - Juergen's suggestion
> [was: Re: A systematic approach to IP review?]
>
> FWIW;
x27;s suggestion [was: Re: A
systematic approach to IP review?]
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
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,
On Wed, Sep 28, 2011 at 9:23 AM, Mathias Bauer wrote:
> What might be the best way to handle 3rd party code in AOOo probably will
> depend on the needs of the developers as well as on legal requirements.
>
> We had these tarballs plus patches IIRC because Sun Legal required that all
> used 3rd par
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
Sent: Thursday, September 22, 2011 05:24
To: ooo-dev@incubator.apache.org
Subject: Re: handling of ext_sources - Juergen's suggestion [was: Re: A
systematic approach to IP review?]
2011/9/22 Pavel Janík :
>> Proposed way to move forward
>>
>> 1. put the externals
t;
> *Rob Weir *
>
> 2011-09-22 21:18
> Please respond to
> ooo-dev@incubator.apache.org
>
>
>
> To
>
> ooo-dev@incubator.apache.org,
> cc
>
>
> Subject
>
> Re: handling of ext_sources - Juergen's suggesti
On Thu, Sep 22, 2011 at 3:18 PM, Rob Weir 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" in synch with
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?
2011/9/22 Jürgen Schmidt :
> 2011/9/22 Jürgen Schmidt
>
>> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir 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 h
2011/9/22 Jürgen Schmidt
> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir 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
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir 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, would be
> ht
2011/9/22 Pavel Janík :
>> 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.
> don't know if it is what you are looking for but
>
> wget http://svn.apache.org/viewvc/incubator/ooo/trunk/main/
> ?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 the
2011/9/22 Pavel Janík
> > 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
On 22.09.2011 13:19, Jürgen Schmidt wrote:
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtienwrote:
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 had moved them out.
> 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 t
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien wrote:
> On 09/20/2011 05:26 PM, Rob Weir wrote:
>
>> Ai2011/9/20 Pavel Janík:
>>
>>> Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
>>>
>>>
>>> Maybe Heiner will say more, but i
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janík:
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 ve
Am 20.09.2011 16:36, schrieb Pavel Janík:
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
> Is your main concern performance? Even as individual tarballs,
> ext-sources is 86 files, 250MB. ooo/extras is 243 files and 822 MB.
> And ooo/main is 76,295 files for over 900MB. So ext-sources is not a
> huge contributor to download time.
You have to think about compressed data. ext_csource
Ai2011/9/20 Pavel Janík :
>> 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
> 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 fil
+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 carry
2011/9/20 Pavel Janík :
>> 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, fo
On 20.09.2011 15:58, Rob Weir wrote:
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand 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
> 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
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand 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/t
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
incubator/ooo/ext_source
...
I like this idea.
From a developer point of view I on
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=""'
when we will have such repository, we will surely modify the current sources so
yo
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir wrote:
2011/9/19 Jürgen Schmidt:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
...
Suggestions:
1) We need to get all files needed for the build into SVN. Right now
there are some that are copie
46 matches
Mail list logo
