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