Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 19 Feb 2015 18:22:12 +0000 (UTC)
From: "Ryan Ernst (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12776094.1424330693000.88176.1424370132612@Atlassian.JIRA>
In-Reply-To: <JIRA.12776094.1424330693000@Atlassian.JIRA>
References: <JIRA.12776094.1424330693000@Atlassian.JIRA>
 <JIRA.12776094.1424330693355@arcas>
Subject: [jira] [Commented] (LUCENE-6258) Cut binary releases down to a
 single format
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/LUCENE-6258?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D143=
27895#comment-14327895 ]=20

Ryan Ernst commented on LUCENE-6258:
------------------------------------

{quote}
a) worth looking at the build.xml files to make sure we understand what is =
currently diff between the two =E2=80=93 off the top of my head i seem to r=
ecall line endings on shell scripts being diff (to play nicer with cygwin w=
hen windows users use zip files) ... on the flip side: tgz lets us preserve=
 executable bits on shell scripts in a way i don't believe works consistent=
ly in zip files? ... point is: that should be reviewed thoroughly before ri=
pping out one or the other.
{quote}

If this is true, that we have different line endings depending on the forma=
t, then this is bogus IMO. We don't say "windows" and "unix/mac" in the fil=
ename to indicate zip is for one and tgz for the others.

{quote}
b) this sounds like a made up problem to me -- end users are only helped by=
 having multiple formats, not harmed.  users aren't downloading both the tg=
z and zip file releases -- they are picking one and using that.  the only s=
ize decrease here is in what we as developers have to download to test when=
 voting on an RC.
{quote}

But that is a real problem. Releases take a *long time* for the release man=
ager to deal with.  Cutting down on what has to be transferred/tested will =
allow us iterate more quickly. For example, maybe we wouldn't be so afraid =
of a respin if spinning an RC took half the time (not saying this will decr=
ease the time by half, only using this as an example for why decreasing tot=
al artifacts size is good for us). =20

Regarding "end users are only helped", then why don't we also release in .7=
zip, or .rar or any other container format?  Why is our source release only=
 for tgz? IMO it is because we just need some container format to stuff our=
 jar files into. There is no real distinction or advantage for a competent =
user.

> Cut binary releases down to a single format
> -------------------------------------------
>
>                 Key: LUCENE-6258
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6258
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Ryan Ernst
>
> In LUCENE-6247, one idea discussed to decrease the size of release artifa=
cts was removing either tgz or zip from our binary releases.
> The source releases are already only in tgz.  I think we should do the sa=
me for binary releases.  I looked at a number of other Apache projects, and=
 the results are mixed, but there definitely are many major projects (hadoo=
p, couchdb, cassandra, cordova) that only release tgz. Anyone who can deal =
with running using Lucene or Solr should have the skills necessary to extra=
ct an archive in either format, so in this way I think either format is fin=
e, but I think matching what we release source in has a nice look.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org