This Time Self-Hosted
dark mode light mode Search

Why I don’t agree with not giving upstream’s package to the same person

Seems like many people get a strange idea by reading mailing list, mostly because of Ciaran’s claims that happens pretty often, that if you’re upstream of a given software you cannot be downstream (as in ebuild maintainer), because you “remove a layer of QA”.

Yes this would be all and well, if we had an infinite amount of developers and an infinite amount of time. Unfortunately while the Time is infinite, our lifespan is not, and not even as long as Vulcans, and we all know that we’re mostly understaffed. Which means that removing a layer would still be better than an unmaintained package.

Let’s then consider another problem. I became xine-lib’s upstream because I was working as a downstream for it. Now if we were to enforce the rule above, I should now give up xine-lib to another maintainer. So I should first find someone crazy enough to take xine-lib (which isn’t easy), and then he would have to understand all the trouble I did work to understand in the past. It’s a time waste we cannot afford right now.

If from one side you can say to remove a QA layer, from the other if you’re both upstream and downstream you probably are the person that knows that software better in Gentoo, so you usually have a way to find what’s really needed to be done…

But one has to say that it’s more likely for CVS snapshot to be in tree when the ebuild maintainer is upstream, in my case mostly because I do use the CVS HEAD version of xine-lib almost as my “personal fixes tree” 😉

Comments 2
  1. I didn’t say “can’t”. I said it wasn’t a good idea. I didn’t say “can’t” precisely because of the whole not enough people thing.

  2. I don’t think it is really an issue. Any upstream developer probably uses a Linux distro of somekind and is therefore a quasi-downstream dev for that distro.Trying to avoid problems can, as you mention, lead to quite a bit of inefficiency. It pays to be more pragmatic and ask whether it is necesary to even worry about it (as you are). It is fairly easy to test. If the quality of xine-lib.ebuild starts to degrade then you should find a new downstream dev and if it doesn’t then don’t.

Leave a Reply to Ciaran McCreeshCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.