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

[Markos Chandras]

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