Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 00:11 Sat 18 Aug , Mike Frysinger wrote: > On Friday 17 August 2007, Alec Warner wrote: > > On 8/17/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > what do you think of comment #14 in Bug 185567 ? > > > > > > i think that plus having hooks for all phase funcs ... > > > > +1 for pkg_maint > > i was thinking more mnt_qa since the new phase will be like "maint_" or "mnt_" Yeah I like it. Please be verbose with naming though, maint_ rather than mnt_, so it's clear and self-documenting. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Alec Warner wrote: > On 8/17/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Friday 17 August 2007, Donnie Berkholz wrote: > > > On 13:40 Fri 17 Aug , Mike Frysinger wrote: > > > > On Friday 17 August 2007, Hans de Graaff wrote: > > > > > On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > > > > > > Also known as FEATURES=stricter. > > > > > > > > > > Unfortunately FEATURES=stricter stopped being really useful when it > > > > > started to die on bad programming practices QA messages. These > > > > > happen a lot and often are beyond our direct control because it may > > > > > not be easy to fix them or to convince upstream to fix them. I've > > > > > turned off stricter for this reason. > > > > > > > > i can make it more selective about which ones actually die ... > > > > > > Would be most useful if the things to die on were configurable, via > > > make.conf and possibly some files in /etc/portage/ where you could drop > > > in extra checks. > > > > what do you think of comment #14 in Bug 185567 ? > > > > i think that plus having hooks for all phase funcs ... > > +1 for pkg_maint i was thinking more mnt_qa since the new phase will be like "maint_" or "mnt_" -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 8/17/07, Peter Volkov <[EMAIL PROTECTED]> wrote: > В Птн, 17/08/2007 в 13:18 -0700, Donnie Berkholz пишет: > > On 13:40 Fri 17 Aug , Mike Frysinger wrote: > > > On Friday 17 August 2007, Hans de Graaff wrote: > > > > Unfortunately FEATURES=stricter stopped being really useful > > > > > > i can make it more selective about which ones actually die ... > > > > Would be most useful if the things to die on were configurable, via > > make.conf > > and possibly some files in /etc/portage/ where you could drop in extra > > checks. > > But is it good idea to let developers disable QA checks? Seems that it's > better to set QA checks in profile (arch team decision). Of course for > overlays only it'll be possible to redefine this. Developers = Users. Many users have wanted the checks and dies reduced for a long time. Most users could care less about half the tests that run. I know I disable most of the crap that runs after src_install(). QA has always been and will always be a pragmatic effort. You cannot force people to run the software you want and you can't even force them to run repoman before commiting even though it's 'required'. You cannot force QA. In the end the only requirement is to not break shit, and we fail to meet that even with our current tools. │ИМ╒┤^╬╖╤┼(╝ ┼X╖┌X╛
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 8/17/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Friday 17 August 2007, Donnie Berkholz wrote: > > On 13:40 Fri 17 Aug , Mike Frysinger wrote: > > > On Friday 17 August 2007, Hans de Graaff wrote: > > > > On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > > > > > Also known as FEATURES=stricter. > > > > > > > > Unfortunately FEATURES=stricter stopped being really useful when it > > > > started to die on bad programming practices QA messages. These happen a > > > > lot and often are beyond our direct control because it may not be easy > > > > to fix them or to convince upstream to fix them. I've turned off > > > > stricter for this reason. > > > > > > i can make it more selective about which ones actually die ... > > > > Would be most useful if the things to die on were configurable, via > > make.conf and possibly some files in /etc/portage/ where you could drop in > > extra checks. > > what do you think of comment #14 in Bug 185567 ? > > i think that plus having hooks for all phase funcs ... > -mike > +1 for pkg_maint -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
В Птн, 17/08/2007 в 13:18 -0700, Donnie Berkholz пишет: > On 13:40 Fri 17 Aug , Mike Frysinger wrote: > > On Friday 17 August 2007, Hans de Graaff wrote: > > > Unfortunately FEATURES=stricter stopped being really useful > > > > i can make it more selective about which ones actually die ... > > Would be most useful if the things to die on were configurable, via make.conf > and possibly some files in /etc/portage/ where you could drop in extra checks. But is it good idea to let developers disable QA checks? Seems that it's better to set QA checks in profile (arch team decision). Of course for overlays only it'll be possible to redefine this. Also speaking about "bad programming practice" seems that it's good to be able to disable them on ebuild basis as some upstreams (e.g. wireshark) are really interested in any compiler warnings and I report such thing for them. -- Peter. signature.asc Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Donnie Berkholz wrote: > On 13:40 Fri 17 Aug , Mike Frysinger wrote: > > On Friday 17 August 2007, Hans de Graaff wrote: > > > On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > > > > Also known as FEATURES=stricter. > > > > > > Unfortunately FEATURES=stricter stopped being really useful when it > > > started to die on bad programming practices QA messages. These happen a > > > lot and often are beyond our direct control because it may not be easy > > > to fix them or to convince upstream to fix them. I've turned off > > > stricter for this reason. > > > > i can make it more selective about which ones actually die ... > > Would be most useful if the things to die on were configurable, via > make.conf and possibly some files in /etc/portage/ where you could drop in > extra checks. what do you think of comment #14 in Bug 185567 ? i think that plus having hooks for all phase funcs ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 13:40 Fri 17 Aug , Mike Frysinger wrote: > On Friday 17 August 2007, Hans de Graaff wrote: > > On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > > > Also known as FEATURES=stricter. > > > > Unfortunately FEATURES=stricter stopped being really useful when it > > started to die on bad programming practices QA messages. These happen a > > lot and often are beyond our direct control because it may not be easy > > to fix them or to convince upstream to fix them. I've turned off > > stricter for this reason. > > i can make it more selective about which ones actually die ... Would be most useful if the things to die on were configurable, via make.conf and possibly some files in /etc/portage/ where you could drop in extra checks. Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-17 at 13:40 -0400, Mike Frysinger wrote: > On Friday 17 August 2007, Hans de Graaff wrote: > > Unfortunately FEATURES=stricter stopped being really useful when it > > started to die on bad programming practices QA messages. These happen a > > lot and often are beyond our direct control because it may not be easy > > to fix them or to convince upstream to fix them. I've turned off > > stricter for this reason. > > i can make it more selective about which ones actually die ... That would be useful, because I'm sure that different people have different ideas about which checks to die on, and introducing more FEATURES for this seems to take it a bit too far. > > dodoc stuff on the other hand is within our control, so I'd be happy to > > see ebuilds die because of that, either with stricter or even with > > strict. > > FEATURES=strict is inappropriate as it implies things like Manifest checking > and is the default for everyone Agreed if it is the default. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Friday 17 August 2007, Hans de Graaff wrote: > On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > > Also known as FEATURES=stricter. > > Unfortunately FEATURES=stricter stopped being really useful when it > started to die on bad programming practices QA messages. These happen a > lot and often are beyond our direct control because it may not be easy > to fix them or to convince upstream to fix them. I've turned off > stricter for this reason. i can make it more selective about which ones actually die ... > dodoc stuff on the other hand is within our control, so I'd be happy to > see ebuilds die because of that, either with stricter or even with > strict. FEATURES=strict is inappropriate as it implies things like Manifest checking and is the default for everyone -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-17 at 18:43 +0200, Vlastimil Babka wrote: > Also known as FEATURES=stricter. Unfortunately FEATURES=stricter stopped being really useful when it started to die on bad programming practices QA messages. These happen a lot and often are beyond our direct control because it may not be easy to fix them or to convince upstream to fix them. I've turned off stricter for this reason. dodoc stuff on the other hand is within our control, so I'd be happy to see ebuilds die because of that, either with stricter or even with strict. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: >> perhaps it'd be useful to introduce an "anal_die". developers run anal >> tests, >> users get sane tests. >> -mike >> >> > > Anal ftw > > -Alec Also known as FEATURES=stricter. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxdAXtbrAj05h3oQRAsUxAJ48+iW/EEhe87Q37xEP/gWwUPmrPACfbS1e rVtezxohQ6Bh+NOTEbWH02c= =uhBq -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
> > perhaps it'd be useful to introduce an "anal_die". developers run anal tests, > users get sane tests. > -mike > > Anal ftw -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tuesday 07 August 2007, Ciaran McCreesh wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Tuesday 07 August 2007, Richard Brown wrote: > > > On 07/08/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > in an ideal world, yes ... in the real world however, i wouldnt > > > > trust it > > > > > > You wouldn't trust what, exactly? A dev to install a package they're > > > bumping? > > > > you cant tell me the build experience a dev goes through mirrors > > exactly the same experience very user sees > > Which is why it's so important to catch failures. yes, it's important to catch *important* failures. a missing doc is generally not such a failure. > Something that builds > correctly for a developer may not build correctly for a user, so being > strict will help prevent users from installing a broken package. it's up to the dev to determine what determines a broken package. a missing TODO in the doc tree does not a broken package make. perhaps it'd be useful to introduce an "anal_die". developers run anal tests, users get sane tests. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tue, 2007-08-07 at 05:40 -0400, Michael Cummings wrote: > > sure...except in another thread, we're saying it's ok for non-maintainers to > bump packages, and i'm here to tell you, when that happens they rarely confirm > things like missing deps or whether it dies during a build. What? They won't confirm if it is missing deps or dies during a build. Sounds like they should not be doing a bump and or committing anything :) Testing is a must before committing anything to the main tree, regardless of it being unstable, masked, etc. > most often, when a > non-maintainer bumps a package its because they need the newer version and > feel > competent enough to do the bump themselves (regardless of whether they know > what > they're looking at). the || die would bite us in those cases Surely if they aren't testing their own bump. Then they really have no business messing with another's package, or any for that matter if they fail to test. > - don't know about > you all, but i get more than annoyed at bugs on package bumps for bumps > that weren't coordinated with the maintainer. It's likely best for maintainers to be contacted before a bump or etc. Not sure I would require it, depends on if one will be responsible for their own actions or not. If not, then it's not right to bump without maintainers knowledge and leave them to deal with any problems. -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tue, 2007-08-07 at 12:20 +0100, Ciaran McCreesh wrote: > Which is why it's so important to catch failures. Something that builds > correctly for a developer may not build correctly for a user, so being > strict will help prevent users from installing a broken package. Personally I agree with being strict and catching as many failures as possible. I would be in favor of catching do* related errors and have them fail only FEATURES="strict", or perhaps "stricter". That will still cause a clear failure for people running with "strict" (and which dev isn't...). If you don't want to be bothered by the QA stuff then simply don't set "strict". I do this on my work laptop, while I use "strict" on my dev machine to catch as many problems as possible so that I can fix them or report bugs on them. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tue, 7 Aug 2007 05:38:25 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Tuesday 07 August 2007, Richard Brown wrote: > > On 07/08/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > in an ideal world, yes ... in the real world however, i wouldnt > > > trust it > > > > You wouldn't trust what, exactly? A dev to install a package they're > > bumping? > > you cant tell me the build experience a dev goes through mirrors > exactly the same experience very user sees Which is why it's so important to catch failures. Something that builds correctly for a developer may not build correctly for a user, so being strict will help prevent users from installing a broken package. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tue, Aug 07, 2007 at 09:36:23AM +0100, Richard Brown wrote: > On 07/08/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > in an ideal world, yes ... in the real world however, i wouldnt trust it > > -mike > > You wouldn't trust what, exactly? A dev to install a package they're > bumping? Surely everyone does that before they call echangelog and > repoman? > sure...except in another thread, we're saying it's ok for non-maintainers to bump packages, and i'm here to tell you, when that happens they rarely confirm things like missing deps or whether it dies during a build. most often, when a non-maintainer bumps a package its because they need the newer version and feel competent enough to do the bump themselves (regardless of whether they know what they're looking at). the || die would bite us in those cases - don't know about you all, but i get more than annoyed at bugs on package bumps for bumps that weren't coordinated with the maintainer. bah. my last two cents. ~mcummings signature.asc Description: Digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tuesday 07 August 2007, Richard Brown wrote: > On 07/08/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > in an ideal world, yes ... in the real world however, i wouldnt trust it > > You wouldn't trust what, exactly? A dev to install a package they're > bumping? you cant tell me the build experience a dev goes through mirrors exactly the same experience very user sees -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Mike Frysinger kirjoitti: > On Monday 06 August 2007, Petteri Räty wrote: >> Mike Frysinger kirjoitti: >>> On Saturday 04 August 2007, Petteri Räty wrote: Steev Klimaszewski kirjoitti: > Vlastimil Babka wrote: >> dodoc calls should have || die and USE=doc should be tested before >> commiting a bump, IMHO > Sorry, I didn't realize my 3 hour compile of $APPLICATION should die > because TODO wasn't around. Vote against || die - it doesn't affect > anything aside from misc docs not being installed, if its really that > important, most people hit the website anyway. (But yes, they should > be corrected and tested before committing) And is the average ebuild 3 hours and haven't you heard about FEATURES noauto? The || die is there for maintainers to spot when version bumping. If you commit a version that's broken with missing TODO and || die you should think about if you are doing everything right... >>> so you think everyone should be an ebuild ninja and know exactly how to >>> recover ? or edit an ebuild to fix the issue themselves (you're assuming >>> dodoc was the last statement in src_install, not the first) >>> -mike >> Yes, every gentoo dev with gentoo-x86 access should know how to deal >> with it. > > we're not talking developers, we're talking users. it's inappropriate for a > user to have spent significant time compiling a package only to have it fail > because TODO does not exist. > -mike > IMHO the best solution for TODO, AUTHORS etc files installation is to handle them in an eclass where they detect which ones of them come with the package. Many eclasses already do this. I think the benefits out weight the problems users might have when playing with ebuilds locally. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On 07/08/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > in an ideal world, yes ... in the real world however, i wouldnt trust it > -mike You wouldn't trust what, exactly? A dev to install a package they're bumping? Surely everyone does that before they call echangelog and repoman? -- Richard Brown -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Tuesday 07 August 2007, William L. Thomson Jr. wrote: > On Mon, 2007-08-06 at 20:23 -0400, Mike Frysinger wrote: > > we're not talking developers, we're talking users. > > Nope, because the point of the die is for the developer to catch it > during testing. Before commit to tree, so the user never has a chance to > experience it. in an ideal world, yes ... in the real world however, i wouldnt trust it -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Mon, 2007-08-06 at 20:23 -0400, Mike Frysinger wrote: > > we're not talking developers, we're talking users. Nope, because the point of the die is for the developer to catch it during testing. Before commit to tree, so the user never has a chance to experience it. > it's inappropriate for a > user to have spent significant time compiling a package only to have it fail > because TODO does not exist. Correct, and that would only occur if a dev was slacking :) Otherwise stuff like missing TODO's or other docs get easily omitted, and ignored. Not the most professional type of error output. So the || dies are more like a fail safe for devs to catch minor stuff like missing docs or etc. QA stuff :) -- William L. Thomson Jr. Gentoo/Java signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Monday 06 August 2007, Petteri Räty wrote: > Mike Frysinger kirjoitti: > > On Saturday 04 August 2007, Petteri Räty wrote: > >> Steev Klimaszewski kirjoitti: > >>> Vlastimil Babka wrote: > dodoc calls should have || die and USE=doc should be tested before > commiting a bump, IMHO > >>> > >>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die > >>> because TODO wasn't around. Vote against || die - it doesn't affect > >>> anything aside from misc docs not being installed, if its really that > >>> important, most people hit the website anyway. (But yes, they should > >>> be corrected and tested before committing) > >> > >> And is the average ebuild 3 hours and haven't you heard about FEATURES > >> noauto? The || die is there for maintainers to spot when version > >> bumping. If you commit a version that's broken with missing TODO and || > >> die you should think about if you are doing everything right... > > > > so you think everyone should be an ebuild ninja and know exactly how to > > recover ? or edit an ebuild to fix the issue themselves (you're assuming > > dodoc was the last statement in src_install, not the first) > > -mike > > Yes, every gentoo dev with gentoo-x86 access should know how to deal > with it. we're not talking developers, we're talking users. it's inappropriate for a user to have spent significant time compiling a package only to have it fail because TODO does not exist. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 21:13 -0400, Luis Francisco Araujo wrote: > > - arch-specific patches/dependencies - If someone is requesting KEYWORD > > changes on a package and it requires a patch or additional dependencies > > for your architecture, you are not only permitted, but really are > > required to make the necessary changes to add support for your > > architecture. > > I am not sure about this last one ... what if for example this patch is > only for supporting a special option of the package for that > architecture, but the maintainer of the package found out that such a > patch is unnecessary and/or will cause other kind of problems in the > package, therefore preferring avoiding such a patch ... or he just > wouldn't like to apply the patch for X or Y; or even further, he just > wouldn't like to have such a package available for that architecture > just yet for Z or W. The vagueness made it kinda hard to follow, but if a maintainer doesn't want their package on an architecture, they need to mark it -arch for that architecture. As it is right now, any arch team can add ~arch without maintainer consent. > The stabilization idea sounds good and it could free maintainers from > filing similar bugs over and over ; but wouldn't this be more and harder > work for arch teams?. For example, they should carefully track the > history of all the packages to know when and if they should stabilize it > yet. Huh? It's simple. The maintainer says "stabilize foo-1.2-r1" which gives a minimum level that all arches should be using. If foo-1.2-r2 comes out, it is up to the arch team to decide if/when to stabilize it, *unless* the maintainer requests a newer version/revision. Basically, the maintainer sets the minimum level they would like stable. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Mike Frysinger kirjoitti: > On Saturday 04 August 2007, Petteri Räty wrote: >> Steev Klimaszewski kirjoitti: >>> Vlastimil Babka wrote: dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO >>> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die >>> because TODO wasn't around. Vote against || die - it doesn't affect >>> anything aside from misc docs not being installed, if its really that >>> important, most people hit the website anyway. (But yes, they should be >>> corrected and tested before committing) >> And is the average ebuild 3 hours and haven't you heard about FEATURES >> noauto? The || die is there for maintainers to spot when version >> bumping. If you commit a version that's broken with missing TODO and || >> die you should think about if you are doing everything right... > > so you think everyone should be an ebuild ninja and know exactly how to > recover ? or edit an ebuild to fix the issue themselves (you're assuming > dodoc was the last statement in src_install, not the first) > -mike Yes, every gentoo dev with gentoo-x86 access should know how to deal with it. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Saturday 04 August 2007, Petteri Räty wrote: > Steev Klimaszewski kirjoitti: > > Vlastimil Babka wrote: > >> dodoc calls should have || die and USE=doc should be tested before > >> commiting a bump, IMHO > > > > Sorry, I didn't realize my 3 hour compile of $APPLICATION should die > > because TODO wasn't around. Vote against || die - it doesn't affect > > anything aside from misc docs not being installed, if its really that > > important, most people hit the website anyway. (But yes, they should be > > corrected and tested before committing) > > And is the average ebuild 3 hours and haven't you heard about FEATURES > noauto? The || die is there for maintainers to spot when version > bumping. If you commit a version that's broken with missing TODO and || > die you should think about if you are doing everything right... so you think everyone should be an ebuild ninja and know exactly how to recover ? or edit an ebuild to fix the issue themselves (you're assuming dodoc was the last statement in src_install, not the first) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 4 Aug 2007 08:06:07 Chris Gianelloni wrote: > - HOMEPAGE changes > - LICENSE changes > - arch-specific patches/dependencies - If someone is requesting KEYWORD > changes on a package and it requires a patch or additional dependencies > for your architecture, you are not only permitted, but really are > required to make the necessary changes to add support for your > architecture. > - Typo fixes > - SRC_URI changes - If the source has moved, feel free to fix it. We > shouldn't have to wait on the maintainer to fix something this simple. > - *DEPEND changes due to changes in your packages - If a package that > you maintain moves, splits, or otherwise changes in a manner that > requires dependency changes on any other packages in the tree, you > should make those changes yourself. You're free to ask for assistance, > of course, but you have the power to make the changes yourself without > asking permission. After all, you're the one "breaking" the package, so > you should be the one to "fix" it. > - Manifest/digest fixes > - metadata.xml changes > So, what do you guys think? From my maintaining perspective it is ok if language support teams come in and fix binding issues with packages that are not specifically for that language but somehow have bindings. Like emacs, bash-completion, perl, python, java, etc. support in subversion. I don't really know some of these languages well, let alone how to best support them in gentoo. I don't mind help from those teams to get that stuff integrated and running well. Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > - arch-specific patches/dependencies - If someone is requesting > KEYWORD changes on a package and it requires a patch or additional > dependencies for your architecture, you are not only permitted, but > really are required to make the necessary changes to add support for > your architecture. arch-specific patches are almost always wrong. The last thing people need is to come along and find some arch developer has applied a bad arch-specific patch without asking first... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sun, 05 Aug 2007 01:56:47 +0200
Jurek Bartuszek <[EMAIL PROTECTED]> wrote:
> Just thinking aloud - why not add some (QA?) notice in the summary
> when dodoc (and possibly other do*'s) fails? One would be instructed
> to file a new bug when he sees it *and*, after all, the package will
> have still been merged successfuly.
That's already in place. dodoc does the following:
echo "dodoc: ${x} does not exist" 1>&2
and anything in stderr is reported as a QA notice. All done. BAM!
Kind regards,
JeR
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Petteri Räty wrote: > Steev Klimaszewski kirjoitti: >> Vlastimil Babka wrote: >> >>> dodoc calls should have || die and USE=doc should be tested before >>> commiting a bump, IMHO >>> >> Sorry, I didn't realize my 3 hour compile of $APPLICATION should die >> because TODO wasn't around. Vote against || die - it doesn't affect >> anything aside from misc docs not being installed, if its really that >> important, most people hit the website anyway. (But yes, they should be >> corrected and tested before committing) >> > > And is the average ebuild 3 hours and haven't you heard about FEATURES > noauto? The || die is there for maintainers to spot when version > bumping. If you commit a version that's broken with missing TODO and || > die you should think about if you are doing everything right... > Just thinking aloud - why not add some (QA?) notice in the summary when dodoc (and possibly other do*'s) fails? One would be instructed to file a new bug when he sees it *and*, after all, the package will have still been merged successfuly. Best regards, Jurek Bartuszek -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Steev Klimaszewski kirjoitti: > Vlastimil Babka wrote: > >> dodoc calls should have || die and USE=doc should be tested before >> commiting a bump, IMHO >> > > Sorry, I didn't realize my 3 hour compile of $APPLICATION should die > because TODO wasn't around. Vote against || die - it doesn't affect > anything aside from misc docs not being installed, if its really that > important, most people hit the website anyway. (But yes, they should be > corrected and tested before committing) > And is the average ebuild 3 hours and haven't you heard about FEATURES noauto? The || die is there for maintainers to spot when version bumping. If you commit a version that's broken with missing TODO and || die you should think about if you are doing everything right... Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Vlastimil Babka wrote: dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO Sorry, I didn't realize my 3 hour compile of $APPLICATION should die because TODO wasn't around. Vote against || die - it doesn't affect anything aside from misc docs not being installed, if its really that important, most people hit the website anyway. (But yes, they should be corrected and tested before committing) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Jeroen Roovers wrote: On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. Another good candidate is correcting errors in anything dodoc is tasked to install. When a TODO or other metafile goes missing in the course of development, I often find ebuilds that still mention them. When I haven't done my arch commit yet, I often correct the error after I check whether the file has simply been moved, by either correcting the path or removing the filename from the dodoc call. dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > There's a couple more that I wouldn't mind seeing as things developers > can do without the maintainer, but I can see how these might be a bit > more controversial, so I'm asking for input. Another good candidate is correcting errors in anything dodoc is tasked to install. When a TODO or other metafile goes missing in the course of development, I often find ebuilds that still mention them. When I haven't done my arch commit yet, I often correct the error after I check whether the file has simply been moved, by either correcting the path or removing the filename from the dodoc call. Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Ask for forgiveness, not permission. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:49:58 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Why should someone have to go through all of that just to make these > minor fixes? Is it really necessary for someone to be required to try > to track down and contact the maintainer to tell them that they put > "ebiuld" instead of "ebuild" into an ebuild? This is my entire point. > Why are we forcing a process that only fosters inefficiency? It is > much simpler to say "if you see one of these, fix it" than to force > every single action to go through the maintainer. Well, for simple typos it's ok. But some of the things you listed might have a bigger impact: SRC_URI changes are ok when the actual files are the same, but if they are somehow different one should really check wih the maintainer to make sure it's still the correct file (same for verifying checksums, unless it's obvious). In the end it comes down that you have to know the consequences of a change, and assuming that the maintainer knows more about a package than you do he should be contacted for non-trivial changes (I'm not saying you have to wait for him at all costs). Of course if a package is plain and unconditionally broken it's ok to act first and talk later IMO, but communication is a requirement, not something you should try to avoid. One thing I completely disagree with however are the metadata.xml changes. Basically you're saying there it's ok to change the maintainer of a package without talking to the existing maintainer first (though I'm sure that wasn't your intention). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 03 Aug 2007 15:47:27 -0700 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Well, I meant that this should be doable without the maintainer's > consent. Meaning, I ask you to stabilize 1.0-r1 and a few weeks > later, you can decide to stabilize -r2 without me having to file a > bug. Basically, the maintainer decides the minimal revision he wants > to go stable (so bugs are fixed, etc) but the revisions after that > are up to the arch teams, unless the maintainer sees a need for > everyone to update (major bug, security). My main goal here is to > reduce the "we have to wait on the maintainer to ask" issue within a > given version of a package. Well, that's probably ok when the higher revision is just a "fixed" version, but if for example it includes new (invasive) patches or other major changes to the ebuild it's a different story. But I'd hope we can rely on common sense here. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > More and more, I am finding developers who are afraid to touch packages > for even minor things if they're not the maintainer. This is a sad > state of affairs and not the reason we have maintainers. We have > maintainers to assure that a package is being taken care of, not to > establish some kind of "territory" over that package. Because of this > misconception, I would like to come up with and document a listing of > things that any ebuild developer can feel free to do to any package > *without* maintainer consent. These are generally all minor things, but > things that I think are important. I'm going to list off the things > that I can think of, and encourage everyone else to speak up if I've > missed something. > > - HOMEPAGE changes > - LICENSE changes > - arch-specific patches/dependencies - If someone is requesting KEYWORD > changes on a package and it requires a patch or additional dependencies > for your architecture, you are not only permitted, but really are > required to make the necessary changes to add support for your > architecture. I am not sure about this last one ... what if for example this patch is only for supporting a special option of the package for that architecture, but the maintainer of the package found out that such a patch is unnecessary and/or will cause other kind of problems in the package, therefore preferring avoiding such a patch ... or he just wouldn't like to apply the patch for X or Y; or even further, he just wouldn't like to have such a package available for that architecture just yet for Z or W. > - Typo fixes > - SRC_URI changes - If the source has moved, feel free to fix it. We > shouldn't have to wait on the maintainer to fix something this simple. > - *DEPEND changes due to changes in your packages - If a package that > you maintain moves, splits, or otherwise changes in a manner that > requires dependency changes on any other packages in the tree, you > should make those changes yourself. You're free to ask for assistance, > of course, but you have the power to make the changes yourself without > asking permission. After all, you're the one "breaking" the package, so > you should be the one to "fix" it. > - Manifest/digest fixes > - metadata.xml changes > > There's a couple more that I wouldn't mind seeing as things developers > can do without the maintainer, but I can see how these might be a bit > more controversial, so I'm asking for input. > > - Version bumps where the only requirement is to "cp" the ebuild > - (for arch teams) Stabilization of new revisions of an already stable > package - An example of this would be being able to stabilize foo-1.0-r2 > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is > stable. > I think these two cases should still be handled by the herd or maintainer of the package. The stabilization idea sounds good and it could free maintainers from filing similar bugs over and over ; but wouldn't this be more and harder work for arch teams?. For example, they should carefully track the history of all the packages to know when and if they should stabilize it yet. > So, what do you guys think? > The other list of things look fine and safe to be changed by any maintainer. Regards, - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9 tKDsHyNAWsliFCx0MMzcIpA= =RGhM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, Aug 03, 2007 at 04:06:25PM -0700, Mike Doty wrote: > >> We really need to get a -commits mailing list going again. If the > >> subject and/or sender are set appropriately, it should be easy to filter > >> for items of interest. > > some of us infra types were entertaining a RS feed for this... > stupid spell checker, that's RSS feed and sorry for mangling your name. Alternatively, we try to create custom headers for the relevant portion of the mails. X-VCS-Repository: gentoo-x86 X-VCS-Directories: profiles/ licenses/ X-VCS-Files: profiles/foo licenses/bar etc? (Suggest more headers that can be gained PURELY from the commit data). -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgphcV8wpptbF.pgp Description: PGP signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Mike Doty wrote: > Donnie Berkowitz wrote: >> Petteri Räty wrote: >>> Philipp Riegger kirjoitti: On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: > So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp >>> No. >> We really need to get a -commits mailing list going again. If the >> subject and/or sender are set appropriately, it should be easy to filter >> for items of interest. >> >> Thanks, >> Donnie >> > some of us infra types were entertaining a RS feed for this... stupid spell checker, that's RSS feed and sorry for mangling your name. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Donnie Berkowitz wrote: > Petteri Räty wrote: >> Philipp Riegger kirjoitti: >>> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: So, what do you guys think? >>> One problem i see is changing versions in the tree but not puting the >>> changes to the wip ebuilds in an overlay or somewhere else. Is there a >>> system to email any changes done to ebuilds maintained by developer X to >>> developer X? Like... selective commit mailinglist? >>> >>> Philipp >>> >> No. > > We really need to get a -commits mailing list going again. If the > subject and/or sender are set appropriately, it should be easy to filter > for items of interest. > > Thanks, > Donnie > some of us infra types were entertaining a RS feed for this... -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: > More and more, I am finding developers who are afraid to touch packages > for even minor things if they're not the maintainer. This is a sad > state of affairs and not the reason we have maintainers. We have > maintainers to assure that a package is being taken care of, not to > establish some kind of "territory" over that package. Because of this > misconception, I would like to come up with and document a listing of > things that any ebuild developer can feel free to do to any package > *without* maintainer consent. These are generally all minor things, but > things that I think are important. I'm going to list off the things > that I can think of, and encourage everyone else to speak up if I've > missed something. Arch bugs that obviously don't affect other arches. An example of this is the pine/uw-imap/c-client stuff which does this make lnx Great! Make linux. Sucks for FreeBSD so I've been changing it to if use elibc_FreeBSD ; then make bsf else make lnx fi Obviously that's very simplified, but you get the idea. In this case I don't expect the ebuild maintainer to use Gentoo/FreeBSD. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 2007-08-04 at 01:23 +0300, Petteri Räty wrote: > Chris Gianelloni kirjoitti: > > More and more, I am finding developers who are afraid to touch packages > > for even minor things if they're not the maintainer. This is a sad > > state of affairs and not the reason we have maintainers. We have > > maintainers to assure that a package is being taken care of, not to > > establish some kind of "territory" over that package. Because of this > > misconception, I would like to come up with and document a listing of > > things that any ebuild developer can feel free to do to any package > > *without* maintainer consent. These are generally all minor things, but > > things that I think are important. I'm going to list off the things > > that I can think of, and encourage everyone else to speak up if I've > > missed something. > > > > I don't find anything wrong with doing the changes after you find that > the maintainer is not responsive. If the maintainer is responsive, he > will a) do the changes b) give you the permission to do it c) give > reasoning on why the proposed changes should not be done. Why should someone have to go through all of that just to make these minor fixes? Is it really necessary for someone to be required to try to track down and contact the maintainer to tell them that they put "ebiuld" instead of "ebuild" into an ebuild? This is my entire point. Why are we forcing a process that only fosters inefficiency? It is much simpler to say "if you see one of these, fix it" than to force every single action to go through the maintainer. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:19 -0700, Mike Doty wrote: > Chris Gianelloni wrote: > [snip] > > > > > There's a couple more that I wouldn't mind seeing as things developers > > can do without the maintainer, but I can see how these might be a bit > > more controversial, so I'm asking for input. > > > > - Version bumps where the only requirement is to "cp" the ebuild > This is more on a per package basis. it's not fair to force the maintainer to > support a new version before he feels it's ready. For example, I'd love to > bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't > want it bumped. It wouldn't be fair to him for me to bump it unless I took > the > burden of support. This is why I said it should be discussed. Also, it might very likely be better to opt-out rather than opt-in on this. I really don't know, myself. > > - (for arch teams) Stabilization of new revisions of an already stable > > package - An example of this would be being able to stabilize foo-1.0-r2 > > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is > > stable. > arch teams are the definitive authority on keywording for their arch. That > said, if there is a disagreement between maintainer and arch team, the support > burden falls on whoever did the keyword. Teamwork should solve this problem > every time. Well, I meant that this should be doable without the maintainer's consent. Meaning, I ask you to stabilize 1.0-r1 and a few weeks later, you can decide to stabilize -r2 without me having to file a bug. Basically, the maintainer decides the minimal revision he wants to go stable (so bugs are fixed, etc) but the revisions after that are up to the arch teams, unless the maintainer sees a need for everyone to update (major bug, security). My main goal here is to reduce the "we have to wait on the maintainer to ask" issue within a given version of a package. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 2007-08-04 at 01:34 +0300, Petteri Räty wrote: > >> So, what do you guys think? > > > > One problem i see is changing versions in the tree but not puting the > > changes to the wip ebuilds in an overlay or somewhere else. Is there a > > system to email any changes done to ebuilds maintained by developer X to > > developer X? Like... selective commit mailinglist? > > No. Might that be an interesting feature for helping devs keep up to date with their maintained packages? Or are there reasons against this? This could of course be muteable... Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Petteri Räty wrote: > Philipp Riegger kirjoitti: >> On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: >>> So, what do you guys think? >> One problem i see is changing versions in the tree but not puting the >> changes to the wip ebuilds in an overlay or somewhere else. Is there a >> system to email any changes done to ebuilds maintained by developer X to >> developer X? Like... selective commit mailinglist? >> >> Philipp >> > > No. We really need to get a -commits mailing list going again. If the subject and/or sender are set appropriately, it should be easy to filter for items of interest. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Philipp Riegger kirjoitti: > On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: >> So, what do you guys think? > > One problem i see is changing versions in the tree but not puting the > changes to the wip ebuilds in an overlay or somewhere else. Is there a > system to email any changes done to ebuilds maintained by developer X to > developer X? Like... selective commit mailinglist? > > Philipp > No. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: > So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Chris Gianelloni kirjoitti: > More and more, I am finding developers who are afraid to touch packages > for even minor things if they're not the maintainer. This is a sad > state of affairs and not the reason we have maintainers. We have > maintainers to assure that a package is being taken care of, not to > establish some kind of "territory" over that package. Because of this > misconception, I would like to come up with and document a listing of > things that any ebuild developer can feel free to do to any package > *without* maintainer consent. These are generally all minor things, but > things that I think are important. I'm going to list off the things > that I can think of, and encourage everyone else to speak up if I've > missed something. > I don't find anything wrong with doing the changes after you find that the maintainer is not responsive. If the maintainer is responsive, he will a) do the changes b) give you the permission to do it c) give reasoning on why the proposed changes should not be done. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Chris Gianelloni wrote: [snip] > > There's a couple more that I wouldn't mind seeing as things developers > can do without the maintainer, but I can see how these might be a bit > more controversial, so I'm asking for input. > > - Version bumps where the only requirement is to "cp" the ebuild This is more on a per package basis. it's not fair to force the maintainer to support a new version before he feels it's ready. For example, I'd love to bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't want it bumped. It wouldn't be fair to him for me to bump it unless I took the burden of support. > - (for arch teams) Stabilization of new revisions of an already stable > package - An example of this would be being able to stabilize foo-1.0-r2 > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is > stable. arch teams are the definitive authority on keywording for their arch. That said, if there is a disagreement between maintainer and arch team, the support burden falls on whoever did the keyword. Teamwork should solve this problem every time. I think the territoriality issue is one of support burden more than anything else. --taco -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Some ideas on how to reduce territoriality
More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of "territory" over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. - HOMEPAGE changes - LICENSE changes - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. - *DEPEND changes due to changes in your packages - If a package that you maintain moves, splits, or otherwise changes in a manner that requires dependency changes on any other packages in the tree, you should make those changes yourself. You're free to ask for assistance, of course, but you have the power to make the changes yourself without asking permission. After all, you're the one "breaking" the package, so you should be the one to "fix" it. - Manifest/digest fixes - metadata.xml changes There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to "cp" the ebuild - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. So, what do you guys think? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
