incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)
Date Fri, 01 Jun 2012 18:12:58 GMT
On Fri, Jun 1, 2012 at 12:37 PM, Pedro Giffuni <pfg@apache.org> wrote:
> Hi Jürgen;
>
>
> On 06/01/12 03:16, Jürgen Schmidt wrote:
>>
>> On 5/31/12 6:26 PM, Pedro Giffuni wrote:
>>>
>>> ...
>>>
>>> First of all we should clarify what a source release is in this context.
>>> Does our source release contain Category-A tarballs? In other
>>> words, does this file:
>>>
>>> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
>>>
>> I hoped that was clear, our source release files don't contain any
>> tar-balls from ext_sources
>
> OK. So what we are releasing is only the part of the SVN tree labelled
> "main",
> (not sure if ext_libraries is included, it should be). I would think a
> source
> release should be able to build without having to look for extra libraries
> in
> our SVN. Call me old fashioned but I am thinking of people trying to
> distribute the sources in a CD-ROM.
>
>
>
>>> Build on it's own? Or are developers/builders expected to download
>>> more tarballs from SVN.
>>
>> yes, you unpack the source, solve some basic build env requirements
>> according the building guide, run configure and build. The tar-balls get
>> downloaded during the bootstrap step automatically.
>>
>> After checking it again, the only drawback currently is that all
>> tar-balls are downloaded even if they are not used. That is true for all
>> categories.
>>
>> But this is something that we can improve for the 3.5 (already started).
>> We should only download the tar-balls that we need by configure ...
>>
>> Why not 3.4.1? Because it is a maintenance release only and we want to
>> be careful. For 3.4.1 we change the url to download from our 3.4 revision.
>
> I think all releases must respect Apache policies ASAP.
>
>
>>
>>>> It seems to be really an item for legal to decide if hosting the
>>>> category-b tar-balls in svn is not allowed for convenience at all.
>>>>
>>>> Furthermore we agreed to accept and of course support the move to
>>>> another server but it is important that we don't break our 3.4 release.
>>>
>>> As you noted before, removing Category-B tarballs shouldn't break
>>> the default build. But I will go further ahead with mentioning that
>>> the 3.4 Release is theoretically broken already with the Lucene and
>>> Apache Commons updates (the development branch is for
>>> development, right?), and since no one complained people must be
>>> getting the files from somewhere else.
>>
>> well that is a very bad example and probably wrong. We all know or
>> expect that not many people will build AOO from the source release.
>> People who are interested will more likely check it out from svn as you
>> and I did it as well.
>
> I think the problem is your definition of source release. The source release
> in the source tarballs should be 1:1 equivalent to the source release in
> SVN.
> If you think release (in the tarball) is only what you have under "main"
> then
> we do have trouble moving dependencies in the tree. but if you include the
> tarballs in the release, then we don't have trouble. In other words:
>
> If 3.4.1-Release is this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
> it has never been broken.
> If it is only this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/
>
> Then the release is unbuildable on it's own.
>

No release is buildable on its own.  You need an operating system, a
compiler, often other pre-existing libraries on the system, other
prerequisites that need to be installed by the developers.

Even in its cleanest form, a Java program using Maven, a release will
not build until the user first installs Maven.

So no one (except maybe you) is arguing that our release should be
buildable without any dependencies that are not included in the
release.   The real questions should be thought of from the
developer's perspective:

1) What dependencies are mandatory and which ones are optional, needed
only for specific features?

2) What are the obligations that a developer has when they make use
of, or modify code in a particular dependency?

3) What do I need to provision my dev environment to build, with or
without any given dependency.

What we do at Apache, providing open source software for the good, is
directed to making things simple for the downstream consumers of our
releases.

What we're doing with ext_sources is making #3 far easier, for the
developer, compared to tracking down and fetching dependencies from
other websites.  And I think we've taken the proper steps to provide
information, build flags, NOTICE and LICENSE files to cover the other
two concerns.


>
>
>>
>>>> We also agreed to clean up as much as possible of the dependencies to
>>>> category-b stuff over time. But that takes time and is a lot of work.
>>>
>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now is
>>> not really acceptable.
>>
>> well that is exactly the question. I don't know for sure if it is a real
>> problem to have them in svn.
>>
>> svn or any other server would be equal as long as we don't
>> change/improve the download part.
>>
>> So the real problem seems to be a different one.
>>
>
> I will address the Category-B + patches issue on another email.
>
>

Mime
View raw message