Re: [gentoo-dev] [soc] Python bindings for Paludis
Piotr Jaroszyński wrote: Hello, I have already submitted my application, but want to advertise it over here too :] Comments are welcome! Summary: Create Python bindings, associated documentation and test cases for the Paludis public API, and allow subclassing of Paludis classes using Python. Check my counterproposal. I know it is more broad but it also fits better Gentoo as whole. For the ones that aren't following gentoo-soc: - C/C++/Ruby/python bindings/API for package managers. The idea is to have some kind of common ground for applications willing to use our wonderful package managers. Task list: - define a basic API for basic query and basic commands - implement it for paludis/pkgcore/portage a non native language - implement a little front-end using it (that would act as a subset of emerge) - extend the API to cover more features. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote: Paludis is a tool used for working with the Gentoo Portage tree - there is no problem with it being part of a Gentoo Google Summer of Code project as it will benefit the Gentoo project and its users. Why not simply solve the situation by making paludis the mentoring organisation instead of Gentoo? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpPRc9PWndC4.pgp Description: PGP signature
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
On Sat, Mar 24, 2007 at 12:29:06AM +0200, Petteri Räty wrote: I got annoyed enough about emerge -pl not working when people don't use echangelog like: # $Header: /var/cvsroot/gentoo-x86/x11-libs/libXinerama/ChangeLog,v 1.27 2007/03/22 02:18:21 joshuabaergen Exp $ 22 Mar 2007; Joshua Baergen [EMAIL PROTECTED] +libXinerama-1.0.2.ebuild: Version bump. Includes new documentation and some small code tweaks. Because it's missing *libXinerama-1.0.2 (22 Mar 2007) emerge -pl does not work. This lead me to write the code to detect these cases: https://bugs.gentoo.org/show_bug.cgi?id=171962 You can find the results here: http://dev.gentoo.org/~betelgeuse/changelogs_with_bad_new_revision_entries.txt Most of these probably probably date back to time before echangelog but feel free to fix your packages any way :) It complains about the fpc changelog, for 2.0.0-r1, but it seems okay to me: [...] 17 Dec 2005; Carsten Lohrke [EMAIL PROTECTED] +fpc-2.0.0-r1.ebuild: restore ebuild for dev-lang/lazarus *fpc-2.0.2 (17 Dec 2005) 17 Dec 2005; Carsten Lohrke [EMAIL PROTECTED] -fpc-1.9.5_pre20040820.ebuild, -fpc-2.0.0_rc2.ebuild, -fpc-2.0.0.ebuild, -fpc-2.0.0-r1.ebuild, +fpc-2.0.2.ebuild: version bump 14 Oct 2005; Gustavo Zacarias [EMAIL PROTECTED] fpc-2.0.0-r1.ebuild: Added sparc support and keyworded accordingly 15 Sep 2005; Marcelo Goes [EMAIL PROTECTED] fpc-1.9.5_pre20040820.ebuild: Add app-arch/unzip to DEPEND for bug 69831. 24 Jul 2005; Herbie Hopkins [EMAIL PROTECTED] fpc-2.0.0-r1.ebuild: Added amd64 support thanks to Matthias Jansen. *fpc-2.0.0-r1 (03 Jul 2005) [...] Or should the *fpc-2.0.0-r1 line be repeated? Also, would it be possible to sort the packages in some way? pgphE8QDONytz.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:46:45PM +1100, Jonathan Adamczewski wrote: Paludis is a tool used for working with the Gentoo Portage tree - there is no problem with it being part of a Gentoo Google Summer of Code project as it will benefit the Gentoo project and its users. Why not simply solve the situation by making paludis the mentoring organisation instead of Gentoo? You assume that the paludis folks applied for mentoring org status and were accepted; which didn't happen. The Gentoo SoC team is aware of lingering issues regarding projects like pkgcore and paludis and whatnot. I'd prefer we rank applications (and applicants) based on the merits of their application as opposed to some arbitrary political system. If it happens that someone submits a very well thought out idea with defined goals, milestones, has a design plan and seems to have decent merit but happens to be say, a paludis related project; well I guess the other people should have submitted better proposals. In the end most of the ranking and chosing of projects is a huge judgement call by the SoC team and the mentors each year anyway. Personally I think python bindings for paludis push the boundaries of 'does this project affect gentoo' while say, the project idea for 'adding an ebuild development tool for paludis' does not push the boundaries. One is only tangentially related (paludis happens to be a tool that uses ebuilds) and the other could be more of a cross-project project, with 1 gentoo mentor and 1 paludis mentor. However my opinon (and most of this ensuing discussion) is probably better served for when applications are actually ranked. So in closing, we know, some of us don't care, we will disuss it during ranking. -Alec -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Package removals: libzvt+deps: gnomesu, xsu2, root-portal
# Stefan Schweizer [EMAIL PROTECTED] (24 Mar 2007) # as-needed broken, unmaintained, for removal, bug 147550 x11-libs/libzvt # use gksu now app-admin/gnomesu app-admin/xsu2 # use root-tail now x11-misc/root-portal -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:31:08AM -0700, Alec Warner wrote: [some stuff] Thanks for the explanation, i guess that makes sense. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp0iYPX1u5mI.pgp Description: PGP signature
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
Harald van Dijk kirjoitti:
*fpc-2.0.0-r1 (03 Jul 2005)
[...]
Or should the *fpc-2.0.0-r1 line be repeated?
Also, would it be possible to sort the packages in some way?
This is a case that the script does not currently detect. IMHO the *${P}
line should be there if it brings more info to users with emerge -pl
changelog. I will modify the script to also the rest of the line for the
entries beside to the start.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Everyone developer should downgrade back to gentoolkit-dev-0.2.6.2
Joshua Baergen kirjoitti: It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 produces proper changelogs. Josh Until the problem is solved everyone should downgrade back to 0.2.6.2. I package.masked 0.2.6.3 in the meanwhile. https://bugs.gentoo.org/show_bug.cgi?id=172017 Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
Harald van Dijk kirjoitti: It complains about the fpc changelog, for 2.0.0-r1, but it seems okay to me: Fixed the script to take package moves into account. Also, would it be possible to sort the packages in some way? The list is now sorted and I added a check for bad date entries in the new revision/version entries: http://dev.gentoo.org/~betelgeuse/changelogs_syntax_errors.txt Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We should not have third-party projects be part of SOC -- specifically, things that are not Gentoo projects. I'd lobby this whether it was pkgcore or paludis being proposed, so don't bother trying to pin partisan accusations. Point is, it's not a Gentoo project. PMS, portage tests, or doing a gentoo.org rewrite -- those are Gentoo projects by any reasonable standards, I should think. Not entirely true. The very reason Google selects Linux Distributions as mentoring organizations is because a lot of projects that benefit the entire FOSS community in general are mentored by them. Have a look at the project ideas for Debian or Fedora; they have several ideas that have nothing to do with the distro, but do benefit a broader audience. I see nothing wrong in mentoring projects that are not related to Gentoo in any way at all, leave alone projects like Paludis which have provide *direct* benefits for (some) Gentoo users. I completely agree with what Alec says, applications must be ranked purely on the basis of their technical merit, rather than evaluating how it helps a specific subset of projects. Cheers, - -- Anant -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGBRM9Ton3xA72kU4RAh5VAJ9/1DCzWqm5zMFyIPW6MccQEq1akQCgjOGk 0eiZGjA3Jw/ztUTuwTE/HQk= =Zr/4 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote: On Friday 23 March 2007, Josh Saddler wrote: I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. i'd have to agree here -mike Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. ~mcummings, the other mike -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpaXhlsVZ3GD.pgp Description: PGP signature
[gentoo-dev] Last rites for app-shells/ash
app-shells/ash is based on a very old netbsd sh and also uses an equally old Debian patch. ash currently has no maintainer. This package has since become dash upstream, which we do have in portage and is maintained by me. The irony is that ash requires /bin/sh as bash to compile as part of the Debian patch uses some bashisms - lol. As such, I will mask it at the end of next week, pending removal in 30 days. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 13:54:51 Michael Cummings wrote: Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. Anant really meant his mail: https://wiki.ubuntu.com/GoogleSoC2007 - Revision-controlled home directories - we have the same idea for /etc - Python Basics Training Program - Math System for Children - Educational Apps - Tool for computer aided vocabulary learning - Gnome Media Center - G-Playah ... Also Google FAQ is worth reading: http://code.google.com/support/bin/answer.py?answer=60291 Google seems to concern more about the FOSS community than the organizations' copyright in the header and imho that's a good thing. Gentoo is supposed to be a _mentoring_ organization, so the only question is whether Gentoo mentors are capable of mentoring a project or not. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Michael Cummings wrote: [Sat Mar 24 2007, 07:54:51AM CDT] On Sat, Mar 24, 2007 at 01:50:19AM -0400, Mike Frysinger wrote: On Friday 23 March 2007, Josh Saddler wrote: I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. i'd have to agree here -mike Ditto. Gentoo SoC projects need to be for Gentoo developed and sponsored code/projects, not third party projects, no matter how much they would whither and die without a gentoo core. There was an example of gentoo+gnome integration (i think) in a previous email - that wouldn't be any more appropriate. Unless there's the Gentoo Inc copyright in the header, it isn't eligible in my opinion. Okay, let me explain why I think all three of you have the wrong idea here, although I have sympathy for your argument. First, there's the issue that hosting projects that are only tangentially related to Gentoo drains our resources. To some extent that's true, but it's a minimal effect. What resources are we talking about? Infra provides cvs or svn for the SOC students, we have a gentoo-soc mailing list, and I suspect there will be a gentoo-soc planet again. Getting that set up requires significant effort, but the difference in effort between 5 students and 10 students is not very much. (One could imagine web-based projects that would also require Infra to provide various web-based or network-based apps, but those are likely to be for true Gentoo projects, so I'm discounting those for this discussion.) Gentoo also provides mentors, who choose to volunteer their time. If nobody wants to mentor a project, it's not going to be accepted. You could argue that by allowing these sorts of projects we are encouraging devs to spend time on non-Gentoo stuff. *Shrug* Our devs are volunteers, so I figure they're going to spend their time doing what they want to do anyway. (Incidentally, if that gnome+gentoo student chose to submit his or her proposal to Gnome, nothing would stop one of our devs from officially mentoring that person as long as the Gnome folks agreed (or unofficially mentoring if they didn't). Of course, for many my above argument is beside the point. It isn't the resources, it's the principle of the thing. SOC projects hosted by Gentoo should be Gentoo projects that clearly benefit Gentoo and have (c) Gentoo Foundation, Inc stamped on them. I have sympathy for that argument, but I respectfully disagree, because I think that argument misses the essential point of Google's Summer of Code program. The primary goal is to get students involved in developing open source code, and thus bringing new blood into the community. Even if our students don't become Gentoo developers, if they have a good experience they are likely to be friendly to open-source software, at least, and perhaps even long-term active contributors. My view is that we are providing an altruistic service here to benefit the community in which we reside, not to get free labor and a bit of cash (Google pays the hosting organizations as well as the students). (That said, we nonetheless did pick up some nice code and at least two devs from last year's program. Also, our being chosen to participate nicely enhances our reputation, both as being a significant player in open-source and as being one of the good guys in the community.) It's possible that I'm not being terribly convincing. After all, a student who submits a proposal to nmap is almost certainly going to be working on nmap, not, say, honeynets. Why should Gentoo be different? Well, for one thing, our main product is a distribution, and we spend most of our time integrating existing code instead of writing new code, so we're pretty much a natural umbrella organization anyway. Last year one of the proposals that was submitted to a number of distributions (including ours) involved porting Sun's ZFS to Linux. It was a very well-written proposal, and it was accepted by several different organizations. (I don't remember which organization he went with, but it wasn't Gentoo.) Clearly having ZFS support in Linux would benefit Gentoo in the long run, even if it wasn't an obvious Gentoo project, and I'd have been perfectly happy supporting it. (In case you're curious, you can follow along the progress of that proposal at http://zfs-on-fuse.blogspot.com/, and he just released the first beta at the beginning of this month.) Finally, let me be more specific about pkgcore- or paludis- or gnome+gentoo-related proposals. If not us as a mentoring org,
[gentoo-dev] logrotate use flag local - global
Any issues with this? It is used by the following packages: [+ C ] logrotate (app-antivirus/clamav): Install logrotate script for clamav logs [+ C ] logrotate (app-backup/bacula): Install support files for logrotate [+ C ] logrotate (mail-filter/dspam): Install support files for logrotate [+ C ] logrotate (mail-filter/spamassassin-fuzzyocr): Install support files for logrotate [+ C ] logrotate (net-ftp/vsftpd): Use logrotate for rotating logs [+ C ] logrotate (net-proxy/squid): Use logrotate for rotating logs [+ C ] logrotate (sys-apps/qingy): Enable logrotate file installation [+ C ] logrotate (sys-cluster/vzctl): Enable logrotate file installation [+ C ] logrotate (sys-power/acpid): Use logrotate for rotating logs [+ C ] logrotate (sys-power/hibernate-script): Use logrotate for rotating logs Regards, Michele Noberasco -- Nice guys finish last. -- Leo Durocher -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 08:09:09 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Check my counterproposal. I know it is more broad but it also fits better Gentoo as whole. For the ones that aren't following gentoo-soc: - C/C++/Ruby/python bindings/API for package managers. The idea is to have some kind of common ground for applications willing to use our wonderful package managers. Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] logrotate use flag local - global
On Sat, 24 Mar 2007 17:14:50 +0100 Michele Noberasco [EMAIL PROTECTED] wrote: Any issues with this? Yes. Check every previous time this has been discussed on this list. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ah, a couple additional things. Diego wrote me and commented that he's not a big fan of accepting proposals from existing devs, since the goal of the program is to get _new_ blood into open-source projects. I think that's a good point, and my personal preference is to accept strong proposals from new folks. That said, I'd rather we accept strong proposals from eligible existing devs than lousy proposals from the new folks, if that should turn out to be a choice we have to make. *Shrug* Also, it may not have been clear from my previous post that if we get inundated by strong, obviously-Gentoo-specific proposals, I suspect they'll push the less-Gentoo-specific proposals right off the acceptance list, unless those alternative proposals are amazingly impressive. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpLPhE6K4meX.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Saturday 24 of March 2007 17:30:55 Mike Doty wrote: Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. 1. pioto is a mentor this year... ;] 2. hardly technical issue 3. see ciaran's post -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Yes. pioto's proposal is weak. You mean Piotr, right? He's a different person from me. -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT] On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Weird, I haven't received Mike's e-mail yet, although I got ciaranm's reply. In any event, I agree that lu_zero's idea would be preferable, if it could be implemented. I'm agnostic on that point at the moment, though, since it's hard to evaluate from lu_zero's brief sketch. I'd love to see a true detailed proposal. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpslit9OK2hx.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Mike Kelly wrote: On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Yes. pioto's proposal is weak. You mean Piotr, right? He's a different person from me. I do. -- === Mike Doty kingtaco -at- gentoo.org Gentoo Council Gentoo Infrastructure Gentoo/AMD64 Strategic Lead GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05 === -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
I'm very strongly against using Gentoo SoC time and resources for things that are not officially part of Gentoo (yes, this statement could be spun however you wish) or are not official Gentoo projects. And no, just because a project has Gentoo developers in it doesn't mean that it's a Gentoo project -- let's avoid the gray areas now, shall we? Just because we have Gentoo devs who are also Gnome upstream doesn't make their Gnome-related packages that happen to be in our tree official Gentoo projects. In my opinion, any project that has reasonable potential to improve Gentoo as a whole *and* is strongly related to Gentoo should be considerable for SoC. While this is certainly not the case for say Improving gtk+, it definitely is for Pepers project. After all, what is PMS all about, if we keep on evaluating package managers solely on being official Gentoo projects or not? -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. Any reasons why this would be a bad idea? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn napsal(a): Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. Any reasons why this would be a bad idea? NOCHANGE sucks... If you really insist on doing anything, then use NOTABUG. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 18:34:21 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. _If_ it's changed then please to something else, NOCHANGE would overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious to me at least. A fake resolution that's mentioned on IRC from time to time is NOTABUG which would fit better here. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
Marius Mauch wrote: Kevin F. Quinn [EMAIL PROTECTED] wrote: Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. _If_ it's changed then please to something else, NOCHANGE would overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious to me at least. A fake resolution that's mentioned on IRC from time to time is NOTABUG which would fit better here. I like freedesktop.org's bugzilla, which has INVALID, NOTABUG and NOTOURBUG. ;) But yeah, NOTABUG is used by a few different projects and seems to work. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. But sometimes, just sometimes, the bugs are absolutely 100% invalid. Emerging nano broke my apache (random fake example with two unrelated packages)(or...are they...?) More important is to explain to the user *why* it is invalid, and leave it open to them to argue and reopen the bug. Better communication, not more convoluted closure flags, is the solution. IMHO. You know. Word. ~mcummings -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- Hi, I'm a .signature virus! Please copy me in your ~/.signature. pgpNuJuZowzge.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. I'd like to know your opinion about which are the pitfalls and the issues since you are surely more informed than me on paludis and, to a large degree, on portage internals. I assumed that for a foundation and a non exaustive converage the summer would be more than enough. I'm more interested in a solid base than a complete and exaustive wrapper =) lu PS: if the other project leaders would like to chip in I wouldn't be offended ^^ -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Josh Saddler wrote: We should not have third-party projects be part of SOC I see 3 important points missing from the discussion so far: (not directed at any response in particular) 1. We mentored projects like Piotr's last year, it seemed to work OK and as far as I'm aware there weren't any objections or conflicts of interest or anything like that. 2. Google are paying *GENTOO* $500 per project. Be sure to consider this when you state that mentoring projects like Piotr's would be taking resources away from Gentoo. 3. We should ask Google for their opinion on this. They are, after all, running the scheme, PAYING US MONEY, and are the people who decide whether we get to participate in future years. I have asked Alec to inquire about this. It seems that the mentors are already decided about the strategy here -- prefer projects undoubtedly in line with Gentoo development, but let proposal quality be the ultimate factor. My personal opinion is that we shouldn't be so hard on proposals like Piotr's. After all we are an open source community, the whole scheme is about promoting open source, so we should try and be open in our processes. In this particular case, it hasn't been decided that Paludis can't ever become the package manager of choice, and even while it isn't the official package manager right now, it is already helping significantly with areas like technical QA. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. I'd like to know your opinion about which are the pitfalls and the issues since you are surely more informed than me on paludis and, to a large degree, on portage internals. I assumed that for a foundation and a non exaustive converage the summer would be more than enough. I'm more interested in a solid base than a complete and exaustive wrapper =) lu PS: if the other project leaders would like to chip in I wouldn't be offended ^^ I'd imagine portage lacks many of the things that would be wrapped (multiple repos being probably the big killer). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. I'd like to have more details, please. Trivial functionality would be already fine for most of the front-ends IMHO. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Grant Goodyear wrote: Ciaran McCreesh wrote: [Sat Mar 24 2007, 11:38:45AM CDT] On Sat, 24 Mar 2007 09:30:55 -0700 Mike Doty [EMAIL PROTECTED] wrote: Grant Goodyear wrote: [snip] PS. So, anybody have any actual technical comments about this proposal? Yes. pioto's proposal is weak. lu_zero's counterproposal for developing a method of having a package manager agnostic API is much more useful than developing one language binding for one package manager. Weird, I haven't received Mike's e-mail yet, although I got ciaranm's reply. Me neither, but the mail is here: http://article.gmane.org/gmane.linux.gentoo.devel/47260 The bug: https://bugs.gentoo.org/141904 Regards, Robert signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Am Samstag, 24. März 2007 20:53 schrieb Luca Barbato: Ciaran McCreesh wrote: Which is all very nice in theory, but completely impractical and useless in practice. There's far too much difference and far too much complexity implementation-wise to make this practical for any non-trivial functionality. I'd like to have more details, please. Trivial functionality would be already fine for most of the front-ends IMHO. * Paludis supports multiple repositories, don't know about pkgcore, but i guess they support it as well. Portage doesn't. (actually it has 3 repositories, but that's not really related to multiple repository support) * Paludis handles ENVVARs on a per package basis, Portage doesn't. (no idea about how pkgcore does it) * Paludis repositories aren't necessarily ebuild repositories. This is what comes to my mind right now. The list is certainly not complete :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 19:14:38 +0100 Marius Mauch [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2007 18:34:21 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. _If_ it's changed then please to something else, NOCHANGE would overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious to me at least. A fake resolution that's mentioned on IRC from time to time is NOTABUG which would fit better here. Well, I meant for NOCHANGE to be no change needed, but figured NOCHANGEREQUIRED is a bit longwinded. It implies the issue is understood, it has been explained to the bug reporter, but requires no change to anything: CANTFIX: the problem exists, but no sensible way to fix it exists WONTFIX: the problem exists, but for some reason it won't be fixed WORKSFORME: can't replicate NOCHANGE: no change needed The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
Danny van Dyk wrote: * Paludis supports multiple repositories, don't know about pkgcore, but i guess they support it as well. Portage doesn't. (actually it has 3 repositories, but that's not really related to multiple repository support) and mixing overlays and repository doesn't look that good even if it could be a possible temporary solution ^^; * Paludis handles ENVVARs on a per package basis, Portage doesn't. (no idea about how pkgcore does it) Ok ^^ * Paludis repositories aren't necessarily ebuild repositories. I know =) This is what comes to my mind right now. The list is certainly not complete :-) Well I think there is a huge list of advanced features already implemented and working well in paludis, but, my interest is in getting a basic wrapper so people writing front-ends could just have some high level abstraction for now and then cover what's advanced later. The abstraction MUST be something better than having pcre parsing the output of the PM default front-ends, but not that much ^^; lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Sat, 24 Mar 2007 20:25:45 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Assuming you mean piotr, who is not pioto... The difference is, piotr's proposal is possible and doable within the timeframe, whereas lu_zero's sounds nice if you don't know anything about any of the package managers in question and can't be delivered within three months. I'd like to know your opinion about which are the pitfalls and the issues since you are surely more informed than me on paludis and, to a large degree, on portage internals. I assumed that for a foundation and a non exaustive converage the summer would be more than enough. If you're wanting to do a very simple API supporting approximately the following, you're ok: * Fetching a list of package versions that match a particular dependency atom * Fetching a list of available packages * Simple metadata queries upon a particular package * Fetching the contents of a particular package If you're wanting to make a powerful API that lets people solve real world problems, you're in for an awful lot of trouble. The problem is this... Although Paludis, Pkgcore and Portage solve the same ultimate problem, they do it in extremely different ways. Internally and from a public API perspective, there's very little in common between the three. Portage is by and large procedural and messy. It's basically an incoherent bunch of routines to do particular things. It doesn't generalise well, and things you'd expect to be similar aren't (e.g. you'd think finding out something about a package in VDB would be the same as finding out something about a package in the tree, but that would be far too easy...). Paludis is basically what you'd expect from a highly OO, resource managed language like C++. The problem is, a generalised API would end up hiding nearly all of the flexibility and functionality. You also can't wrap Paludis in any programming language that doesn't do resource management of some kind (preferably fully controlled, but since only C++ offers that, garbage collected works too). Writing a common middle layer in C and then writing language extensions on top of that isn't doable -- the common middle layer would have to be C++, since you can't write Ruby extensions in Python or suchlike... Pkgcore is closer to being AO than OO, largely because of programming language differences. Again, a generalised API would mask flexibility and functionality. You'd have a hard time getting callbacks to generalise cleanly. Design issues aside, there're also problems conceptually. The three package managers have very different ideas of certain key concepts like repositories, packages, the general operating environment (or domain) and version metadata. You'd have to come up with a whole new conceptual model that can handle all three paradigms, and you'd have to do it in such a way that you don't kill the performance techniques (delayed and batch loading, effectively) used by Paludis and Pkgcore. So it's down to a question of scope. Are you trying to make an API to do a few very basic queries, or are you trying to make an API powerful enough to, say, make a graphical front end? The former is doable and useless, the latter is a massive project. Now, what you *could* do is implement a portageq-style tool with more functionality. You'd still have conceptual issues (Paludis doesn't particularly like giving you global configuration information, for example -- simple things like querying whether a USE flag is enabled need an associated c/p-v::r), but they wouldn't be as bad. Such a tool would be slow, of limited use and easily doable within the available time. I'm more interested in a solid base than a complete and exaustive wrapper =) Which is the problem... The base is extremely different for all three. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
I think that there is a problem of concept. If a bug is marked INVALID, it's because it is not a real bug. Marking a bug NOCHANGE or NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails to better explain the reason why the bug was closed, whereas INVALID indeed means that the reported bug is simply not a bug or that it was reported to the wrong place. Even though it might look harsh to the user to get such a resolution, it's also harsh for the developers to have to handle bugs that are not related to them. Still, changing the name from INVALID to NOTABUG + NOTOURBUG does make sense, as the meaning doesn't get lost. Kevin F. Quinn wrote: On Sat, 24 Mar 2007 19:14:38 +0100 Marius Mauch [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2007 18:34:21 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. _If_ it's changed then please to something else, NOCHANGE would overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious to me at least. A fake resolution that's mentioned on IRC from time to time is NOTABUG which would fit better here. Well, I meant for NOCHANGE to be no change needed, but figured NOCHANGEREQUIRED is a bit longwinded. It implies the issue is understood, it has been explained to the bug reporter, but requires no change to anything: CANTFIX: the problem exists, but no sensible way to fix it exists WONTFIX: the problem exists, but for some reason it won't be fixed WORKSFORME: can't replicate NOCHANGE: no change needed The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 14:48:25 -0400 Michael Cummings [EMAIL PROTECTED] wrote: On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. But sometimes, just sometimes, the bugs are absolutely 100% invalid. Emerging nano broke my apache (random fake example with two unrelated packages)(or...are they...?) Well, if someone raises a bug, they have an issue. They may not understand it properly, and may frequently mis-diagnose it, but there's still an issue for them. To take your example, emerge nano broke my apache actually implies that apache isn't working properly for the reporter - just because they incorrectly assign blame to an emerge of nano doesn't mean everything is peachy. As the details are eked out of the reporter, the summary may become ssl support in apache broken with openssl-1.2.3.4, IYSWIM. We shouldn't be closing bugs as INVALID just because the original reporter mis-diagnosed the problem. There are cases where people raise a bug because they've mis-understood something and they don't realise it's behaving correctly - i.e. the behaviour they are complaining about is actually as-designed expected behaviour. But even then, the user had an issue - resolved by the explanation, even if the outcome is no change to anything. Closing it INVALID comes across too often as oh you're so stupid to raise this as a bug and there's no need for that to happen, imo. NOTABUG would do well enough in that sort of case I suppose, but there's still an overtone of you shouldn't have raised this to it. More important is to explain to the user *why* it is invalid, and leave it open to them to argue and reopen the bug. Better communication, Certainly good explanations as to why a bug is being closed are to be encouraged. My issue isn't with that - it's with the way that the marking INVALID is perceived, when there's no need to be so harsh. not more convoluted closure flags, is the solution. IMHO. You know. Word. The idea was to _replace_ INVALID with a less provocative name, not add more closure flags. I certainly agree that we don't need more closure flags. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn wrote: The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). Maybe, just maybe, the problem is not with the resolution name, but with peeps who cannot accept they could be wrong. For the most of us, INVALID doesn't mean YOUAREAMORON. A NOTOURBUG resolution would be pointless. I cannot imagine a possible scenario in which I could choose such resolution over the existing ones. Probably you want it as a replacement for UPSTREAM? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On 3/24/07, Daniel Drake [EMAIL PROTECTED] wrote: 3. We should ask Google for their opinion on this. They are, after all, running the scheme, PAYING US MONEY, and are the people who decide whether we get to participate in future years. I have asked Alec to inquire about this. This is by far the most pragmatic approach I've seen so far. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 22:07:08 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: Certainly good explanations as to why a bug is being closed are to be encouraged. My issue isn't with that - it's with the way that the marking INVALID is perceived, when there's no need to be so harsh. And NOCHANGE could be perceived as We're not going to change this anyway, so you're not really solving any problem by just changing a label. Some people will only ever be happy if they get the FIXED label on their reports. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 22:02:48 +0100 Ioannis Aslanidis [EMAIL PROTECTED] wrote: I think that there is a problem of concept. If a bug is marked INVALID, it's because it is not a real bug. Marking a bug NOCHANGE or NOCHANGEREQUIRED, not only overlaps with other resolutions, but fails to better explain the reason why the bug was closed, whereas INVALID indeed means that the reported bug is simply not a bug or that it was reported to the wrong place. I don't think it overlaps, as I described before (whether it does or not comes down to how you define it, of course). As to knowing why the bug was closed, personally I would rather the closure flag indicate the impact on the tree etc - i.e. whether something was changed (FIXED), could have changed but didn't (WONTFIX) or would have changed but couldn't be changed (CANTFIX) or in no way indicated a change (NOCHANGE). Bugs filed in the wrong place should just be re-assigned to the right place, not closed INVALID (at least, not at the point where it's still in the wrong place). Even though it might look harsh to the user to get such a resolution, it's also harsh for the developers to have to handle bugs that are not related to them. Still, changing the name from INVALID to NOTABUG + NOTOURBUG does make sense, as the meaning doesn't get lost. I don't think we need NOTOURBUG. Anything that's a real bug, but not a bug in what we do, can be marked UPSTREAM. Kevin F. Quinn wrote: On Sat, 24 Mar 2007 19:14:38 +0100 Marius Mauch [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2007 18:34:21 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. Arguably no bug is invalid in the normal sense - if someone raises an issue, they have an issue, regardless what we think of it. To that end I'd like to propose bugzilla be reconfigured to use the phrase NOCHANGE instead of INVALID. NOCHANGE would indicate that whatever the original issue, no change is needed on our part to resolve the issue. _If_ it's changed then please to something else, NOCHANGE would overlap with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious to me at least. A fake resolution that's mentioned on IRC from time to time is NOTABUG which would fit better here. Well, I meant for NOCHANGE to be no change needed, but figured NOCHANGEREQUIRED is a bit longwinded. It implies the issue is understood, it has been explained to the bug reporter, but requires no change to anything: CANTFIX: the problem exists, but no sensible way to fix it exists WONTFIX: the problem exists, but for some reason it won't be fixed WORKSFORME: can't replicate NOCHANGE: no change needed The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 23:17:52 +0200 Alin Năstac [EMAIL PROTECTED] wrote: Kevin F. Quinn wrote: The problem I have with NOTABUG is pretty much the same problem I have with INVALID - it's not as severe, but it still does the same thing to the user (i.e. slaps him with a wet fish rather than a frozen one). Maybe, just maybe, the problem is not with the resolution name, but with peeps who cannot accept they could be wrong. For the most of us, INVALID doesn't mean YOUAREAMORON. My point is that if someone raises a bug, they clearly have an issue - if they didn't, they wouldn't have raised a bug. Closing INVALID is like saying they never had an issue - when clearly they did have an issue, even if it was just an issue of understanding. A NOTOURBUG resolution would be pointless. I cannot imagine a possible scenario in which I could choose such resolution over the existing ones. Probably you want it as a replacement for UPSTREAM? Er, I never suggested NOTOURBUG - as you say we already have UPSTREAM. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sat, 24 Mar 2007 22:46:07 +0100 Marius Mauch [EMAIL PROTECTED] wrote: On Sat, 24 Mar 2007 22:07:08 +0100 Kevin F. Quinn [EMAIL PROTECTED] wrote: Certainly good explanations as to why a bug is being closed are to be encouraged. My issue isn't with that - it's with the way that the marking INVALID is perceived, when there's no need to be so harsh. And NOCHANGE could be perceived as We're not going to change this anyway, No, that would be WONTFIX (or CANTFIX). NOCHANGE implies there is nothing wrong with the existing code, so there's no question of whether we should change anything or not. so you're not really solving any problem by just changing a label. Some people will only ever be happy if they get the FIXED label on their reports. I'm not sure that's so. There are certainly many who don't like their reports marked INVALID, at least initially. I know I've seen many instances where the word INVALID has got peoples hackles up, yet after it's explained that it doesn't imply they shouldn't have raised the report in the first place, they're ok (I've explained to people before that the INVALID marking just indicates that there's no change required to the tree). This is the same issue I have with NOTABUG - it's like saying, you're wrong, shouldn't have raised the report, just perhaps not as in-your-face as INVALID. Still, it looks like I'm being out-gunned on this one, and I'm starting to repeat myself, so I'll be quiet for a bit... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn napsal(a): [snip] See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. Don't invent confusing 'politically correct' junk for this just because someone might feel 'offended'. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sun, 25 Mar 2007, Jakub Moc wrote: Kevin F. Quinn napsal(a): [snip] See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. In which case it must be a feature, so why not use the keyword FEATURE? Don't invent confusing 'politically correct' junk for this just because someone might feel 'offended'. I think that insufficient people in the open source and free software movements realize that in the real world there are differing cultures all of whom have differing sensitivities to language constructs. imnsho it's very important not to cause deliberate offense, because doing so perpetuates the idea that FOSS movement people are an unpleasant bunch of individuals. This causes users to make the choice of using computer products from elsewhere, and developers to spend their free time doing other things. -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
Ciaran McCreesh wrote: [a succinct enough, yet complete examination of the problems and the possible outcomes of my SoC idea] Thank you for pointing all the issue and give a good review of the 3 package managers. Now I think it's up to the students and front-end developers telling their wishes. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Christopher Sawtell napsal(a): See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. In which case it must be a feature, so why not use the keyword FEATURE? And why use it? Anything else than 'so that we are 'politically correct'? Sorry, this doesn't go anywhere. Don't invent confusing 'politically correct' junk for this just because someone might feel 'offended'. I think that insufficient people in the open source and free software movements realize that in the real world there are differing cultures all of whom have differing sensitivities to language constructs. imnsho it's very important not to cause deliberate offense, because doing so perpetuates the idea that FOSS movement people are an unpleasant bunch of individuals. This causes users to make the choice of using computer products from elsewhere, and developers to spend their free time doing other things. Oh, so resolving 'INVALID' a bug for people that report crap like 'oh, my sci-mathematics/*' thingy got horribly broken with -ffast-math' causes an offense to them? Well, that's a good thing, maybe they'll actually use their brain next time. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Sun, 25 Mar 2007 00:05:02 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Oh, so resolving 'INVALID' a bug for people that report crap like 'oh, my sci-mathematics/*' thingy got horribly broken with -ffast-math' causes an offense to them? Well, that's a good thing, maybe they'll actually use their brain next time. So you feel that idiocy should be punished? -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Ciaran McCreesh napsal(a): Jakub Moc [EMAIL PROTECTED] wrote: Oh, so resolving 'INVALID' a bug for people that report crap like 'oh, my sci-mathematics/*' thingy got horribly broken with -ffast-math' causes an offense to them? Well, that's a good thing, maybe they'll actually use their brain next time. So you feel that idiocy should be punished? It's already been punished as they've got their broken app; I just don't see why I should be forced to spend even more time on this. So, what's your question? If you ask whether INVALID is a valid resolution for bugs, then yeah, it absolutely is, and no, I don't see any need to change this. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Christopher Sawtell wrote: On Sun, 25 Mar 2007, Jakub Moc wrote: Kevin F. Quinn napsal(a): [snip] See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. In which case it must be a feature, so why not use the keyword FEATURE? Why would we need a keyword for that? We already have enhancement as a possible value of the severity field. imnsho it's very important not to cause deliberate offense, because doing so perpetuates the idea that FOSS movement people are an unpleasant bunch of individuals. This causes users to make the choice of using computer products from elsewhere, and developers to spend their free time doing other things. FOSS _is_ a bunch of individuals, each with their own agenda. Whether they're unpleasant or not, it is a subjective issue. One of the FOSS strengths is always telling the truth, which applied to invalid bugs translates as closing them with INVALID resolution. If the reporter takes it as a personal offense, it is by all means his problem, not ours. Someone once said (Linus maybe?) Linux is user-friendly, only chooses its friends more carefully. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn [EMAIL PROTECTED] wrote: Closing INVALID is like saying they never had an issue - when clearly they did have an issue, even if it was just an issue of understanding. If bugs.gentoo.org users think that it's like saying there's no issue, ISTM the problem is with their understanding of bugzilla. IMO a bugs.gentoo.org faq could help, with info about how to file a useful bug, what to do if your bug is marked invalid, etc. I'm not qualified to write such a thing (at least not a good one), so all I can do is toss the idea into the list. -- »Q« -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] ANN: PMS public release
The first public draft of PMS is open for comment. The PDF is at http://dev.gentoo.org/~spb/pms.pdf, and will be updated periodically as changes are made. Anonymous SVN access to the LaTeX source is available; I won't give the URL here since most won't need it and I'd rather not run the risk of overloading the server. Find someone on IRC if you need it, which will probably be only if you are producing patches or reviewing changes just checked in. Any feedback should be via Bugzilla, in the PMS/EAPI component of Gentoo Hosted Projects, or IRC in #gentoo-pms on freenode. Based in part on feelings expressed by others in the past, and in part on the impossibility of tracking issues based in mailing list traffic, discussion would probably be best kept off the gentoo-dev list. Issues should be in Bugzilla, one issue per bug; any issues raised elsewhere will most likely be directed there. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Everyone developer should downgrade back to gentoolkit-dev-0.2.6.2
On Saturday 24 March 2007, Petteri Räty wrote: Joshua Baergen kirjoitti: It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 produces proper changelogs. Until the problem is solved everyone should downgrade back to 0.2.6.2. I package.masked 0.2.6.3 in the meanwhile. isnt this what package mask is for ? and/or just put out a quick -r1 that reverts echangelog -mike pgpXqVGUDQpTK.pgp Description: PGP signature
[gentoo-dev] Proposed addition to the Social Contract
It looks like our social contract doesn't prohibit Gentoo from being dependent upon a single sponsor or corporation. In the interests of keeping Gentoo run by the developers rather than any outside party, how about the following addition to the Social Contract? headingWe will be run by the Development Community/ Gentoo will be run by the development community. We will never allow ourselves to be reliant upon a single sponsor or corporation. -- I remain, Sir, your most humble and obedient servant, Christel - conventionally stuck in the 1920s signature.asc Description: This is a digitally signed message part
[gentoo-dev] Bugzilla UI (was Re: Suggestion: INVALID - NOCHANGE in bugzilla)
Kevin F. Quinn wrote: so you're not really solving any problem by just changing a label. Some people will only ever be happy if they get the FIXED label on their reports. I'm not sure that's so. There are certainly many who don't like their reports marked INVALID, at least initially. I know I've seen many instances where the word INVALID has got peoples hackles up, yet after it's explained that it doesn't imply they shouldn't have raised the report in the first place, they're ok (I've explained to people before that the INVALID marking just indicates that there's no change required to the tree). This is the same issue I have with NOTABUG - it's like saying, you're wrong, shouldn't have raised the report, just perhaps not as in-your-face as INVALID. Still, it looks like I'm being out-gunned on this one, and I'm starting to repeat myself, so I'll be quiet for a bit... Well from experience of the forums, there are indeed users who have felt bruised by their experience of bugzilla. I'm not sure if changing this flag is the right solution. It's a bit of a leap in terms of user-friendliness to go from the forums where everyone is supportive (or gets pulled up unless it's OTW) to bugzilla where wranglers are trying to deal with a flood of bugs and don't have the time to be diplomatic. And the standard advice is to interact with bugzilla to contribute, so you get enthusiastic beginners making the leap, only to annoy the busiest devs. It doesn't make for a sensible learning curve imo, and leads to a lot of confusion. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
a semi on topic thought. could bugzilla be changed so that the default search includes bugs in all status. instead of just open bugs. I know sometimes I'll miss closed bugs because I'll forget to do an advanced search. -- Caleb Cushing
Re: [gentoo-dev] Proposed addition to the Social Contract
Darn, there go Piotocorp's plans of buyout... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)
On Sun, 25 Mar 2007 02:21:46 +0200 Alin Năstac [EMAIL PROTECTED] wrote: Christopher Sawtell wrote: In which case it must be a feature, so why not use the keyword FEATURE? Why would we need a keyword for that? We already have enhancement as a possible value of the severity field. I think he was making a joke there (along the lines of the saying, It's not a bug, it's a feature!). Sadly, this just goes to show how people need to be more careful in their wording in a community like ours with people coming from so many different cultures. Or maybe people need to lighten up a bit more, I don't really know which. Anyone have any further suggestions how we as a community can avoid this sorta confusion from in-jokes, idioms, etc? It seems to be happening very often now-a-days (or maybe I'm just paying more attention than I used to). -- Mike Kelly -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
On Saturday 24 March 2007, Caleb Cushing wrote: could bugzilla be changed so that the default search includes bugs in all status. instead of just open bugs. I know sometimes I'll miss closed bugs because I'll forget to do an advanced search. there is an open regression bug about this -mike pgpGuMbjChBW1.pgp Description: PGP signature
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)
On Saturday 24 March 2007, Mike Kelly wrote: Or maybe people need to lighten up a bit more there it is -mike pgpfSL9nLJFvd.pgp Description: PGP signature
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)
On Sun, 25 Mar 2007, Mike Kelly wrote: On Sun, 25 Mar 2007 02:21:46 +0200 Alin NÄstac [EMAIL PROTECTED] wrote: Christopher Sawtell wrote: In which case it must be a feature, so why not use the keyword FEATURE? Why would we need a keyword for that? We already have enhancement as a possible value of the severity field. I think he was making a joke there (along the lines of the saying, It's not a bug, it's a feature!). He was, but at the same time he was testing the water ( more idiom ) to see what would happen. He would also like to point out that Many a true word is spoken in jest is a true proverb. He thinks, and hopes, that it applies in this context, and would still like to see INVALID replaced by FEATURE. Is going to make a fuss about it? No, he is not. It's not that important. Sadly, this just goes to show how people need to be more careful in their wording in a community like ours with people coming from so many different cultures. Or maybe people need to lighten up a bit more, I don't really know which. A bit of both I suspect. Anyone have any further suggestions how we as a community can avoid this sorta confusion from in-jokes, idioms, etc? All of us who are native English speakers need to remember that folks who learnt English at school often just don't 'get it' when it comes to English jokes. Similarly what passes for a harmless joke, or phrase, in one English speaking society can be really offensive in another. Also one of the intrinsic cultures of people who live to the East of a hazy line drawn more or less along the Rhine and Danube rivers is that when they are talking to each other on a day-to-day basis they are very honest and frank with each other. Those of us who are used to layers of nuance find the direct transliteration of very clear phrases difficult to understand emotionally. It seems to be happening very often now-a-days (or maybe I'm just paying more attention than I used to). I suspect both. -- CS -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cultural Differences (was: Suggestion: INVALID - NOCHANGE in bugzilla)
Sadly, this just goes to show how people need to be more careful in their wording in a community like ours with people coming from so many different cultures. Or maybe people need to lighten up a bit more, I don't really know which. Anyone have any further suggestions how we as a community can avoid this sorta confusion from in-jokes, idioms, etc? It seems to be happening very often now-a-days (or maybe I'm just paying more attention than I used to). Well I'm a native speaker so I guess I'm biased in this regard ;) I generally recommend a few thing assumptions: A. People really aren't out to get you. As much flaming as you see between certain individuals on this list (and in other venues) most people really just want to talk about ideas and get work done. They aren't out to make fun of you or insult you (or your mother, etc..) B. People misunderstand stuff all the time (myself included). Particularly when talking to non-native speakers of English I find that I don't always understand or interpret things correctly. This is why you will see me asking more detailed questions about certain aspects of the argument. A and B come from a general view that people are going to aim to do good instead of bad. If there is a situation where I am feeling insulted I usually assume I've misunderstood the situation rather than take offense. Some individuals also take ownership of their ideas and get really defensive about them (even when their ideas really do suck ass). This is something you should avoid; in most healthy environments even good ideas will get criticised. Nothing in this world is as black and white such that everyone will instantly agree with you or have no objections. Be prepared to defense and back up your ideas (preferably with good arguments and numbers etc..) -Alec -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Everyone developer should downgrade back to gentoolkit-dev-0.2.6.2
On Sat, 2007-03-24 at 21:56 -0400, Mike Frysinger wrote: On Saturday 24 March 2007, Petteri Räty wrote: Joshua Baergen kirjoitti: It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 produces proper changelogs. Until the problem is solved everyone should downgrade back to 0.2.6.2. I package.masked 0.2.6.3 in the meanwhile. isnt this what package mask is for ? and/or just put out a quick -r1 that reverts echangelog Both have occurred. The bad version has been package masked and removed from the tree. Additionally, the newer version reverts to the same echangelog from 0.2.6.2 Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [SoC] Idea for emerge
and I'd assume users might get rather confused to answer questions that are then thrown away later. I don't unterstand what do you mean by that... Another (relatively minor) problem is that the flags set in such a session would have to be made persistent somehow, and I wouldn't want emerge to mess with /etc/portage/package.* files Why ? it's just doing something the user will normally do As for listing USE flag descriptions, there are already patches floating around for that (at least TGL wrote one a while ago), and even if not it would be hardly worth a complete SoC project by itself. My idea was to integrate this with emerge, and this seemed something not very easy. But I totally agree that it's very easy (too for the SoC) to make an external tool to do that. So, since you think that emerge is not a place for that, I'll search for a new idea for the SoC and try to make this simple tool next week ;) Regards -- gentoo-portage-dev@gentoo.org mailing list
