Re: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread Yann Ylavic 
I like this "attic" idea better, resurrecting something is easier if
you can find that it ever existed (w/o diving into svn history, à la
"svn delete").

On Thu, Oct 26, 2017 at 10:17 AM, Stefan Eissing
 wrote:
> Thanks Greg. The proposed change is purely aestetic. You could make a
> dir /branches/attic" and move all candidates there. People wanting to
> "resurrect" them can simply move them back. This is not RCS.
>
>> Am 25.10.2017 um 20:21 schrieb Greg Stein :
>>
>> To be clear: "delete" simply means "no longer seen in HEAD". This is version 
>> control. The data cannot truly be deleted, so it can always be revived. Or 
>> reviewed.
>>
>> On Oct 25, 2017 12:31, "Marion & Christophe JAILLET" 
>>  wrote:
>> Just to mention that before giving a +1, I made a copy of these repositories 
>> in order to dig later on, in order to see if something useful seems to be 
>> there.
>> Don't have that much time these days to play with httpd, but will do and 
>> will report anything that looks valuable.
>>
>> CJ
>>
>>
>> Le 25/10/2017 à 14:29, Jim Jagielski a écrit :
>> Are there anything of "value" in any of those branches?
>>
>> If not, prune away!
>>
>> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr  wrote:
>>
>> On Tue, Oct 24, 2017 at 3:28 AM, Steffen  wrote:
>> On Tuesday 24/10/2017 at 10:26, Steffen wrote:
>>
>> Can someone clean up the not needed anymore  backports/branches
>> http://svn.apache.org/viewvc/httpd/httpd/branches/
>>
>> httpd 2.4.1 was tagged at r1243503.
>>
>> I'd propose we start by pruning all working branches not updated since this 
>> tag.
>>
>> Thoughts?
>>
>>
>

AW: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread Plüm , Rüdiger , Vodafone Group 
+1

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 26. Oktober 2017 10:31
> An: httpd-dev 
> Betreff: Re: Pruning working branches (Was: Re: Why?)
> 
> I like this "attic" idea better, resurrecting something is easier if
> you can find that it ever existed (w/o diving into svn history, à la
> "svn delete").
> 
> On Thu, Oct 26, 2017 at 10:17 AM, Stefan Eissing
>  wrote:
> > Thanks Greg. The proposed change is purely aestetic. You could make a
> > dir /branches/attic" and move all candidates there. People wanting to
> > "resurrect" them can simply move them back. This is not RCS.
> >
> >> Am 25.10.2017 um 20:21 schrieb Greg Stein :
> >>
> >> To be clear: "delete" simply means "no longer seen in HEAD". This is
> version control. The data cannot truly be deleted, so it can always be
> revived. Or reviewed.
> >>
> >> On Oct 25, 2017 12:31, "Marion & Christophe JAILLET"
>  wrote:
> >> Just to mention that before giving a +1, I made a copy of these
> repositories in order to dig later on, in order to see if something
> useful seems to be there.
> >> Don't have that much time these days to play with httpd, but will do
> and will report anything that looks valuable.
> >>
> >> CJ
> >>
> >>
> >> Le 25/10/2017 à 14:29, Jim Jagielski a écrit :
> >> Are there anything of "value" in any of those branches?
> >>
> >> If not, prune away!
> >>
> >> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr 
> wrote:
> >>
> >> On Tue, Oct 24, 2017 at 3:28 AM, Steffen 
> wrote:
> >> On Tuesday 24/10/2017 at 10:26, Steffen wrote:
> >>
> >> Can someone clean up the not needed anymore  backports/branches
> >> http://svn.apache.org/viewvc/httpd/httpd/branches/
> >>
> >> httpd 2.4.1 was tagged at r1243503.
> >>
> >> I'd propose we start by pruning all working branches not updated
> since this tag.
> >>
> >> Thoughts?
> >>
> >>
> >

Re: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread Stefan Eissing 
Thanks Greg. The proposed change is purely aestetic. You could make a dir 
/branches/attic" and move all candidates there. People wanting to "resurrect" 
them can simply move them back. This is not RCS.

> Am 25.10.2017 um 20:21 schrieb Greg Stein :
> 
> To be clear: "delete" simply means "no longer seen in HEAD". This is version 
> control. The data cannot truly be deleted, so it can always be revived. Or 
> reviewed.
> 
> On Oct 25, 2017 12:31, "Marion & Christophe JAILLET" 
>  wrote:
> Just to mention that before giving a +1, I made a copy of these repositories 
> in order to dig later on, in order to see if something useful seems to be 
> there.
> Don't have that much time these days to play with httpd, but will do and will 
> report anything that looks valuable.
> 
> CJ
> 
> 
> Le 25/10/2017 à 14:29, Jim Jagielski a écrit :
> Are there anything of "value" in any of those branches?
> 
> If not, prune away!
> 
> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr  wrote:
> 
> On Tue, Oct 24, 2017 at 3:28 AM, Steffen  wrote:
> On Tuesday 24/10/2017 at 10:26, Steffen wrote:
> 
> Can someone clean up the not needed anymore  backports/branches
> http://svn.apache.org/viewvc/httpd/httpd/branches/
> 
> httpd 2.4.1 was tagged at r1243503.
> 
> I'd propose we start by pruning all working branches not updated since this 
> tag.
> 
> Thoughts?
> 
>

