[packman] Maintainers speak up (was: Package update workflow?)

[Pascal Bleser]

On 2012-05-04 18:36:26 (+0100), Cristian Morales Vega <reddwarf at opensuse.org> wrote:
> On 4 May 2012 16:48, Pascal Bleser <pascal.bleser at opensuse.org> wrote:
> > On 2012-05-04 15:58:33 (+0100), Cristian Morales Vega <reddwarf at opensuse.org> wrote:
> > That's why a lot of packages don't really have much of a
> > maintainer and why, instead, I'm jumping from one package to
> > another like a fire fighter. If someone feels like wanting to
> > own packages in Packman, be my guest, please do so ;)

> A solution is to just lower the workload.
> I think a problem is that nobody wants to drop packages. If we had
> download statistics probably we would find packages with *zero*
> downloads! Usually packages that have been abandoned upstream and are
> therefore the ones that take more time to make them build in the
> latest versions.

Quite possibly, yes.

> transcode is dead, let's accept it. And I see 11 packages that require
> it. Either the dependencies are wrong or those packages should have
> already started to move to something else. Those packages are usually
> DVD related... we are in 2012!!! DVDs??? Who uses those any more?

dvdrip is still quite popular though, afaik. At least we did get
bug reports about it not too long ago.
mythtv uses it too.

> There a few packages I just don't feel motivated to fix because I
> don't think any user really cares. If you look at the Packman build
> service the situation looks bad. But we don't have so many users
> complaining here. Perhaps it's just that no user cares about those
> packages any more.

Possibly, but unfortunately we don't have good means to find
out.

Well, except removing them and waiting for users to scream.
That always works, and maybe that's the way to do it.

> And it could be argued that we could drop Evergreen and SLE targets
> from Essentials to also lower the workload. But if interested people
> can accept its current state I guess it's not such a problem.

They occasionally create some work because things don't build
there from time to time. I only bother with fixing the builds
for them with stuff from Essentials (e.g. backporting older
versions of dependencies, etc), at least for packages I believe
could be really useful (vlc, mplayer, ffmpeg).

Those are clearly "best effort".

> >> So... there is no clear policy. And if you trust the
> >> maintainer/bugowner tags in the package metadata it's easy to be
> >> worried about stepping on the toes of somebody that isn't there.

> > How do you mean?

> Just that, that I don't know who disappeared and who is just in a two
> weeks holiday. I don't do something expecting the maintainer to do it
> (searching for some other package broken...) or send an email to
> him... Just to find he is not there any more.

Yep, I understand. Hope my post clarified the situation a bit.

> But more important. I somebody sees in the metadata that a package has
> a maintainer (even if that maintainer is not available any more) he is
> not going to offer himself to be the new maintainer.

> Do you want new maintainers? Publish here a list of packages without
> maintainer and interested people will appear. But... there is a list
> of packages without a maintainer? Can it be created reliably at all?

Well, the situation, right now, as I see it:
* Manfred takes good care of a few packages that need some
  experience with them, most prominently ffmpeg and xine
* I'm staying on top of mixxx, MPlayer, smplayer and some jack
  related packages (because I use them all the time)
* almost everything else: has no maintainer and I'm jumping in
  because no one else does

Manfred, do you have other packages that you'd like to remain
the sole maintainer of ?

Or anyone else ? Please speak up so we can draw a map of what's
actually maintained (and where maintainers would like to stay in
charge). Everything else is up for takes.

cheers
-- 
  -o) Pascal Bleser
  /\\ http://opensuse.org -- we haz green
 _\_v http://fosdem.org   -- we haz conf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.links2linux.de/pipermail/packman/attachments/20120504/812e5930/attachment.sig>