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.