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 itApparently I pissed a lot people off so I will siege my QA fixes for now. Apparently I need a break > > > > > > > unless something is on stable branch, I fix it as it is. I don't > > > > > > want to > > > > > > version bump anything because I don't want to mess with anyones > > > > > > packages. I only do QA fixing. If you have problem touching your > > > > > > packages just say it > > > > > > > > > > > > > > A. > > > > > > > > > > > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523 > > > > > > > > > > > > -- > > > > > > Markos Chandras (hwoarang) > > > > > > Gentoo Linux Developer > > > > > > Web: http://hwoarang.silverarrow.org > > > > > > > > > > -- > > > > > Alex Alexander -=- wired > > > > > Gentoo Linux Developer -=- Council / Qt / KDE / more > > > > > www.linuxized.com > > > > > > > > > > > > > > > > -- > > > > Markos Chandras (hwoarang) > > > > Gentoo Linux Developer > > > > Web: http://hwoarang.silverarrow.org > > > > Key ID: 441AC410 > > > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 > > > > > > > > > > > > -- > > > Alex Alexander -=- wired > > > Gentoo Linux Developer -=- Council / Qt / KDE / more > > > www.linuxized.com > > > > > > > > -- > > Markos Chandras (hwoarang) > > Gentoo Linux Developer > > Web: http://hwoarang.silverarrow.org > > Key ID: 441AC410 > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 > > > > -- > Alex Alexander -=- wired > Gentoo Linux Developer -=- Council / Qt / KDE / more > www.linuxized.com -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
pgpLxpDP8Uwvg.pgp
Description: PGP signature
