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