Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 767F7200D24 for ; Tue, 24 Oct 2017 10:26:52 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 75086160BE0; Tue, 24 Oct 2017 08:26:52 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 6D3E5160BDB for ; Tue, 24 Oct 2017 10:26:51 +0200 (CEST) Received: (qmail 67856 invoked by uid 500); 24 Oct 2017 08:26:50 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 67846 invoked by uid 99); 24 Oct 2017 08:26:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Oct 2017 08:26:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 90D0F1A13D5 for ; Tue, 24 Oct 2017 08:26:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=apachelounge.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id fWQH6-7-_Wn2 for ; Tue, 24 Oct 2017 08:26:46 +0000 (UTC) Received: from land10web.com (land10web.com [80.101.236.247]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id B81825FDBE for ; Tue, 24 Oct 2017 08:26:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apachelounge.com; s=default; t=1508833604; bh=SQ0u2BHb97RWWnCZiRi311jA4DtHRicMjM3TTS6SXIY=; h=From:To:Subject:Date; b=fBGO4nKE7IdNr/H4bSTT/mQdOzZtcozgjQpdGhD1L+aXltHEU2w08F8Pgeg+Aoi5q JKo4GQVIBxAYtsoJ3/J3QiQRna2ZeTU3DaIW/L1WrlcDztglPS4XIbVOMCSWyFUlzR 33sb5G4jLHFfXNpUgX3RmMtTC68QhQvBjn99aRIE= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=127.0.0.1; From: Steffen To: Subject: Re: Why tag 2.5.0? [Was: Re: Tagging 2.4.29 / 2.5.0-{alpha/beta?}today] Date: Tue, 24 Oct 2017 10:26:37 +0200 Message-ID: <59eef93d.cb0.2348.4b11@land10.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_SW_19323_1508833597_mpa=" X-Originating-IP: 127.0.0.1 X-Mailer: SurgeWeb - Ajax Webmail Client archived-at: Tue, 24 Oct 2017 08:26:52 -0000 This is a multi-part message in MIME format. ------=_SW_19323_1508833597_mpa= Content-Type: text/plain; charset=us-ascii; format=flowed Can someone clean up the not needed anymore backports/branches at http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby=date On Tuesday 24/10/2017 at 10:12, Stefan Eissing wrote: > FTR: I refuse any discussion where people, already in the initial > statements, discuss each others merit and downfalls and whatnot. > > If you want to talk about technical stuff and/or propose a project > plan, > start a new thread without all that destructive crap I will not waste > any more time than this mail about. > > Cheers, > > Stefan > >> >> Am 24.10.2017 um 00:17 schrieb William A Rowe Jr >> : >> >> Jim, you have very vocally and hostility reacted to *all* discussion >> of improving the release process at the httpd project. >> >> The project bylaws are clear, no individual PMC member may >> block a release (the PMC chair may, owing to the fact that they >> alone represent the board as the appointed VP, that's another >> topic entirely.) >> >> I have no evidence that you perceive a problem with the httpd >> release status quo, and no evidence that you have reconsidered >> your positions expressed during the past year, so I presume >> none of these are changed, and further discussion is not >> necessary at this step. >> >> You've insisted we maintain the status quo with no changes, >> and I'm proceeding based on our historical and documented >> practices to move the project along. This is an obvious case >> of agree-to-disagree, I accept your demand to hold to precedent, >> and will proceed under that structure to ask wiling users to help >> us determine the usability of the current code trunk/. In short, >> you have engendered this solution. >> >> This is only a starting point, not a result. Multiple -alphas will >> usually occur, and I can't foresee any conclusions on a roadmap >> before the end of the year, and a beta-worthy candidate before >> the end of winter. >> >> (Northern) winter tends to be a period of greater activity, summers >> are very quiet in comparison. The approach to progress under our >> existing model is incremental; code and release, code and release, >> until the committee agrees that the code is ready to move from an >> -alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This >> approach avoids all personal conflicts by getting away from >> people debating opinion or process, and going back to debating >> the features and code. >> >> I am reading your reply as adding additional process which does >> not exist, and appears to be thrown-up roadblocks. I'll ignore such >> attempts to introduce process until any proposed process has the >> majority +1 support by the project. If others here at httpd want >> to begin defining the structure of 2.6.0/3.0.0 (the next possible >> GA release, because 2.5.x is not GA, by policy), I'm all for it. >> It's not a prereq to begin. >> >> http://httpd.apache.org/dev/release.html >> >> By "vetoed tag" it does not mean you can veto a tag. That wording >> means that there is no code at present which carries a veto. I'm >> unaware of any code in trunk that is vetoed in the 2.5.x development >> trunk branch. >> >> Please inform within 72 hours of what you are vetoing from -alpha >> examination, so that I can remove or route around it and avoid any >> unnecessary tags. >> >> The rules were designed from day 1 of the ASF as a foundation >> that no one individual can block forward progress of the project, >> any PMC member may branch, or tag. The majority decision of >> the project decides whether that tag is adopted as a release >> (even -alpha requires a majority, 3 +1's!) >> >> As the saying goes "We won't know till we try"... let's see if we >> have collectively treated trunk/ well, and whether adventurous >> users on the bleeding edge like what they see. >> >> >> >> On Mon, Oct 23, 2017 at 4:32 PM, Jim Jagielski >> wrote: >>> >>> The issue obviously isn't in the *tagging*. It is the unknown >>> aspect of what is expected AFTER the tagging. >>> >>> I see the tagging as simply a mechanism to force action >>> upon the PMC to go down a route which the PMC has not >>> decided, from what I can tell, to go down. Maybe I'm wrong. >>> But your reply tends to support that interpretation. The tag, per >>> se, is not the goal. The goal is to "push" 2.5.0 when, again >>> from what I can tell, the PMC has not decided that such >>> a push is warranted/needed/desired/whatever. >>> >>> So if you want to tag, first generate a roadmap, that can be >>> shared and discussed with the PMC, and the dev community, >>> what that 1st step is intended to lead us to. But let's >>> not pretend that such tagging is simply noting a SVN revision. >>> >>> You may complain that I "single handedly" do Foo and Bar >>> and other dictatorial and dangerous stuff, but AFAIK, I've >>> never done or proposed anything w/o bringing it up >>> to the list 1st (ala PROXY support, mod_wsgi, health >>> checks... etc...). Even w/ releases and tags I give >>> people more than 24hours notice. Unless, of course, >>> your tag was under Lazy Consensus, in which case my >>> "veto" was valid, if more "strong" than required. In >>> which case, I am sorry for that. > ------=_SW_19323_1508833597_mpa= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Can someone clean up the not needed anymore  backports/branches at=  
http://svn.apache.org/viewvc/httpd/httpd/branches/?sortby= =3ddate 


 
On Tuesday 24/10/2017 at 10:12, Stefan Eissing= wrote:
FTR: I refuse any discussion where = people, already in the initial
statements, discuss each others merit and= downfalls and whatnot.

If you want to talk about technical stuff and= /or propose a project plan,
start a new thread without all that destructi= ve crap I will not waste
any more time than this mail about.

Cheer= s,

Stefan

Am 24.10.2017 um 00:17 sc= hrieb William A Rowe Jr <wrowe@rowe-clan.net>:

Jim, you have = very vocally and hostility reacted to *all* discussion
of improving the = release process at the httpd project.

The project bylaws are clear,= no individual PMC member may
block a release (the PMC chair may, owing = to the fact that they
alone represent the board as the appointed VP, tha= t's another
topic entirely.)

I have no evidence that you percei= ve a problem with the httpd
release status quo, and no evidence that you= have reconsidered
your positions expressed during the past year, so I p= resume
none of these are changed, and further discussion is not
nece= ssary at this step.

You've insisted we maintain the status quo with= no changes,
and I'm proceeding based on our historical and documented practices to move the project along. This is an obvious case
of agree= -to-disagree, I accept your demand to hold to precedent,
and will procee= d under that structure to ask wiling users to help
us determine the usab= ility of the current code trunk/. In short,
you have engendered this sol= ution.

This is only a starting point, not a result. Multiple -alpha= s will
usually occur, and I can't foresee any conclusions on a roadmap before the end of the year, and a beta-worthy candidate before
the en= d of winter.

(Northern) winter tends to be a period of greater acti= vity, summers
are very quiet in comparison. The approach to progress und= er our
existing model is incremental; code and release, code and release= ,
until the committee agrees that the code is ready to move from an
= -alpha to a -beta, from a -beta to graduate to 2.6.0/3.0.0. This
approac= h avoids all personal conflicts by getting away from
people debating opi= nion or process, and going back to debating
the features and code.
<= br> I am reading your reply as adding additional process which does
not = exist, and appears to be thrown-up roadblocks. I'll ignore such
attempts= to introduce process until any proposed process has the
majority +1 sup= port by the project. If others here at httpd want
to begin defining the = structure of 2.6.0/3.0.0 (the next possible
GA release, because 2.5.x is= not GA, by policy), I'm all for it.
It's not a prereq to begin.
htt= p://httpd.apache.org/dev/release.html

By "vetoed tag" it does n= ot mean you can veto a tag. That wording
means that there is no code at = present which carries a veto. I'm
unaware of any code in trunk that is v= etoed in the 2.5.x development
trunk branch.

Please inform with= in 72 hours of what you are vetoing from -alpha
examination, so that I c= an remove or route around it and avoid any
unnecessary tags.

Th= e rules were designed from day 1 of the ASF as a foundation
that no one = individual can block forward progress of the project,
any PMC member may= branch, or tag. The majority decision of
the project decides whether th= at tag is adopted as a release
(even -alpha requires a majority, 3 +1's!= )

As the saying goes "We won't know till we try"... let's see if we=
have collectively treated trunk/ well, and whether adventurous
user= s on the bleeding edge like what they see.



On Mon, Oct 23= , 2017 at 4:32 PM, Jim Jagielski <jim@jagunet.com> wrote:
The issue obviously isn't in the *tagging*. It is the unkn= own
aspect of what is expected AFTER the tagging.

I see the tag= ging as simply a mechanism to force action
upon the PMC to go down a rou= te which the PMC has not
decided, from what I can tell, to go down. Mayb= e I'm wrong.
But your reply tends to support that interpretation. The ta= g, per
se, is not the goal. The goal is to "push" 2.5.0 when, again
= from what I can tell, the PMC has not decided that such
a push is warran= ted/needed/desired/whatever.

So if you want to tag, first generate = a roadmap, that can be
shared and discussed with the PMC, and the dev co= mmunity,
what that 1st step is intended to lead us to. But let's
not= pretend that such tagging is simply noting a SVN revision.

You may= complain that I "single handedly" do Foo and Bar
and other dictatorial = and dangerous stuff, but AFAIK, I've
never done or proposed anything w/o= bringing it up
to the list 1st (ala PROXY support, mod_wsgi, health
= checks... etc...). Even w/ releases and tags I give
people more than 24= hours notice. Unless, of course,
your tag was under Lazy Consensus, in w= hich case my
"veto" was valid, if more "strong" than required. In
wh= ich case, I am sorry for that.


------=_SW_19323_1508833597_mpa=--