Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
@council: We need to discuss ways to improve the current policy. See below. On 06/07/11 23:09, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. It was not only that, and the situation escalated as people tried to lawyer around instead of doing something productive like writing a perl script to wrap the nonsense so they can ignore it. Result was an unambiguous policy so that no lawyering happens and all ChangeLogs make sense. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. So you say that you want to follow the rules but accidentally forgot it? Since it has caused so much trouble I'd like to see it discussed and improved by the council. I disagreed with the initial strict wording, and I think the fallout has shown that we need to find a common ground so that no one feels he has to ignore the rules. if you want useless information, then automate it. there's no reason at all to not do so. i prefer to keep useful information in the changelogs of packages i maintain without cluttering up with noise. -mike Here's the problem. Useful depends a lot on the context. Sometimes I only care about a new addition. Sometimes I care about when and how a patch was introduced. Sometimes I care about removals because some monkey has broken things for me. In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. Cheers, Dirkjan
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, 8 Jun 2011 11:28:47 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. What if we wanted to remove ChangeLogs then for autogeneration? Will we require all devs to quickly update their portage versions? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/08/11 11:43, Michał Górny wrote: On Wed, 8 Jun 2011 11:28:47 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. What if we wanted to remove ChangeLogs then for autogeneration? Will we require all devs to quickly update their portage versions? Just make committing the ChangeLog fatal on the server side ;) There are enough ways to get it done ... -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/08/2011 12:28 PM, Dirkjan Ochtman wrote: On Wed, Jun 8, 2011 at 11:27, Patrick Lauer patr...@gentoo.org wrote: In all cases I want one resource to look at, viewcvs is a horrible and slow interface. So it does make sense to keep changelogs filled with information - maybe automation is needed, I don't have a strong opinion either way. But don't make me do more work because you are lazy, that never ends well. IMO we should just make repoman commit update the ChangeLog. Then repoman commit should have a flag to leave out removals from ChangeLog entries so unlazy people can still leave the cruft out from them. Ref. http://bugs.gentoo.org/show_bug.cgi?id=365373
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 11:45, Samuli Suominen ssuomi...@gentoo.org wrote: IMO we should just make repoman commit update the ChangeLog. Then repoman commit should have a flag to leave out removals from ChangeLog entries so unlazy people can still leave the cruft out from them. Ref. http://bugs.gentoo.org/show_bug.cgi?id=365373 I disagree; I think having the information about removed packages is useful. Cheers, Dirkjan
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Dale posted on Tue, 07 Jun 2011 22:45:34 -0500 as excerpted: Mike Frysinger wrote: On Tuesday, June 07, 2011 19:41:20 Dale wrote: I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike Let me see if I understand this correctly. Most devs and some users wants things put in the changelog. I don't know if it was you before but in the past someone didn't want to put when versions are removed. That person, whoever it was, said they were not going to do it because it was silly or whatever. This was taken to the council and it was decided that all changes had to be put in the changelog. Now in this thread, about the same thing from my understanding. You said waste of time and the policy is not sane. So, council says it has to be done. You say you won't. Tell me where I missed the point here. Mike's actually correct. He didn't say he was going to defy council, rather, that he simply wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto- generated (making the case moot) or the council changes policy. That means they'll either fall to someone else to do, or will simply remain there, but either way, it's quite different from directly defying the council decision. Gentoo devs are volunteers in any case, and as such, the system, to the degree that it works at all, does so because volunteers are (within reason) allowed to have their foibles and the system ultimately works around them. Because everyone has their foibles and if the system couldn't work around them, the system would quickly cease to be! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 7:17 AM, Duncan 1i5t5.dun...@cox.net wrote: He didn't say he was going to defy council, rather, that he simply wouldn't be removing ebuilds /at/ /all/ until either the changelog is auto- generated (making the case moot) or the council changes policy. That means they'll either fall to someone else to do, or will simply remain there, but either way, it's quite different from directly defying the council decision. As long as all versions in the tree compile cleanly and are free from security issues, I don't see any issue with keeping older ebuilds around. If anything I think that some packages are too quick to remove ~arch versions. I run stable but accept the odd ~arch package. When I do accept a ~arch package I only accept one version of it with the goal of going stable once whatever drove me to accept ~arch gets there. When the ~arch package disappears I just have to re-evaluate my new options and try again, and sometimes it feels like I never end up in stable. (I do realize that a few types of packages will probably never be stable by their nature, and that is fine.) If old versions become QA issues then we already have processes to deal with that. It is the duty of maintainers to deal with such problems. In any case, the rule is simple - if you remove an ebuild you have to include a note in the Changelog. That could change, or it might not, or perhaps it will become automated, but either way it is the rule right now. One thing I will say is that I appreciate the civility in this thread so far. I think everybody on both sides of the issue realizes that this is contentious, and I think everybody would be open to a better solution. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 23:44:49 Michał Górny wrote: On Tue, 7 Jun 2011 17:45:03 -0400 Mike Frysinger wrote: On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? the tree has already been migrated. automatic ChangeLog generation is trivial to implement, and many many projects already have scripts to do it. Including portage's egencache which can generate ChangeLogs from git. Just a side note. very cool ... wasnt aware of that guy, thanks -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 05:27:27 Patrick Lauer wrote: So you say that you want to follow the rules but accidentally forgot it? no idea what you're talking about. the new policy has 0 relevance to actions performed before said policy went into effect. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wed, Jun 8, 2011 at 1:06 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 08, 2011 05:27:27 Patrick Lauer wrote: So you say that you want to follow the rules but accidentally forgot it? no idea what you're talking about. the new policy has 0 relevance to actions performed before said policy went into effect. -mike Right, to be perfectly clear, the initial email in this thread was from halcy0n (May 16), and it was about something that happened before the new policy. Mike's first reply in this thread was after the new policy and was 3 weeks later on Jun 7. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 13:40:49 Matt Turner wrote: and was 3 weeks later on Jun 7. i havent had much time for Gentoo lately :/. but maybe people think that's good so i'll stop being a hassle. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. -mike So, you are saying that you won't be doing anything that will require you to add entries to the changelog. That works. It doesn't do much for the packages you maintain but that doesn't break the rules either. Let's just hope in the meantime things stay stable. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Wednesday, June 08, 2011 13:04:08 Mike Frysinger wrote: On Tuesday, June 07, 2011 23:45:34 Dale wrote: So, council says it has to be done. You say you won't. Tell me where I missed the point here. you missed the point as soon as you incorrectly stated that i said i wont. thus the rest of your e-mail is useless noise. sorry, this was probably overly dismissive. let's rephrase to something like the long e-mails were redundant/rhetorical and incorrectly attempted to apply to me. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. It'd also be better to do this all as one commit and run repoman with each commit. seems you left out imo in this statement. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 15:53, Mike Frysinger wrote: On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. snip -mike Mike, To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. You and I both know that a removal can (and sometimes does) cause breakage. These kinds of changes are things that your fellow devs (as well as many users) would like to see in ChangeLogs. I do *not* think that this is an unreasonable request. I find it to be a little.. inconsiderate I guess, when any developer fails to heed a reasonable request from another developer or user. I know I personally try to accommodate people if they ask me to do something slightly differently to make their lives easier. Why is it that you can't do that? Is running echangelog (or hell, scripting something) for a removal really that hard or undesirable? Can you really not spare the extra 10 seconds? I mean, come on. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN7o5hAAoJEEsurZwMLhUx2RcP/ip1lKohjB46iWA/T0Mb2eoa Vro488IDBMSOXy6L+JvKW4vh2EOfJl8g5PGgJuJhM9OmiLgYxmOgBCPpbCtu21hj FlJc5jKc3qN+0So1ka0Tez/toccA5d0lxPpZWitxDnEtMzQ6M46eEUv00EZN8yle o/UP94Inlp4miYXTGeyw2HKL8GP5su53/gYFidWQyzewEBYlvIFaIvyTPmJmbT5b ztgdlEr/xWS12OcUM8PymoOIw86dc8VcGPlPP5PaAx97T8o8OTG3q8lzx6naqYGN IyWFCNCrJJXSjQptIDALm3TU3qGe4/2pDbo7JuRCA8fG/i6+bKDEhJuKwBCnvIp/ YJR/PL6IlOInsBrTdew78MG2MqRnsOebBZ5a7rRDMfqSLrB4GHLisuyE8oHlyU8W A6ABRIi9yZIQrQG9TMcywNjTT8ejse9gL+Xrm03Aveb37FdrbQV5Nu+a5/wkaYOU 3e/3X9eRTFK7FdaWsAjXzGyS/8b7WtKioCEFTo4giP5R6lucLpVqqMYkuhAxAzMX y1u+57aZVUfZTBVksfQyQApVU/j+4UgUdMUBWuoX7F4i19almlm7U5egWh7wmBNi oKsUz6OcsvZ00x5Hr8xTrFEWaxE5CGyThjX0npblPLni9ZyppJyEz9P2YZ9OscGH FL1nIoSPHBeBznWaKnzO =z3hd -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. You and I both know that a removal can (and sometimes does) cause breakage. These kinds of changes are things that your fellow devs (as well as many users) would like to see in ChangeLogs. I do *not* think that this is an unreasonable request. I find it to be a little.. inconsiderate I guess, when any developer fails to heed a reasonable request from another developer or user. I know I personally try to accommodate people if they ask me to do something slightly differently to make their lives easier. Why is it that you can't do that? Is running echangelog (or hell, scripting something) for a removal really that hard or undesirable? Can you really not spare the extra 10 seconds? I mean, come on. if you want useless information, then automate it. there's no reason at all to not do so. i prefer to keep useful information in the changelogs of packages i maintain without cluttering up with noise. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/07/11 15:53, Mike Frysinger wrote: (...) waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. For the record, I support Dane's statement 100%. In addition, I would like to say that you're behaving pretty much childish and obstructive. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On 06/07/2011 10:53 PM, Mike Frysinger wrote: On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. +1, see: http://bugs.gentoo.org/show_bug.cgi?id=368097#c75 and I have to say it's all on councils shoulders how bad of an impact this will have on the tree with several devs leaving old files around or leaving trivial fixes uncommitted to workaround bad policy.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:14:05 Andreas K. Huettel wrote: On 06/07/11 15:53, Mike Frysinger wrote: waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. For the record, I support Dane's statement 100%. In addition, I would like to say that you're behaving pretty much childish and obstructive. in no way whatsoever am i obstructing anyone. look up the word and try again. as for childish, that's your opinion of course and everyone has one. here's another: forcing useless information which can be automatically dumped is a waste of developer time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/11 17:09, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. There never would have been any such policy had people been a little considerate of the requests of others. This could have ended like so: Dev y: Hey dev x, can you please ChangeLog removals please. I find it very useful. Dev x: Sure. I don't see use in the information, but if it's going to make your job easier, I'll try to remember to do it. Dev y: Thanks! Then this never would have even gotten to council, council never would have passed the current policy, and we never would have gotten to the bloody crapfest that it is now. I personally want people to heed my requests. The only way that will work is if I try to heed others. The only way to work in a community is a little give and take. You and I both know that a removal can (and sometimes does) cause breakage. These kinds of changes are things that your fellow devs (as well as many users) would like to see in ChangeLogs. I do *not* think that this is an unreasonable request. I find it to be a little.. inconsiderate I guess, when any developer fails to heed a reasonable request from another developer or user. I know I personally try to accommodate people if they ask me to do something slightly differently to make their lives easier. Why is it that you can't do that? Is running echangelog (or hell, scripting something) for a removal really that hard or undesirable? Can you really not spare the extra 10 seconds? I mean, come on. if you want useless information, then automate it. there's no reason at all to not do so. i prefer to keep useful information in the changelogs of packages i maintain without cluttering up with noise. Just because you deem it useless doesn't make it so. If someone else sees use in the information, I fail to see why it is such a huge deal to log it. Even if for no other reason than to make someone else's life a bit easier. And yes, it should be automated. I agree. Doesn't change the current situation. Regards, - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN7pbLAAoJEEsurZwMLhUxPTkP/AtB5skbFy9GOOpw1kKEu+jI 8z60RD/usXB+TAuHJGKqEDGg8mHzaY7xHMp8PaIoGSzUMGLFHYvnpfkiG1iMzGzF r/F6uLpxpDS35vDHJs5TWMZpiefK8D2SGF/mup68a75R3f7c7+FV2iFUSsJgqq5M iNJGHjzmnGG7utFIO4yRafuSFD1+dn3cZvWjUA6pRvZrMpY+hDRJ9ntuOeqn8CX9 Uw75PXWGEk8ebtR1hewR6sLQWJR1SVucexICCfOHEmLygpM3WJ9mPGxiiOT0iXRD Z7zO5bajoun6lv+xbAW5G4ITpk0s4eqXUQQ9Y1sWMmctXXkbmRn0MeGzK5EEhEen v+L7dRs7ZXjrD+rY+eni87rGNyS/GnUlq6Kx9cuJQJ/OrTB93wu1metnOlOIUH5N oEfvQq3gfsIshxGLmrkuwPZT6FkMxVCmEpyawMc2teSrZXrkHxWRVsW4W8u5+WQp fxp0HcLc4yS8BPTTgrAlT5UI/Tm3qPf+7UhgvH9Sx8AkmMgVD3sUOl38i4wiLvCu VsjRbCQ7tjrjM5VemaBOJzubcg0pbnHd9mhNK/2I1BDQjStb7EeXxiRvxJh61L6C u52mLmgHCvIcxkJkfdmDyl4We1BhvRp8u6lqIDjuxjgm5ge+JA2YtvYyOAYz4Ay4 zwPb45qd/GK9/dGAgtEf =7Ajj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:09 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 06/07/2011 10:53 PM, Mike Frysinger wrote: On Monday, May 16, 2011 09:41:08 Mark Loeser wrote: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. waste of time. i simply wont bother removing old versions until changelogs start being autogenerated or the policy is sane again. +1, see: http://bugs.gentoo.org/show_bug.cgi?id=368097#c75 and I have to say it's all on councils shoulders how bad of an impact this will have on the tree with several devs leaving old files around or leaving trivial fixes uncommitted to workaround bad policy. To avoid cluttering that bug report more, I'll respond here. It seems like the obvious answer is yes. The devrel resolution simply says that you can have commit access back after promising to follow the policy, and I can't see any way you wouldn't be following the policy by not making commits where you'd have otherwise left the changelog untouched. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. Plenty of people have, successfully I though, argued that removal Changelog entries _are_ useful and have cited relevant situations. Make a case about how the current policy is stupid in that it requires changelog entries for trivial whitespace changes or for documenting removals of packages even when it means the changelog is deleted as well, but for god sake, stop the nonsense about documenting version removals being useless. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:23:23 Dane Smith wrote: On 06/07/11 17:09, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. There never would have been any such policy had people been a little considerate of the requests of others. This could have ended like so: sorry, but that's utter bs. there is a disconnect between what you find valuable and what i find valuable. all you're doing is assuming your position is right and mine is wrong and thus i'm in the wrong and thus any disagreement that causes strife after that is my fault. if common ground between developers cannot be attained, then it is the council's job to step in and make a decision. And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger vap...@gentoo.org wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 2:36 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger vap...@gentoo.org wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? Automated changelog entries do not require git. -A -- Ciaran McCreesh
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? the tree has already been migrated. automatic ChangeLog generation is trivial to implement, and many many projects already have scripts to do it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 17:32:03 Matt Turner wrote: On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. Plenty of people have, successfully I though, argued that removal Changelog entries _are_ useful and have cited relevant situations. Make a case about how the current policy is stupid in that it requires changelog entries for trivial whitespace changes or for documenting removals of packages even when it means the changelog is deleted as well, but for god sake, stop the nonsense about documenting version removals being useless. that wasnt my point, although it is a good one. the idea that policy exists because i disagree with others is bunk. whether it be people complaining to other devs to do XYZ or the council makes it official XYZ, there is still a policy XYZ. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, Jun 7, 2011 at 5:47 PM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, June 07, 2011 17:32:03 Matt Turner wrote: On Tue, Jun 7, 2011 at 5:09 PM, Mike Frysinger wrote: On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote: To be perfectly blunt, no small part of what caused this current fiasco was this exact attitude. I don't like the current policy either, it's far too wide. However, if you go back and look at why it even *got* to council, it was because you (and others), decided that they weren't going to give any regard to the requests of some of their fellow devs about ChangeLogging removals. how is this relevant at all ? i dont find value in these entries, other people do. my attitude towards how worthless they are has 0 bearing on the policy towards creating it. Plenty of people have, successfully I though, argued that removal Changelog entries _are_ useful and have cited relevant situations. Make a case about how the current policy is stupid in that it requires changelog entries for trivial whitespace changes or for documenting removals of packages even when it means the changelog is deleted as well, but for god sake, stop the nonsense about documenting version removals being useless. that wasnt my point, although it is a good one. the idea that policy exists because i disagree with others is bunk. whether it be people complaining to other devs to do XYZ or the council makes it official XYZ, there is still a policy XYZ. -mike There _was_ a policy before, but it was unclear about documenting version removals and arguably didn't require it, so after a few developers (you've been often mentioned as one of them) refused to document version removals in the changelog, even after prompting on gentoo-dev@ the council fixed the policy. Of course the policy doesn't exist simply because you disagree with others, the policy exists (and was instituted/clarified) because you wouldn't do something that most developers and users find useful and thought was already policy, even after being asked. Why does this have to be such a struggle. It's pretty clear that the policy is going to be changed again to fix the oversight of silly situations like I mentioned previously, but there's a near unanimous agreement that documenting version removals _is_ useful. So, please, just start doing it. It's really not a lot of work. I'm sure something more can be done to make this more automated, but until then please just fucking do it and let's stop all this silliness. Matt
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 18:08:17 Matt Turner wrote: There _was_ a policy before, but it was unclear about documenting version removals and arguably didn't require it, so after a few developers (you've been often mentioned as one of them) refused to document version removals in the changelog, even after prompting on gentoo-dev@ the council fixed the policy. i'm aware of the history. it still doesnt validate the logic cited earlier. Of course the policy doesn't exist simply because you disagree with others, the policy exists (and was instituted/clarified) because you wouldn't do something that most developers and users find useful and thought was already policy, even after being asked. Why does this have to be such a struggle. It's pretty clear that the policy is going to be changed again to fix the oversight of silly situations like I mentioned previously, but there's a near unanimous agreement that documenting version removals _is_ useful. So, please, just start doing it. It's really not a lot of work. I'm sure something more can be done to make this more automated, but until then please just fucking do it and let's stop all this silliness. seems we gauge things differently as i dont think it's that black white, although it probably is further in your white than in my black. further, i dont believe people actually get useful information out of this, they just think they do (perception vs reality). when an actual bug arises, the information contained in the ChangeLog doesnt assist in the bug triage/fixing. depgraph broken - file removed - reason is irrelevant to the user. maintainer of the package causing the depgraph breakage gets a bug in bugzilla and they address it by either re-adding, or trimming more, or tweaking deps, or something else. so if someone wants a fuzzy security blanket, they can look to autogeneration and then it's no longer my problem. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: seems we gauge things differently as i dont think it's that black white, although it probably is further in your white than in my black. further, i dont believe people actually get useful information out of this, they just think they do (perception vs reality). when an actual bug arises, the information contained in the ChangeLog doesnt assist in the bug triage/fixing. depgraph broken - file removed - reason is irrelevant to the user. maintainer of the package causing the depgraph breakage gets a bug in bugzilla and they address it by either re-adding, or trimming more, or tweaking deps, or something else. so if someone wants a fuzzy security blanket, they can look to autogeneration and then it's no longer my problem. -mike Mike and others as it applies, I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. What would you think if someone else ignores another rule that affects you, negatively of course? What would you do? What do you think should be done to the person ignoring the rule? Should that person be allowed to do so with no consequences at all? Just everyone do as they wish regardless of the rules. What affect would that have on Gentoo as a whole? Do you really want to see this happen after all the mess Gentoo has been through in the past? Think on that for a bit. Give it a day or so or better yet, sleep on it. Again, I don't care for you to answer or reply. Just think. Dale :-) :-)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tuesday, June 07, 2011 19:41:20 Dale wrote: I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Tue, 7 Jun 2011 17:45:03 -0400 Mike Frysinger vap...@gentoo.org wrote: On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote: On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote: And yes, it should be automated. I agree. Doesn't change the current situation. of course it does. it makes the current situation irrelevant. Does this mean we should shortly be expecting to see you do the work to migrate the tree to Git and to automate ChangeLog generation? the tree has already been migrated. automatic ChangeLog generation is trivial to implement, and many many projects already have scripts to do it. Including portage's egencache which can generate ChangeLogs from git. Just a side note. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger wrote: On Tuesday, June 07, 2011 19:41:20 Dale wrote: I have a question or two. I don't care if you, or others, reply to this with a answer, just think on it. A policy, rule if you will, has been decided on by the council. This after MUCH discussion on this list and the council hearing both sides of the argument. You, apparently on your own or with a few others, have decided to ignore the policy or rule. umm, no, ive done no such thing. try again. -mike Let me see if I understand this correctly. Most devs and some users wants things put in the changelog. I don't know if it was you before but in the past someone didn't want to put when versions are removed. That person, whoever it was, said they were not going to do it because it was silly or whatever. This was taken to the council and it was decided that all changes had to be put in the changelog. Now in this thread, about the same thing from my understanding. You said waste of time and the policy is not sane. So, council says it has to be done. You say you won't. Tell me where I missed the point here. Thanks for the reply but I think this is going to be headed back up the food chain again. It appears that either rules mean nothing or they have to be enforced on everyone. The rule makers need to decide this. I suspect the reason this thread has gotten quiet is because it has already been discussed off this list about what is coming next. Just me reading tea leaves here. My advice, follow the rules or get the rules changed. Don't break them tho. It doesn't matter to me if you take that advice or not. Just saying. Dale :-) :-)
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/ It'd also be better to do this all as one commit and run repoman with each commit. Thanks, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Mon, May 16, 2011 at 07:41, Mark Loeser halc...@gentoo.org wrote: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. It would also seem manifests weren't regenerated. Don't have the time to go look if they were all touched by the same individual, but since Friday afternoon bzip2, cabextract, rsyslog, rubygems, and ca-certificates all come up with files missing from the manifest.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 16.05.2011 15:41, Mark Loeser pisze: Mike Frysinger (vapier) vap...@gentoo.org said: vapier 11/05/16 03:30:02 Removed: bzip2-1.0.5-r1.ebuild Log: old Please document removal of ebuilds in ChangeLogs. http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/ It'd also be better to do this all as one commit and run repoman with each commit. Thanks, I don't understand the purpose of such mails (it's 2nd within the period of few days). Council have already voted that those changes should be added to changelog so there's nothing technical to discuss. As for the conflict resolution the policy states: 1) try to resolve the issue among yourselves 2) consult with the project lead (QA?) 3) if all fails go to devrel Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. Cheers, Kacper -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk3RZMwACgkQIiMqcbOVdxRGuAP+JHinAeoeYqSxAqfjqcP5Q922 Jr8E4IPPpazlVUeWrtg2uHOIShkHQI8l5djiJ7mnsVGkRooPibX4ndX9rHLkwErH XahKTnHiUPSl1qoMr6f5fyqjQQ7O6dvpVXpT9O6g1/lyRmbnTB2dj6ts5trO88XL n7ehyPhupEewFjGAjbU= =Lvvm -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
El 16/05/11 19:54, Kacper Kowalik escribió: Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. To some of us (i.e. me as a staffer and probably any wanna be developer following the list) it is a good way to learn from others' mistake before applying for full developership. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Mon, May 16, 2011 at 08:19:45PM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: El 16/05/11 19:54, Kacper Kowalik escribió: Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. To some of us (i.e. me as a staffer and probably any wanna be developer following the list) it is a good way to learn from others' mistake before applying for full developership. This may be a bit of surprise to you but this is not an educational list. If you people disagree with these kind of commits feel free to open a bug to QA/Devrel like the policy suggests. But pretty please try to break this non-sense loop of this and similar threads. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpsIMiTwmTMP.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Mon, May 16, 2011 at 11:24 AM, Markos Chandras hwoar...@gentoo.org wrote: On Mon, May 16, 2011 at 08:19:45PM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: El 16/05/11 19:54, Kacper Kowalik escribió: Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. To some of us (i.e. me as a staffer and probably any wanna be developer following the list) it is a good way to learn from others' mistake before applying for full developership. This may be a bit of surprise to you but this is not an educational list. If you people disagree with these kind of commits feel free to open a bug to QA/Devrel like the policy suggests. But pretty please try to break this non-sense loop of this and similar threads. I actually value times when this stuff is CC'd to the list, is there some other list you think folks should CC problems on? Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
Alec Warner anta...@gentoo.org said: On Mon, May 16, 2011 at 11:24 AM, Markos Chandras hwoar...@gentoo.org wrote: On Mon, May 16, 2011 at 08:19:45PM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: El 16/05/11 19:54, Kacper Kowalik escribió: Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. To some of us (i.e. me as a staffer and probably any wanna be developer following the list) it is a good way to learn from others' mistake before applying for full developership. This may be a bit of surprise to you but this is not an educational list. If you people disagree with these kind of commits feel free to open a bug to QA/Devrel like the policy suggests. But pretty please try to break this non-sense loop of this and similar threads. I actually value times when this stuff is CC'd to the list, is there some other list you think folks should CC problems on? This is exactly where these sorts of emails should go so every other developer can see what's going on and ensure they are also following current policies. Don't make yet another list...that's just pointless. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild
On Mon, May 16, 2011 at 12:45:14PM -0700, Alec Warner wrote: On Mon, May 16, 2011 at 11:24 AM, Markos Chandras hwoar...@gentoo.org wrote: On Mon, May 16, 2011 at 08:19:45PM +0200, Francisco Blas Izquierdo Riera (klondike) wrote: El 16/05/11 19:54, Kacper Kowalik escribió: Neither of those points include sending mail to gentoo-dev, which tend to quickly convert into the witch hunt and seldom lead to anything conclusive. To some of us (i.e. me as a staffer and probably any wanna be developer following the list) it is a good way to learn from others' mistake before applying for full developership. This may be a bit of surprise to you but this is not an educational list. If you people disagree with these kind of commits feel free to open a bug to QA/Devrel like the policy suggests. But pretty please try to break this non-sense loop of this and similar threads. I actually value times when this stuff is CC'd to the list, is there some other list you think folks should CC problems on? Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 This problem is not a technical one to justify discussion on gentoo-dev list. This is clearly a disagreement over the established policies which should go through QA and/or Devrel if someone feels like it worths pushing it so far. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpeAtYaBdY7I.pgp Description: PGP signature
