On Fri, Jun 1, 2012 at 3:10 PM, Pedro Giffuni <p...@apache.org> wrote: > > Ugh ... > > --- Ven 1/6/12, Rob Weir <robw...@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. >> > >> > >>
