[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Package Review Stats for the week ending January 18th, 2009

On Thu, 29 Jan 2009, Behdad Esfahbod wrote:
> > Taking co-maintainship or even the package doesn't solve 'em all, as I
> > pointed out above already. If the "Red Hat guy" is upstream of software,
> > it's more hard to work around.
> Why's that?  I don't understand.  Now you're attacking the upstream
> maintainers too?

Maybe next time, when I write another huge e-mail like in December 2008 ;-)

What I want to say is, that if somebody is upstream or one of the upstream
maintainers, he/she/it/they is/are the best knowing people of that piece of
software. If he/she/it/they is/are downstream as well, I see this usually
as a benefit. If upstream is then less responsive (e.g. as at ethtool), it
is hard to do a good job as co-maintainer as well.

> I'm smart enough to not need training.  I can train myself.  The question is,
> should I learn RPM?  I don't think so.  My time is better spent doing upstream
> work.  As I've been saying repeatedly, RPM is not my (and many "RH guys"')
> strength, and I'm honest about it.  I know how to update my packages to the
> new version of the upstream package I just released.  And I hope you don't
> have any problem with that.  For anything more complicated, I'd be happy to
> let more experienced Fedora packages jump in.  Such collaboration has happened
> between me and Nicolas Mailhot already.  He oversees font packaging, and I fix
> upstream issues he wants to see fixed.  That's constructive IMO.

If you don't want to enhance your packaging skills around RPM, you simply
must not be a package maintainer. Go and orphan your packages, if you want
to focus just on upstream. Either do good work up- and downstream or just
do good work downstream or just good work upstream. But doing good work
only upstream and less good work downstream is inacceptable - and as well
indiscutable. Period.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]