re: keeping old jars around...
Having all the old jars around is a nice idea, but do we know that
anybody really cares?
Straw-man two question poll:
1> What's the most recent version of Solr/Lucene you'd be OK with
nuking the jars?
2> In the last year, what's the oldest version of Solr/Lucene you've
built that had been released for more than 6 months? ("I never do
this" is a fine answer)
Wondering how much of this is a "Trip to Abilene". Long form:
https://en.wikipedia.org/wiki/Abilene_paradox
Short form:
"a group of people collectively decide on a course of action that is
counter to the preferences of many (or all) of the individuals in the
group."
On Fri, Dec 4, 2015 at 10:01 PM, david.w.smi...@gmail.com
<david.w.smi...@gmail.com> wrote:
> I agree with Rob on this — delete the ‘jar’s from git history, for all the
> reasons Rob said. If someone wants to attempt to actually *build* an old
> release, and thus needs the jars, then they are welcome to use ASF SVN
> archives for that purpose instead, and even then apparently it will be a
> challenge based on what I’ve read today.
>
> Any way, maybe this will or maybe this won’t even solve the git-svn OOM
> problem by itself? It’s worth a shot to find out as a trial run; no? Maybe
> we could ask infra to try as an experiment. If it doesn’t solve the problem
> then we needn’t belabor this decision at this time — it can be resumed at a
> future git transitional discussion, which is not the subject matter of the
> current crisis.
>
> bq. I know you won't accept rational arguments. :)
>
> Dawid, please, lets not provoke each other with that kind of talk. The
> smiley face doesn’t make it okay.
>
> ~ David
>
> On Fri, Dec 4, 2015 at 4:26 PM Dawid Weiss <dawid.we...@gmail.com> wrote:
>>
>> > I don't think jar files are 'history' and it was a mistake we had so
>> > many in source control before we cleaned that up. it is much better
>> > without them.
>>
>> Depends how you look at it. If your goal is to be able to actually
>> build ancient versions then dropping those JARs is going to be a real
>> pain. I think they should stay. Like I said, git is smart enough to
>> omit objects that aren't referenced from the cloned branch. The
>> conversion from SVN would have to be smart, but it's all doable.
>>
>> > this bloats the repository, makes clone slow for someone new who just
>> > wants to check it out to work on it, etc.
>>
>> No, not really. There is a dozen ways to do it without cloning the
>> full repo (provide a patch with --depth 1, clone a selective branch,
>> etc.). We've had that discussion before. I know you won't accept
>> rational arguments. :)
>>
>> D.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
