Re: Proposal: R-T-C and packaging files
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. > > Seems reasonable. > > +1. > Agreed. But I was also +1 on the original. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "There 10 types of people: those who read binary and everyone else."
Re: Proposal: R-T-C and packaging files
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 smime.p7s Description: S/MIME cryptographic signature
Re: Proposal: R-T-C and packaging files
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
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
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
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
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
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
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 -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposal: R-T-C and packaging files
* Enrico Weigelt wrote: > * André Malo <[EMAIL PROTECTED]> 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
* André Malo <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: Proposal: R-T-C and packaging files
* 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"
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 -- smime.p7s Description: S/MIME Cryptographic Signature