Re: apr "the latest available version"

2017-10-26 Thread Reindl Harald 



Am 25.10.2017 um 18:26 schrieb Daniel Gruno:

On 10/25/2017 06:23 PM, Reindl Harald wrote:

it is *not* helpful when you already have deployed httpd 2.4.29 that you
by random luck face a apr-1.6.3 build on the fedora buildserver


I'd suggest you post this to d...@apr.apache.org if you want them to
update their dist page.


i am not going to subscribe to every single devel list out there for 
single issues and had already submitted a bug as 1.6.x was over months 
invisible when you expect that the top part of the page is recent


both are apache projects, i assume that on this list are also 
apr-developers and when you look at mails like this one such issues 
should be sovled somehow and if it only means doing nothing else than a 
ordinary folder listing and remove the facny always outdated top paragraph


On Wed, Oct 25, 2017 at 4:02 PM, Craig Young  wrote:
> I'm not sure if this is what is referred to in the Apache 2.4.29 
announcement, but please note that the Apache Portable Runtime v1.6.3 
release resolved memory safety issues I found in functions used within 
HTTP server.  This was released in conjunction with 2.4.29.



(https://koji.fedoraproject.org/koji/buildinfo?buildID=989222) either
this stuff on top should be removed completly or properly updated, if
it's not there at all one would look at the filelist

https://www.apache.org/dist/apr/

Important Notices
     Download from your nearest mirror site!
     APR 1.6.2 is the latest available version
     APR-util 1.6.0 is the latest available version
     APR-iconv 1.2.1 is the latest available version

APR 1.6.2 is the latest available version

APR 1.6.2 has been released, and should be considered "general
availability".
APR-util 1.6.0 is the latest available version

APR-util 1.6.0 has been released, and should be considered "general
availability"

Re: apr "the latest available version"

2017-10-26 Thread Graham Leggett 
On 26 Oct 2017, at 12:31 PM, Reindl Harald  wrote:

> i am not going to subscribe to every single devel list out there for single 
> issues and had already submitted a bug as 1.6.x was over months invisible 
> when you expect that the top part of the page is recent

Please tone down the aggressive behaviour, it is not fair on anyone in the 
Apache community to have to endure abuse like this over what was obviously an 
oversight.

Also, please ensure you post to the correct list as a courtesy.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: apr "the latest available version"

2017-10-26 Thread Reindl Harald 



Am 26.10.2017 um 12:38 schrieb Graham Leggett:

On 26 Oct 2017, at 12:31 PM, Reindl Harald  wrote:


i am not going to subscribe to every single devel list out there for single 
issues and had already submitted a bug as 1.6.x was over months invisible when 
you expect that the top part of the page is recent


Please tone down the aggressive behaviour


i don't see any aggressive here

sorry for pointing out a issue trying to help others which probably 
don't realize and hence not update their servers while i personally 
could not care less after knowing that i have to scroll down

Re: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread Rainer Jung 

Am 26.10.2017 um 10:30 schrieb Yann Ylavic:

I like this "attic" idea better, resurrecting something is easier if
you can find that it ever existed (w/o diving into svn history, à la
"svn delete").


+1

Re: apr "the latest available version"

2017-10-26 Thread Daniel Gruno 
On 10/26/2017 12:44 PM, Reindl Harald wrote:
> 
> 
> Am 26.10.2017 um 12:38 schrieb Graham Leggett:
>> On 26 Oct 2017, at 12:31 PM, Reindl Harald 
>> wrote:
>>
>>> i am not going to subscribe to every single devel list out there for
>>> single issues and had already submitted a bug as 1.6.x was over
>>> months invisible when you expect that the top part of the page is recent
>>
>> Please tone down the aggressive behaviour
> 
> i don't see any aggressive here
> 
> sorry for pointing out a issue trying to help others which probably
> don't realize and hence not update their servers while i personally
> could not care less after knowing that i have to scroll down

I, and many others do, and this is not the first time we've had to deal
with negativities. It is a toll on our mental states in the long run -
something I'd rather be without. I have unsubscribed reindl from the
list, he is not welcome for the time being.

Re: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread Eric Covener 
On Thu, Oct 26, 2017 at 4:30 AM, Yann Ylavic  wrote:
> I like this "attic" idea better, resurrecting something is easier if
> you can find that it ever existed (w/o diving into svn history, à la
> "svn delete").

+1

Re: Pruning working branches (Was: Re: Why?)

2017-10-26 Thread William A Rowe Jr 
On Thu, Oct 26, 2017 at 3:17 AM, Stefan Eissing
 wrote:
> You could make a dir /branches/attic" and move all candidates there. People 
> wanting to "resurrect" them can simply move them back. This is not RCS.

+1