On 20.09.2011 15:58, Rob Weir wrote:
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
incubator/ooo/ext_source
...

So are we saying we would never need to branch or tag these files?

For example, suppose we release AOOo 3.4.0, and then later we release AOOo 4.0.

Then someone finds a serious security flaw in AOOo 3.4.0, and we
decide to release an AOOo 3.4.1 as well as a AOOo 4.0.1.

Would we be able to do this?  What if the flaw was related to code in
ext_sources?

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 already updated ext_sources for AOOo 4.0?

In other words, how do we track, in SVN, a compatible set of matching
trunk/ and ext_source/ revisions, so we (or someone else) can recreate
any released version of AOOo?

Good point. Thus, it should be part of incubator/ooo/trunk, something like:

incubator/ooo/trunk/main
incubator/ooo/trunk/extras
incubator/ooo/trunk/ext_sources

It could be in an own repro, but this would just bring up the risk to not use the same tags in both (by purpose or by error).

Indeed, looks as if it has to be a part of trunk somehow. Not very nice for binaries.

Maybe we could find a intermediate place for them as long as we will need to do changes pretty often. Currently we will have to do some add/remove/changes to it. It could be good to add them to trunk after it has stabilized a little more.

-Rob



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>"'

+1

Also, hopefully ext_sources will not change too much (after a consolidation
phase) and it's mostly binaries, thus not too well suited for a repository.
Let's not extend our main repository with those binaries, please.

Best regards, Oliver.


Regards,
        Armin
--
ALG





Reply via email to