[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
> hwoarang    10/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

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

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:
> > hwoarang    10/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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

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:
> > > hwoarang    10/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

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 4184 bytes --]

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:
> > > > hwoarang    10/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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

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

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Richard Freeman]

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

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 1851 bytes --]

Richard Freeman <rich0@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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 468 bytes --]

> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 5893 bytes --]

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 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 5390 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[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.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Duncan]

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

[Richard Freeman]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

On Sat, 14 Aug 2010 19:35:56 +0200
Harald van Dijk <truedfx@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, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Sat, 14 Aug 2010 17:00:38 +0300
Markos Chandras <hwoarang@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, wxwidgets                        to keep us from losing our minds
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

On Sat, Aug 14, 2010 at 02:46:21PM -0600, Ryan Hill wrote:
> On Sat, 14 Aug 2010 17:00:38 +0300
> Markos Chandras <hwoarang@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, wxwidgets                        to keep us from losing our minds
> @ gentoo.org                EFFD 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

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Dale]

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

:-)  :-)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 2283 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Peter Volkov]

В Сбт, 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=3&chap=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.