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.
Greetings,
Robert