You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2005/01/23 15:28:46 UTC
Proposal: R-T-C and packaging files
Hi all,
There has been an ongoing problem with httpd and system package build
scripts. Over time, changes have been backported to the build system
(autoconf, etc) which breaks packaging scripts and files such as the RPM
spec file.
The packaging files are then fixed, but the backport sits in the STATUS
file without enough votes to move it forward, and eventually a release
is made with broken packaging.
What I propose is that changes to packaging files (such as
build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just
as documentation files are. This will not apply if other files (source
code for example) are involved in the change.
Thoughts?
Regards,
Graham
--
Re: Proposal: R-T-C and packaging files
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 23, 2005, at 9:28 AM, Graham Leggett wrote:
> Hi all,
>
> There has been an ongoing problem with httpd and system package build
> scripts. Over time, changes have been backported to the build system
> (autoconf, etc) which breaks packaging scripts and files such as the
> RPM spec file.
>
> The packaging files are then fixed, but the backport sits in the
> STATUS file without enough votes to move it forward, and eventually a
> release is made with broken packaging.
>
> What I propose is that changes to packaging files (such as
> build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR,
> just as documentation files are. This will not apply if other files
> (source code for example) are involved in the change.
++1 !
Re: Proposal: R-T-C and packaging files
Posted by Erik Abele <er...@codefaktor.de>.
William A. Rowe, Jr. said:
> For a stable branch though - more often such changes should just
> be -vetoed- instead of worked-around. Packaging changes would
> seem to signal breakage, not a reason for a workaround.
> -1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what
> ever your schedule best provides) and then commit. If folks
> object they will speak up - if not - then you aren't hampered.
just my 2 cent: -0 on CTR for the stable branch, +1 on lazy consensus
(for packaging changes).
Cheers,
Erik
Re: Proposal: R-T-C and packaging files
Posted by Paul Querna <ch...@force-elite.com>.
Graham Leggett wrote:
> William A. Rowe, Jr. said:
>
>
>>For a stable branch though - more often such changes should just
>>be -vetoed- instead of worked-around. Packaging changes would
>>seem to signal breakage, not a reason for a workaround.
>
>
>>-1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what
>>ever your schedule best provides) and then commit. If folks
>>object they will speak up - if not - then you aren't hampered.
>
>
+1 for packaging issues.
-Paul
Re: Proposal: R-T-C and packaging files
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. said:
> For a stable branch though - more often such changes should just
> be -vetoed- instead of worked-around. Packaging changes would
> seem to signal breakage, not a reason for a workaround.
> -1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what
> ever your schedule best provides) and then commit. If folks
> object they will speak up - if not - then you aren't hampered.
Seems reasonable.
+1.
Regards,
Graham
--
Re: Proposal: R-T-C and packaging files
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:28 AM 1/23/2005, Graham Leggett wrote:
>The packaging files are then fixed, but the backport sits in the STATUS file without enough votes to move it forward, and eventually a release is made with broken packaging.
I think we discussed this at ApacheCon - an .rpm spec file,
.pkg description, or whatever should be considered a platform
issue - left to the platform maintainer and a handful of helpers
to maintain under lazy concensus. Propose your fix, and let the
few who follow the issue pipe up if they like.
For a stable branch though - more often such changes should just
be -vetoed- instead of worked-around. Packaging changes would
seem to signal breakage, not a reason for a workaround.
>What I propose is that changes to packaging files (such as build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just as documentation files are. This will not apply if other files (source code for example) are involved in the change.
-1 not CTR. Lazy consensus. Propose, give 3 - 5 days (what
ever your schedule best provides) and then commit. If folks
object they will speak up - if not - then you aren't hampered.
And documentation is (more often than not) R-T-C, at least in
terms of translations, etc.
Brad and I have operated that way for years.
Bill
Re: Proposal: R-T-C and packaging files
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jan 23, 2005 at 04:28:46PM +0200, Graham Leggett wrote:
> What I propose is that changes to packaging files (such as
> build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just
> as documentation files are. This will not apply if other files (source
> code for example) are involved in the change.
Seems reasonable. -- justin
Re: Proposal: R-T-C and packaging files
Posted by André Malo <nd...@perlig.de>.
* Enrico Weigelt wrote:
> * André Malo <nd...@perlig.de> wrote:
Would have been interesting, what exactly you were referring to.
> Could be solved with an well-engineered, deterministic buildsystem ...
> Exactly this one which autoconf isnt.
Sounds like a flame bot. Could you please turn it off? Thanks.
nd
--
Da fällt mir ein, wieso gibt es eigentlich in Unicode kein
"i" mit einem Herzchen als Tüpfelchen? Das wär sooo süüss!
-- Björn Höhrmann in darw
Re: Proposal: R-T-C and packaging files
Posted by Graham Leggett <mi...@sharp.fm>.
Enrico Weigelt wrote:
> Could be solved with an well-engineered, deterministic buildsystem ...
> Exactly this one which autoconf isnt.
Sounds like using a sledgehammer to knock in a nail to me :(
Regards,
Graham
--
Re: Proposal: R-T-C and packaging files
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jan 23, 2005 at 03:48:39PM +0100, Enrico Weigelt wrote:
> Could be solved with an well-engineered, deterministic buildsystem ...
> Exactly this one which autoconf isnt.
How exactly do you think removing autoconf (and only autoconf) would help
packagers? I certainly don't see how this is related at all. -- justin
Re: Proposal: R-T-C and packaging files
Posted by Enrico Weigelt <we...@metux.de>.
* André Malo <nd...@perlig.de> wrote:
Could be solved with an well-engineered, deterministic buildsystem ...
Exactly this one which autoconf isnt.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Re: Proposal: R-T-C and packaging files
Posted by André Malo <nd...@perlig.de>.
* Graham Leggett wrote:
> Hi all,
>
> There has been an ongoing problem with httpd and system package build
> scripts. Over time, changes have been backported to the build system
> (autoconf, etc) which breaks packaging scripts and files such as the RPM
> spec file.
>
> The packaging files are then fixed, but the backport sits in the STATUS
> file without enough votes to move it forward, and eventually a release
> is made with broken packaging.
>
> What I propose is that changes to packaging files (such as
> build/rpm/httpd.spec.in, build/pkg/buildpkg.sh, etc) should be CTR, just
> as documentation files are. This will not apply if other files (source
> code for example) are involved in the change.
>
> Thoughts?
I tend to agree.
nd
--
"Eine Eieruhr", erklärt ihr Hermann, "besteht aus einem Ei. Du nimmst
das Ei und kochst es. Wenn es hart ist, sind fünf Minuten um. Dann weißt
du, daß die Zeit vergangen ist."
-- Hannes Hüttner in "Das Blaue vom Himmel"