Jeff King writes:
> I think I'm leaning towards the very first patch I posted, that assumes
> 7.11.0 and later. And then hold off on the others for a few years. In
> terms of "number of ifdefs removed" we could go further, but I think it
> was the first patch that removes a lot of the really ques
On Fri, Apr 07, 2017 at 01:18:30PM +0200, Johannes Schindelin wrote:
> On Thu, 6 Apr 2017, Jeff King wrote:
>
> > And it's not like people on ancient mission-critical systems get cut
> > off. They can still run the version of Git they were running when their
> > OS went out of support.
>
> You k
Hi Peff,
On Thu, 6 Apr 2017, Jeff King wrote:
> And it's not like people on ancient mission-critical systems get cut
> off. They can still run the version of Git they were running when their
> OS went out of support.
You keep baiting me, so I'll bite, after resisting the urge for so long.
Let m
On Thu, Apr 06, 2017 at 06:43:06PM +0200, Tom G. Christensen wrote:
> On 06/04/17 11:21, Jeff King wrote:
> > On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:
> > > I don't use the el3 and el4 versions much any more and el5 use will also
> > > drop of now as I'm busy converting
On 06/04/17 11:21, Jeff King wrote:
On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:
I don't use the el3 and el4 versions much any more and el5 use will also
drop of now as I'm busy converting machines from el5 to el7.
Thanks for sharing, that's a really interesting data poi
On Wed, Apr 05, 2017 at 11:33:37AM +0200, Tom G. Christensen wrote:
> FWIW I maintain freely available updated git packages for RHEL 3, 4, 5, 6
> and 7.
>
> They can be found here:
> https://jupiterrise.com/blog/jrpms/
>
> And direct access here:
> https://jupiterrise.com/jrpms/ (for el3,el4,el5
On Thu, Apr 06, 2017 at 12:53:01AM +, brian m. carlson wrote:
> > It would be great to have them on-list, as far as I can tell they were
> > never submitted? Is there some time/administrative reason for why
> > you're not submitting them? Some of these are many years old, it would
> > be great
brian m. carlson wrote:
On Wed, Apr 05, 2017 at 12:51:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
wrote:
Whoah. So my assumption in
that nobody was compiling this & thus not reporting failures was
false. Rather there's an entire community &
On Wed, Apr 05, 2017 at 12:51:38PM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
> wrote:
> Whoah. So my assumption in
>
> that nobody was compiling this & thus not reporting failures was
> false. Rather there's an entire community & distribution mec
On 05/04/17 12:51, Ævar Arnfjörð Bjarmason wrote:
On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
wrote:
Whoah. So my assumption in
that nobody was compiling this & thus not reporting failures was
false. Rather there's an entire community & distribution mechanism
around patching git for ol
On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen
wrote:
> On 04/04/17 04:54, Jeff King wrote:
>>
>> A nearby thread raised the question of whether we can rely on a version
>> of libcurl that contains a particular feature. The version in question
>> is curl 7.11.1, which came out in March 2004.
On 04/04/17 04:54, Jeff King wrote:
A nearby thread raised the question of whether we can rely on a version
of libcurl that contains a particular feature. The version in question
is curl 7.11.1, which came out in March 2004.
My feeling is that this is old enough to stop caring about. Which means
On Wed, Apr 05, 2017 at 10:49:47AM +0200, Johannes Schindelin wrote:
> Let's reiterate that we are talking about some #ifdef's here that are a
> tiny maintenance burden. That may have a bug here and there, easily fixed.
Forget the maintenance cost for a moment. My concern is that we are
doing use
Hi Stefan,
On Tue, 4 Apr 2017, Stefan Beller wrote:
> On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin
> wrote:
> >
> > On Tue, 4 Apr 2017, Brandon Williams wrote:
> >
> >> I'm all for seeing a patch like this applied. I agree that we can't
> >> expect the world to be running the most up-to-
On 04/05, Johannes Schindelin wrote:
> Hi Brandon,
>
> On Tue, 4 Apr 2017, Brandon Williams wrote:
>
> > I'm all for seeing a patch like this applied. I agree that we can't
> > expect the world to be running the most up-to-date version of curl but
> > we should be able to select some "oldest" ve
On Tue, Apr 4, 2017 at 3:46 PM, Johannes Schindelin
wrote:
> Hi Brandon,
>
> On Tue, 4 Apr 2017, Brandon Williams wrote:
>
>> I'm all for seeing a patch like this applied. I agree that we can't
>> expect the world to be running the most up-to-date version of curl but
>> we should be able to selec
Hi Brandon,
On Tue, 4 Apr 2017, Brandon Williams wrote:
> I'm all for seeing a patch like this applied. I agree that we can't
> expect the world to be running the most up-to-date version of curl but
> we should be able to select some "oldest" version we will support which
> can be bumped up ever
On Tue, Apr 04, 2017 at 04:06:46PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat*
> > indefinitely ;-)
>
> I don't really care about applying this patch, but I wouldn't mind
> seeing it applied.
>
> I just wanted to clarify the c
On 04/04, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin
> wrote:
> > Hi,
> >
> > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:
> >
> >> I think it's completely fine to include your patch as-is. At some
> >> point we need to pass the burden of dealing wit
On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin
wrote:
> Hi,
>
> On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:
>
>> I think it's completely fine to include your patch as-is. At some
>> point we need to pass the burden of dealing with these old software
>> versions, saying that you should
On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:
> A nearby thread raised the question of whether we can rely on a version
> of libcurl that contains a particular feature. The version in question
> is curl 7.11.1, which came out in March 2004.
I had a quick look at the 7.11.1 support, an
Hi,
On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote:
> I think it's completely fine to include your patch as-is. At some
> point we need to pass the burden of dealing with these old software
> versions, saying that you should use a <10 year old library isn't
> unreasonable. Anyone packaging new
On Tue, Apr 4, 2017 at 10:33 AM, Jeff King wrote:
> On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote:
>> > My feeling is that this is old enough to stop caring about. Which means
>> > we can drop some of the #ifdefs that
On Tue, Apr 04, 2017 at 10:17:51AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote:
> > My feeling is that this is old enough to stop caring about. Which means
> > we can drop some of the #ifdefs that clutter the HTTP code (and there's
> > a patch at the en
On Tue, Apr 4, 2017 at 4:54 AM, Jeff King wrote:
> My feeling is that this is old enough to stop caring about. Which means
> we can drop some of the #ifdefs that clutter the HTTP code (and there's
> a patch at the end of this mail dropping support for everything older
> than 7.11.1). But that made
> On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:
>
>> If we declared 7.16.0 as a cutoff, we could unconditionally define
>> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.
>
> That version came out 11 years ago. Here's what that patch would look
> like (on top of my other on
On Mon, Apr 03, 2017 at 10:54:38PM -0400, Jeff King wrote:
> If we declared 7.16.0 as a cutoff, we could unconditionally define
> USE_CURL_MULTI, which gets rid of quite a few messy ifdefs.
That version came out 11 years ago. Here's what that patch would look
like (on top of my other one, but not
27 matches
Mail list logo
