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

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

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

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

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

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.

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

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

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