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 19:36:37 GMT
On Fri, Jun 1, 2012 at 3:10 PM, Pedro Giffuni <pfg@apache.org> wrote:
>
> Ugh ...
>
> --- Ven 1/6/12, Rob Weir <robweir@apache.org> ha scritto:
> ...
>
>>
>> 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.
>>
>
> And computers need electricity, which is not free and
> not available under a compatible license. I wish you
> could keep focused or at least do an effort to
> understand the issues so we can solve them.
>

Be nice.

> The tarball release must be consistent; we cannot hide
> tarballs in SVN. Creating a directory with the Category-A
> tarballs that form a base of the release along with the
> base distribution is not really a problem. Some of them
> are not available upstream anymore.
>

That is one possible technique.  But not the only one.  I'm a
committer on another Apache project, the ODF Toolkit, and we do not
include any of the dependencies in our release, not even other
category-a ones.  All of them are downloaded on the fly from a central
repository.  That is the beauty of Maven.

There are advantages of disadvantages of each approach.  But we can't
reject one approach outright with a policy argument.  Both methods are
in use at Apache today.

-rob

> Pedro.
>
>
>
>
>
>
>> 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