Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
В Сбт, 14/08/2010 в 20:06 +0300, Markos Chandras пишет: On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote: So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. List? Really? I use devmanual for ebuild development not list archives. Heh, devmanual is second source of information and first is good old official documentation. Take a look at our Ebuild policy: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1 Now let me read it: Versioning and revision bumps Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. This general and a unclear sentence. Below it is explained quite well: Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. For this this clear: if installed files changed do bump revision. And to make this more clear later text discusses cases when no revbump required: If you make an internal, stylistic change to the ebuild that does not change any of the installed files, then there is no need to bump the revision number. Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. Clear, right? And some exceptions, people mentioned in this tread: A revision bump is also not necessary if a minority of users will be affected and the package has a nontrivial average compilation time; use your best judgement in these circumstances. Yes, we need to merge two piecies of information. But at the moment we'll have to use both and in case devmanual has something unclear try to look at other documentation. So, please, do revbumps for all changes that affect installed files. ~arch is _supposed_ to be fast moving target and for ~arch it's ok to rebuild package just for small fix. In case users want something more stable that should use stable... -- Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Am 14.08.2010 19:35, schrieb Harald van Dijk: On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote: So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. If that's true, that doesn't make sense. Take one extreme case: let's say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it. But the majority of people using gcc don't even turn on java support, those that do have a working libgcj already, and gcc can easily take hours to build. Should you revbump? There are always exceptions. Maybe you don't consider LDFLAGS support in general one of those exceptions, but clearly some others do. You can't just tell them there are no exceptions when there are, you need to explain why this isn't a valid reason to make an exception. My impression, too, is that few people care enough about LDFLAGS support to want to rebuild packages for it, so I would not have bumped either, but I'm willing to be convinced I'm wrong. This is a nice example, why we should not create fixed rules for everything, but allow common rules with the usage of common sense. If we now create a rule, which says Bump on every change, always and forever, people will complain for big things like gcc, openoffice or kdelibs. Instead, we have a general rule, which every developer should learn at least from his mentor to revbump on every change for installed files, but also to use common sense. In the case of openoffice for example, it does not get a new version or revision for some minor updates, since rebuilding openoffice does take much time and resources. The same should apply for your example of LDFLAGS for gcc, so you can do it without a revbump there or wait, until a version bump comes in and directly add it there. So while general, non-fixed rules may result in some discussions, they also allow adjustments in a case by case decision, a fixed Always revbump rule creates issues at least for corner cases, in this case packages with very long compile times. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
hwoarang10/08/06 21:21:39
Modified: ChangeLog
Added:mlt-0.5.4-r1.ebuild
Log:
Respect {C,LD}FLAGS when building shared library. Bug #308873
(Portage version: 2.2_rc67/cvs/Linux x86_64)
While fixing bugs can't be bad and I thank you for doing it, I can see a
couple of important quality problems in this commit:
- There is absolutely no reference to any patch sent upstream and I have not
seen anything on the upstream dev ml.
- If you are not in cc of the gentoo bug nor in the herd alias, please cc
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to the dupes
too).
- That way you'll be able to quickly fix (apparently, I didn't check) obvious
mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check if you
can avoid it by doing a version bump instead.
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
hwoarang10/08/06 21:21:39
Modified: ChangeLog
Added:mlt-0.5.4-r1.ebuild
Log:
Respect {C,LD}FLAGS when building shared library. Bug #308873
(Portage version: 2.2_rc67/cvs/Linux x86_64)
While fixing bugs can't be bad and I thank you for doing it, I can see a
couple of important quality problems in this commit:
- There is absolutely no reference to any patch sent upstream and I have not
seen anything on the upstream dev ml.
Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
expect me to subscribe to 40 different ML and send them upstream? The
patch is there, the maintainer is CC on the bug. All he has to do it to
send this damn patch to upstream. I only care
about the QA status on tree. Most of them just use my patches and
contact upstream themselves. If this doesn't apply for you just let me
know.
- If you are not in cc of the gentoo bug nor in the herd alias, please cc
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to the
dupes
too).
- That way you'll be able to quickly fix (apparently, I didn't check) obvious
mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check if you
can avoid it by doing a version bump instead.
Well not always. If something is on ~testing then I don't think I should
spam the tree with revbumps. Stable users are my first priority so
unless something is on stable branch, I fix it as it is. I don't want to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
pgpU75OWlzyEv.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote: - If you are not in cc of the gentoo bug nor in the herd alias, please cc yourself on the bug. - Please close the bugs, even the dupes (and apply previous point to the dupes too). - That way you'll be able to quickly fix (apparently, I didn't check) obvious mistakes [1]. - You'll have to do a rev. bump for *FLAGS respect, please also check if you can avoid it by doing a version bump instead. Well not always. If something is on ~testing then I don't think I should spam the tree with revbumps. Stable users are my first priority so Stable may be more critical, but we support ~testing as well. How do you expect your changes to be tested before landing on stable if you don't revbump the packages, allowing them to reach our users? Please, don't skip revbumps to avoid tree spamming, thats why we have revbumps in the first place ;) unless something is on stable branch, I fix it as it is. I don't want to version bump anything because I don't want to mess with anyones packages. I only do QA fixing. If you have problem touching your packages just say it A. [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpmeRTNX8JRb.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Saturday 14 August 2010 15:50:53 Markos Chandras wrote:
On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
hwoarang10/08/06 21:21:39
Modified: ChangeLog
Added:mlt-0.5.4-r1.ebuild
Log:
Respect {C,LD}FLAGS when building shared library. Bug #308873
(Portage version: 2.2_rc67/cvs/Linux x86_64)
While fixing bugs can't be bad and I thank you for doing it, I can see a
couple of important quality problems in this commit:
- There is absolutely no reference to any patch sent upstream and I have
not seen anything on the upstream dev ml.
Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
expect me to subscribe to 40 different ML and send them upstream?
you don't need to subscribe, there's usually an AUTHORS file with emails you
can use...
The
patch is there, the maintainer is CC on the bug. All he has to do it to
send this damn patch to upstream.
I can use the same reasoning and ask:
Why don't you do it in the first place if that's all ?
I only care about the QA status on tree.
As I already said, that's good, but that's better achieved with long term
fixes rather than quick hacks IMHO
Most of them just use my patches and
contact upstream themselves. If this doesn't apply for you just let me
know.
Yes this doesn't apply to me because the most probable scenario will be this:
I'll touch the package in a couple of months/years, do a review of the
ebuild/patches, find out some patches need porting, waste time trying to
figure out why it's there in the first place, see it's been there for ages and
that the author didn't consider the fix good enough to upstream it, drop it.
- If you are not in cc of the gentoo bug nor in the herd alias, please cc
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to the
dupes too).
- That way you'll be able to quickly fix (apparently, I didn't check)
obvious mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check if
you can avoid it by doing a version bump instead.
Well not always. If something is on ~testing then I don't think I should
spam the tree with revbumps. Stable users are my first priority so
unless something is on stable branch, I fix it as it is. I don't want to
version bump anything because I don't want to mess with anyones
packages.
You're messing much more with one's package with quick'n'dirty fixes than
with a clean version bump with upstreamed patches...
I only do QA fixing. If you have problem touching your
packages just say it
I don't have problems with anyone touching my packages (esp. when they're
herds packages...); though when I'm not happy with the technical details I let
it be known and _really_ appreciate when the comments are taken into account
instead of aggressively discarded by trying to argue why it's not been perfect
in the first place ;)
A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote: On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote: - If you are not in cc of the gentoo bug nor in the herd alias, please cc yourself on the bug. - Please close the bugs, even the dupes (and apply previous point to the dupes too). - That way you'll be able to quickly fix (apparently, I didn't check) obvious mistakes [1]. - You'll have to do a rev. bump for *FLAGS respect, please also check if you can avoid it by doing a version bump instead. Well not always. If something is on ~testing then I don't think I should spam the tree with revbumps. Stable users are my first priority so Stable may be more critical, but we support ~testing as well. How do you expect your changes to be tested before landing on stable if you don't revbump the packages, allowing them to reach our users? I expect arch testers to do a pretty good testing before they mark them stable. Seems like I am the only one who fixes such issues without revbump. Strange, cvs log must be lying... Now lets see http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Ebuilds should have their -rX incremented whenever a change is made which will make a **substantial** difference to what gets installed by the package — by substantial, we generally mean something for which many users would want to upgrade. This is usually for bugfixes. Seems like it is up to maintainer's discretion to decide what it is substantial change and what it is not. Many users wont be directly affected from my changes. It is not like not respect CXX, CXXFLAGS after all. Simple compile fixes do not warrant a revision bump; this is because they do not affect the installed package for users who already managed to compile it. Small documentation fixes are also usually not grounds for a new revision. So you want me to force everyone to update the package just to respect the LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA issues? Please provide a patch for devmanual to make it more clear. If it is already clear maybe I am that stupid after all. In any case, I will keep doing what I do because you didn't convince me so far that my changes need a revbump. If arch testers fail to do proper testing thats really *REALLY* not my fault. Testing is testing and I can't do a revbump for every little piece of shit I fix everytime. Please, don't skip revbumps to avoid tree spamming, thats why we have revbumps in the first place ;) unless something is on stable branch, I fix it as it is. I don't want to version bump anything because I don't want to mess with anyones packages. I only do QA fixing. If you have problem touching your packages just say it A. [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpQqJyitMeKu.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 04:37:04PM +0300, Alexis Ballier wrote:
On Saturday 14 August 2010 15:50:53 Markos Chandras wrote:
On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
hwoarang10/08/06 21:21:39
Modified: ChangeLog
Added:mlt-0.5.4-r1.ebuild
Log:
Respect {C,LD}FLAGS when building shared library. Bug #308873
(Portage version: 2.2_rc67/cvs/Linux x86_64)
While fixing bugs can't be bad and I thank you for doing it, I can see a
couple of important quality problems in this commit:
- There is absolutely no reference to any patch sent upstream and I have
not seen anything on the upstream dev ml.
Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
expect me to subscribe to 40 different ML and send them upstream?
you don't need to subscribe, there's usually an AUTHORS file with emails you
can use...
As I said, I thought that maintainers was responsible to do it since they
follow all the bug progress after all. So according to you I should do all the
work. Tempting
The
patch is there, the maintainer is CC on the bug. All he has to do it to
send this damn patch to upstream.
I can use the same reasoning and ask:
Why don't you do it in the first place if that's all ?
Cause I cannot maintain all the tree myself
I only care about the QA status on tree.
As I already said, that's good, but that's better achieved with long term
fixes rather than quick hacks IMHO
Most of them just use my patches and
contact upstream themselves. If this doesn't apply for you just let me
know.
Yes this doesn't apply to me because the most probable scenario will be this:
I'll touch the package in a couple of months/years, do a review of the
ebuild/patches, find out some patches need porting, waste time trying to
figure out why it's there in the first place, see it's been there for ages
and
that the author didn't consider the fix good enough to upstream it, drop it.
Sure, the changelogs are there though. I am trying to always write down as many
details as I can so the maintainer can easily track down changes.
- If you are not in cc of the gentoo bug nor in the herd alias, please cc
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to the
dupes too).
- That way you'll be able to quickly fix (apparently, I didn't check)
obvious mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check if
you can avoid it by doing a version bump instead.
Well not always. If something is on ~testing then I don't think I should
spam the tree with revbumps. Stable users are my first priority so
unless something is on stable branch, I fix it as it is. I don't want to
version bump anything because I don't want to mess with anyones
packages.
You're messing much more with one's package with quick'n'dirty fixes than
with a clean version bump with upstreamed patches...
Quick and dirty? Fair enough. Will try to contact upstream from now on. Seems
like I will maintain the entire tree in the end.
I only do QA fixing. If you have problem touching your
packages just say it
I don't have problems with anyone touching my packages (esp. when they're
herds packages...); though when I'm not happy with the technical details I
let
it be known and _really_ appreciate when the comments are taken into account
instead of aggressively discarded by trying to argue why it's not been
perfect
in the first place ;)
A.
I don't think what I do is perfect. But all this kind of judgement is
quite demotivated I must say.
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
pgpHlH84uLr9R.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Saturday 14 August 2010 17:00:38 Markos Chandras wrote: [...] - There is absolutely no reference to any patch sent upstream and I have not seen anything on the upstream dev ml. Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you expect me to subscribe to 40 different ML and send them upstream? you don't need to subscribe, there's usually an AUTHORS file with emails you can use... As I said, I thought that maintainers was responsible to do it since they follow all the bug progress after all. So according to you I should do all the work. Tempting yes please; I consider not doing it a bit rude as the maintainers will _have_ to clean after you. The patch is there, the maintainer is CC on the bug. All he has to do it to send this damn patch to upstream. I can use the same reasoning and ask: Why don't you do it in the first place if that's all ? Cause I cannot maintain all the tree myself you're confused; contributing to an(other) OSS project (and retaining authorship of your patches improvements) does not have much to do with maintaining a package. [...] I only do QA fixing. If you have problem touching your packages just say it I don't have problems with anyone touching my packages (esp. when they're herds packages...); though when I'm not happy with the technical details I let it be known and _really_ appreciate when the comments are taken into account instead of aggressively discarded by trying to argue why it's not been perfect in the first place ;) A. I don't think what I do is perfect. But all this kind of judgement is quite demotivated I must say. Don't be demotivated. The only judgement I made is on the technical side and not on the global goal; on that side you can just fix it, get thanks kudos and be done :) A.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 05:20:38PM +0300, Alexis Ballier wrote: On Saturday 14 August 2010 17:00:38 Markos Chandras wrote: [...] - There is absolutely no reference to any patch sent upstream and I have not seen anything on the upstream dev ml. Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you expect me to subscribe to 40 different ML and send them upstream? you don't need to subscribe, there's usually an AUTHORS file with emails you can use... As I said, I thought that maintainers was responsible to do it since they follow all the bug progress after all. So according to you I should do all the work. Tempting yes please; I consider not doing it a bit rude as the maintainers will _have_ to clean after you. So do I. Fixing your package and you don't even bother to send a *ready to go* patch upstream seems like a bit rude to me as well. Perhaps, we do have a complete different point of view in this one. Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his package, asked me to attach the patch so *he* can send it upstream. I thought that was the *default* policy. Anyway. I should talk to each maintainer separately when I fix his package. Seems to me is the best approach [...] A. -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpTplps6vV9i.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On 08/14/2010 10:29 AM, Markos Chandras wrote: So do I. Fixing your package and you don't even bother to send a *ready to go* patch upstream seems like a bit rude to me as well. Perhaps, we do have a complete different point of view in this one. Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his package, asked me to attach the patch so *he* can send it upstream. I thought that was the *default* policy. Anyway. I should talk to each maintainer separately when I fix his package. Seems to me is the best approach My two cents. In my opinion, whether a commit is good or not depends on whether it left Gentoo as a whole in better or worse shape than before it was made. Here it sounds like we had QA problems before the commit, and no QA problems after the commit. Maybe the maintainer has some work to do now, but he had it to do anyway, and the maintainers have less work to do now than they did before the patches were made. Now, if he had broken something due to a sloppy commit I'd be more concerned. Many hands make for lighter work. The best way to have many hands is to make individual tasks easier. 1+1+1+1+1 is going to happen faster than 3+2, since nobody ever gets around to doing 3. If we give devs an ultimatum like fix it all or don't fix anything guess which one they'll pick? Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote: On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote: On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote: - If you are not in cc of the gentoo bug nor in the herd alias, please cc yourself on the bug. - Please close the bugs, even the dupes (and apply previous point to the dupes too). - That way you'll be able to quickly fix (apparently, I didn't check) obvious mistakes [1]. - You'll have to do a rev. bump for *FLAGS respect, please also check if you can avoid it by doing a version bump instead. Well not always. If something is on ~testing then I don't think I should spam the tree with revbumps. Stable users are my first priority so Stable may be more critical, but we support ~testing as well. How do you expect your changes to be tested before landing on stable if you don't revbump the packages, allowing them to reach our users? I expect arch testers to do a pretty good testing before they mark them stable. Seems like I am the only one who fixes such issues without revbump. Strange, cvs log must be lying... Now lets see http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Ebuilds should have their -rX incremented whenever a change is made which will make a **substantial** difference to what gets installed by the package — by substantial, we generally mean something for which many users would want to upgrade. This is usually for bugfixes. Seems like it is up to maintainer's discretion to decide what it is substantial change and what it is not. Many users wont be directly affected from my changes. It is not like not respect CXX, CXXFLAGS after all. Simple compile fixes do not warrant a revision bump; this is because they do not affect the installed package for users who already managed to compile it. Small documentation fixes are also usually not grounds for a new revision. So you want me to force everyone to update the package just to respect the LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA issues? Please provide a patch for devmanual to make it more clear. If it is already clear maybe I am that stupid after all. In any case, I will keep doing what I do because you didn't convince me so far that my changes need a revbump. If arch testers fail to do proper testing thats really *REALLY* not my fault. Testing is testing and I can't do a revbump for every little piece of shit I fix everytime. Does respecting LDFLAGS change the installed files in any way? yes. Will users benefit from your change if you don't revbump? No. I think that chain of logic is enough to warrant a revbump and it is covered by the devmanual since the change affects the installed package. It's merely a cp, why are you making such a fuss about it? You're doing a good job already, we're just pointing out ways to make it even better :) BTW, archs do the final testing, but much testing is done by the users themselves, who report the bugs that get fixed before the packages get a STABLEREQ bug ;) Please, don't skip revbumps to avoid tree spamming, thats why we have revbumps in the first place ;) unless something is on stable branch, I fix it as it is. I don't want to version bump anything because I don't want to mess with anyones packages. I only do QA fixing. If you have problem touching your packages just say it A. [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpeRtWlpAORz.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Richard Freeman ri...@gentoo.org said: On 08/14/2010 10:29 AM, Markos Chandras wrote: So do I. Fixing your package and you don't even bother to send a *ready to go* patch upstream seems like a bit rude to me as well. Perhaps, we do have a complete different point of view in this one. Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his package, asked me to attach the patch so *he* can send it upstream. I thought that was the *default* policy. Anyway. I should talk to each maintainer separately when I fix his package. Seems to me is the best approach My two cents. In my opinion, whether a commit is good or not depends on whether it left Gentoo as a whole in better or worse shape than before it was made. Here it sounds like we had QA problems before the commit, and no QA problems after the commit. Maybe the maintainer has some work to do now, but he had it to do anyway, and the maintainers have less work to do now than they did before the patches were made. Now, if he had broken something due to a sloppy commit I'd be more concerned. Many hands make for lighter work. The best way to have many hands is to make individual tasks easier. 1+1+1+1+1 is going to happen faster than 3+2, since nobody ever gets around to doing 3. If we give devs an ultimatum like fix it all or don't fix anything guess which one they'll pick? exactly. maybe the maintainer has to do some catch up work, but thats ok. the aim is to improve the tree and not for QA to do the work of the maintainer. perhaps there is a lesson here though: if the bug isnt closed as soon as the patch has hit the tree, but its subject changed to 'push QA patch upstream', then it is clear what is left to do. Rich signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. Why, since until recently, nobody gave a crap about this kind of QA issues? Thats a bad excuse! Please provide a patch for devmanual to make it more clear. Good idea. Any takers? thanks kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote:
On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote:
On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
- If you are not in cc of the gentoo bug nor in the herd alias,
please cc
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to
the dupes
too).
- That way you'll be able to quickly fix (apparently, I didn't check)
obvious
mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check
if you
can avoid it by doing a version bump instead.
Well not always. If something is on ~testing then I don't think I should
spam the tree with revbumps. Stable users are my first priority so
Stable may be more critical, but we support ~testing as well. How do you
expect your changes to be tested before landing on stable if you don't
revbump the packages, allowing them to reach our users?
I expect arch testers to do a pretty good testing before they mark them
stable. Seems like I am the only one who fixes such issues without revbump.
Strange, cvs log must be lying...
Now lets see
http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
Ebuilds should have their -rX incremented whenever a change is made which
will
make a **substantial** difference to what gets installed by the package — by
substantial, we generally mean something for which many users would want to
upgrade. This is usually for bugfixes.
Seems like it is up to maintainer's discretion to decide what it is
substantial change and what it is not. Many users wont be directly affected
from my changes. It is not like not
respect CXX, CXXFLAGS after all.
Simple compile fixes do not warrant a revision bump; this is because they
do
not affect the installed package for users who already managed to compile
it.
Small documentation fixes are also usually not grounds for a new revision.
So you want me to force everyone to update the package just to respect the
LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA
issues?
Please provide a patch for devmanual to make it more clear. If it is
already clear maybe I am that stupid after all.
In any case, I will keep doing what I do because you didn't convince me so
far
that my changes need a revbump. If arch testers fail to do proper testing
thats really *REALLY* not my fault. Testing is testing and I can't do a
revbump for every little piece of shit I fix everytime.
Does respecting LDFLAGS change the installed files in any way? yes.
Will users benefit from your change if you don't revbump? No.
I think that chain of logic is enough to warrant a revbump and it is
covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
It's merely a cp, why are you making such a fuss about it? You're doing
a good job already, we're just pointing out ways to make it even better
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway.
:)
BTW, archs do the final testing, but much testing is done by the users
themselves, who report the bugs that get fixed before the packages get a
STABLEREQ bug ;)
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected or
not. I wouldn't do it either. This
Please, don't skip revbumps to avoid tree spamming, thats why we have
revbumps in the first place ;)
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
unless something is on stable branch, I fix it as it is. I don't want to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
--
Alex Alexander -=- wired
Gentoo
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote: So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. List? Really? I use devmanual for ebuild development not list archives. Why, since until recently, nobody gave a crap about this kind of QA issues? Thats a bad excuse! Yet it is true. The tree is flood with such packages. So my assumption is correct. Maintainers didn't and still don't give a crap about this QA issue, other they wouldn't commit broken packages in the first place Please provide a patch for devmanual to make it more clear. Good idea. Any takers? thanks kind regards Thilo -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgpQyU6NZZJEv.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
Does respecting LDFLAGS change the installed files in any way? yes.
Will users benefit from your change if you don't revbump? No.
I think that chain of logic is enough to warrant a revbump and it is
covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
The fact that others do what you do doesn't automatically make it right.
It's merely a cp, why are you making such a fuss about it? You're doing
a good job already, we're just pointing out ways to make it even better
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway.
All your fixes are important else you wouldn't be doing them.
I still don't understand why you don't want to revbump.
Your changes may not affect program features but they do fix hidden
issues. Issues that might help users later (for example, rebuilding a
package with --as-needed may reduce revdep-rebuilds in the future).
You can always try to reduce revbumps by doing all the things you
mentioned together, if possible.
In any case, unless we're talking about openoffice or kdelibs, revbumps
don't really cost so much anymore.
:)
BTW, archs do the final testing, but much testing is done by the users
themselves, who report the bugs that get fixed before the packages get a
STABLEREQ bug ;)
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected or
not. I wouldn't do it either. This
I never said users report these specific bugs. But they will test *your*
revbumps and may report other problems you didn't hit.
Please, don't skip revbumps to avoid tree spamming, thats why we have
revbumps in the first place ;)
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
Now you're just being stubborn. I'm pretty sure your mentor told you any
change to installed files warrants a revbump ;)
Do we really need bureaucracy to enforce a commonly followed but not
documented policy?
unless something is on stable branch, I fix it as it is. I don't want
to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
pgpjSxqLycMhR.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 08:21:15PM +0300, Alex Alexander wrote:
On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
Does respecting LDFLAGS change the installed files in any way? yes.
Will users benefit from your change if you don't revbump? No.
I think that chain of logic is enough to warrant a revbump and it is
covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
The fact that others do what you do doesn't automatically make it right.
It means that there is something wrong with documentation
It's merely a cp, why are you making such a fuss about it? You're doing
a good job already, we're just pointing out ways to make it even better
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a
good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody
flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway.
All your fixes are important else you wouldn't be doing them.
I still don't understand why you don't want to revbump.
Cause I already said that I consider my changes trivial so the only actual
testing could be performed when the package is about to get stabilized
Your changes may not affect program features but they do fix hidden
issues. Issues that might help users later (for example, rebuilding a
package with --as-needed may reduce revdep-rebuilds in the future).
You can always try to reduce revbumps by doing all the things you
mentioned together, if possible.
No cause I am not the maintainer so I fix whatever gets reported on bugzilla
and assigned to QA.
In any case, unless we're talking about openoffice or kdelibs, revbumps
don't really cost so much anymore.
Not if you own a single core CPU
:)
BTW, archs do the final testing, but much testing is done by the users
themselves, who report the bugs that get fixed before the packages get a
STABLEREQ bug ;)
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected
or
not. I wouldn't do it either. This
I never said users report these specific bugs. But they will test *your*
revbumps and may report other problems you didn't hit.
Please, don't skip revbumps to avoid tree spamming, thats why we
have
revbumps in the first place ;)
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
Now you're just being stubborn. I'm pretty sure your mentor told you any
change to installed files warrants a revbump ;)
Pretty sure this rule is not that strict.
Do we really need bureaucracy to enforce a commonly followed but not
documented policy?
So document this policy to point stubborn maintainers to it
Apparently I pissed a lot people off so I will siege my QA fixes for now.
Apparently I need a break
unless something is on stable branch, I fix it as it is. I don't
want to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
A.
[1] https://bugs.gentoo.org/show_bug.cgi?id=332523
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
--
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
pgpLxpDP8Uwvg.pgp
Description:
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote: So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. If that's true, that doesn't make sense. Take one extreme case: let's say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it. But the majority of people using gcc don't even turn on java support, those that do have a working libgcj already, and gcc can easily take hours to build. Should you revbump? There are always exceptions. Maybe you don't consider LDFLAGS support in general one of those exceptions, but clearly some others do. You can't just tell them there are no exceptions when there are, you need to explain why this isn't a valid reason to make an exception. My impression, too, is that few people care enough about LDFLAGS support to want to rebuild packages for it, so I would not have bumped either, but I'm willing to be convinced I'm wrong.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 08:34:13PM +0300, Markos Chandras wrote: said, commit an actual patch, assigned to QA and if the rest of the members agree on that I am willing to change my policy. Now you're just being stubborn. I'm pretty sure your mentor told you any change to installed files warrants a revbump ;) Pretty sure this rule is not that strict. Do we really need bureaucracy to enforce a commonly followed but not documented policy? So document this policy to point stubborn maintainers to it Apparently I pissed a lot people off so I will siege my QA fixes for now. Apparently I need a break I'm pretty sure you didn't piss off anyone. We're having a conversation about something, we're not fighting :) -- Alex Alexander -=- wired Gentoo Linux Developer -=- Council / Qt / KDE / more www.linuxized.com pgpyYRRiLy0N8.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Markos Chandras posted on Sat, 14 Aug 2010 20:00:40 +0300 as excerpted:
Cause I don't like users to compile the same damn package over and over.
-r1 for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is
that a good reason or not? It is not like I introduce huge patches with
bugfixes etc. My fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted
and there isn't much for users to test anyway. Either you respect the
bloody flags or not. I don't do blindly commits. I try to test the
packages in multiple chroots anyway.
User perspective here...
For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently). The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.
Better the few at a time, even if some of them end up being bumped and
built twice as a result, than the multiple hundred at once.
So I'm not going to get into who's right or wrong vs. current policy, but
that's my perspective as a user. For LDFLAGS respecting changes at least,
please do the rev-bumps, as the cost of failing to do so, thus triggering
a mass update when a base lib changes, far exceeds that of dealing with
them on a trickle-in basis, even if a few do end up updated twice as a
result.
Thanks. =:^)
--
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 media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On 08/14/2010 02:35 PM, Duncan wrote: User perspective here... For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump. Yes, it requires a rebuild, but the rebuilds will occur as the bugs are fixed so it's a few at a time for people who keep reasonably updated (every month or more frequently). The alternative is triggering a several- hundred-package rebuild when some base library package updates, because all those LDFLAGS respecting changes weren't rev-bumped and the user's installed set is still ignoring them, and thus --as-needed. Interesting - I was looking at it in the opposite way. Not having as-needed means that I /might/ have to rebuild that one package unnecessarily at some point in the future - if it isn't upgraded first for some other reason. Rev-bumping the build means that I /will/ have to rebuild that one package for certain - right now. I think we can all at least agree that this is a gray area as far as the INTENT of the (apparently unwritten) policy goes. I would like to echo Markos's comment that having policies written down, if only to point stubborn maintainers to them, would be helpful. The other reason to have them written is so that they go through some kind of review, and there is some way of challenging them if they no longer make sense. In any case, I think we're making a pretty big deal about a pretty small issue - we can probably all afford to think about this a little more and move on... Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, 14 Aug 2010 19:35:56 +0200 Harald van Dijk true...@gentoo.org wrote: On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote: So you want me to force everyone to update the package just to respect the LDFLAGS. yes. IIRC it has been stated on this list before, that a change which changes the resulting binary always needs to be done in a revbump. If that's true, that doesn't make sense. Take one extreme case: let's say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it. But the majority of people using gcc don't even turn on java support, those that do have a working libgcj already, and gcc can easily take hours to build. Should you revbump? There are always exceptions. Maybe you don't consider LDFLAGS support in general one of those exceptions, but clearly some others do. You can't just tell them there are no exceptions when there are, you need to explain why this isn't a valid reason to make an exception. My impression, too, is that few people care enough about LDFLAGS support to want to rebuild packages for it, so I would not have bumped either, but I'm willing to be convinced I'm wrong. I think it's up to the discretion of the maintainer in this case. Of course, when you're not the maintainer, err on the side of caution. (i wouldn't do a revbump for LDFLAGS on my own packages. CFLAGS, yes.) -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, 14 Aug 2010 17:00:38 +0300 Markos Chandras hwoar...@gentoo.org wrote: you don't need to subscribe, there's usually an AUTHORS file with emails you can use... As I said, I thought that maintainers was responsible to do it since they follow all the bug progress after all. So according to you I should do all the work. Tempting When you take on the task of fixing a bug in a package you don't maintain, you are responsible for the whole task, not just the part you want to do. You essentially become the maintainer for that change. So just do what you would do if it really was your package. And really I don't care if you upstream the patch or not, but when the maintainer politely asks you to do so the correct response is okay, not do it yourself. -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 02:46:21PM -0600, Ryan Hill wrote: On Sat, 14 Aug 2010 17:00:38 +0300 Markos Chandras hwoar...@gentoo.org wrote: you don't need to subscribe, there's usually an AUTHORS file with emails you can use... As I said, I thought that maintainers was responsible to do it since they follow all the bug progress after all. So according to you I should do all the work. Tempting When you take on the task of fixing a bug in a package you don't maintain, you are responsible for the whole task, not just the part you want to do. You essentially become the maintainer for that change. So just do what you would do if it really was your package. And really I don't care if you upstream the patch or not, but when the maintainer politely asks you to do so the correct response is okay, not do it yourself. -- fonts, gcc-porting, and it's all by design toolchain, wxwidgetsto keep us from losing our minds @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 You misunderstood me. I never said do it yourself. I said that I didn't know that I have to do it myself and that I will do it from now on -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgp6L6stUZH0S.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
Richard Freeman wrote: On 08/14/2010 02:35 PM, Duncan wrote: User perspective here... For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump. Yes, it requires a rebuild, but the rebuilds will occur as the bugs are fixed so it's a few at a time for people who keep reasonably updated (every month or more frequently). The alternative is triggering a several- hundred-package rebuild when some base library package updates, because all those LDFLAGS respecting changes weren't rev-bumped and the user's installed set is still ignoring them, and thus --as-needed. Interesting - I was looking at it in the opposite way. Not having as-needed means that I /might/ have to rebuild that one package unnecessarily at some point in the future - if it isn't upgraded first for some other reason. Rev-bumping the build means that I /will/ have to rebuild that one package for certain - right now. I think we can all at least agree that this is a gray area as far as the INTENT of the (apparently unwritten) policy goes. I would like to echo Markos's comment that having policies written down, if only to point stubborn maintainers to them, would be helpful. The other reason to have them written is so that they go through some kind of review, and there is some way of challenging them if they no longer make sense. In any case, I think we're making a pretty big deal about a pretty small issue - we can probably all afford to think about this a little more and move on... Rich I'm with Duncan as well. I update pretty regular, usually daily, just because I want to update a few packages at a time. If I do a truly HUGE update, what is it that broke what? If I do 3 to 10 packages and something breaks, I can go look at those 3 to 10 packages for either a version mismatch or just a plain old broken package. If I have to update everything at once, where does one even start to look? I have almost a thousand packages here and I would hate to have to go look for a needle in a haystack. That's a large haystack to go looking in. I might also mention that I see rebuilds from time to time where it looks like nothing has changed. I always let them rebuild anyway because I know there is something different under the hood that I don't see. Open Office is one that I dread tho. lol Even tho it would mean a gradual system rebuild, I'd say that I'm for it. As they get changed, bump them up a notch and let them get rebuilt. Back to my hole now. Dale :-) :-)
