[packman] Package update workflow?

Pascal Bleser pascal.bleser at opensuse.org
Fri May 4 17:48:04 CEST 2012

On 2012-05-04 15:58:33 (+0100), Cristian Morales Vega <reddwarf at opensuse.org> wrote:
> On 4 May 2012 15:39, Stefan Seyfried <stefan.seyfried at googlemail.com> wrote:
> > a small question wrt. the workflow in pmbs -- in order to not step on
> > anyone's toes :-)

> > In order to update clipgrab to the latest version, I have linked it into
> > home:seife and updated it there. It builds fine.

> > The question is: what to do now? Submitrequest and self-accept?
> > Submitrequest and wait for somebody else to accept?

> > Should I commit directly to Extra next time? (I wouldn't like that
> > because I usually want to test if it really builds and works... :-)

Sorry, tl;dr ahead ;)

There is no policy, because there has never really been a team,
just a handful of people trying to cope with the insane amount
of work (tried a few times in the past to motivate for more
communication and teamwork, but it always failed, and I'm as
guilty as everyone else for that).

The situation is pretty much the same right now, although I
believe the bugtracker helps, and at least there are a few
things that are being discussed (such as on this thread).

To me, personally, I see it like this:
- if I give you maintainer level on a package that's in a
  non-home project (Essentials, Multimedia, Extra, Games), then
  do as you wish because you have my complete trust

- if, e.g. for changes to more critical/essential packages
  (ffmpeg, mplayer, ...), you prefer another maintainer to
  review the change, then make a SR

I'm fine with any other proposal, or even a somewhat more
formal/organized approach, but that would require us to work as
a team in the first place.

There have been quite a lot of packagers who have offered to
help, and who have an account, but who have only done very minor
fixes, or added new packages (e.g. because they weren't allowed
to put them on build.o.o), and who pretty much disappear again.

That's really sad, at least for me, because from my perspective,
there isn't all that much help going on and most of the load is
still on my shoulders (Detlef seems to be angry/disgusted and
AWOL, which is really bad because he also took care of a huge
amount of work, Manfred is still there and is in charge of a very
few albeit critical packages (but with great care :)), Toni
suddenly dissappeared a year or two ago leaving us with several
hundreds of his packages, etc...).

Don't get me wrong, any help is much appreciated, but it would
be even more useful if some packagers would step in and feel
more like being in charge here and take ownership of some

Don't be afraid of stepping on other people's toes too much:

- some packages need to be handled with care because they are
  used by tens of thousands of people (mplayer, vlc, ffmpeg,
  xine, ...) and have typically had the same maintainer for a
  very long time (henne then me, detlef then me, manfred,
  manfred, respectively ;)), so let's be careful with things
  that are in Essentials

- do _not_ replace packages with _link's to build.o.o without
  giving it good thought first, and ideally not without
  discussing it on the list first: there are many issues with
  the way the maintainers of multimedia:libs and multimedia:apps
  on build.o.o handle their packages, I've mentioned that in the
  past (they don't care about older distros, replace foo-devel
  with pkgconfig(foo) which doesn't work on SLE or Evergreen,
  they carelessly rename packages which breaks a lot of other
  things (e.g. taglib -> libtag), etc..., and generally speaking
  they don't see their packages are linked in Packman, hence
  they don't see the side effects of changes to their packages,
  and that doesn't work too well)

- if you have some time to spend, pick broken packages, fix
  them, commit directly, there is no need for a review process,
  our staffing is just way too thin for that -- especially if
  you're a seasoned packager (like you ;)), you know what you're

- same goes with upgrades: Packman has always had the unwritten
  policy of updating packages to their latest version, always;
  while there are good points for going with a different
  strategy (e.g. as for openSUSE releases, only backport
  patches), my impression is that our user base is 50/50 on
  that; with a lot more people on the team, we could surely even
  do both, at least for the stuff in Essentials, but it isn't
  the case; short version: newer upstream version, just go for
  it, no need for reviews, you know what you're doing

> Good question. In my first commit I was said to never again create a
> branch because the build power was too limited. Then people complained
> because of committing directly. Once I got a submit request I didn't
> like accepted by somebody else. I saw people in this mailing list
> discussing different ways to fix something and never getting an answer
> (and the problem remained unfixed).

Yes, the build power is quite limited (although we're very
thankful to the few people who provide us with a handful of
build hosts for free -- without them, Packman would be
unmanageable, plain simple), so we do have to be careful to not
create large amounts of branches if it isn't necessary.

But it's perfectly fine to branch a package in order to submit
it (but please clean up afterwards, once it's done, and rdelete
your home: packages).

And yes, many problems, questions and bug reports remain
unfixed/unanswered because I'm doing 90% of the work, and I have
other things to do as well.

> Now I created a bug (PM-15) and a submit request (#192) for a fix that
> for me is so obvious that shouldn't require any discussion. And for a
> package that I don't think has any real active maintainer any more (I
> guess Pascal will be the one to accept it).

Yup, accepted ;)

As for not having an active maintainer: that comes from the
history of our team, or what's left of it. At least a third of
the packages in Packman were added and maintained by Toni
"oc2pus" Graffy, who, as said above, completely disappeared from
one day to the other (hope nothing bad happened, by the way, but
I have no way of finding out, emails remained unanswered).

Then suddenly Detlef and I had to step in and also nanny Toni's
packages, even though we already had our fair share of things to

And now Detlef seems to be AWOL too and... well, you get the

There are a good handful of other people who used to be active
but who left the project, the situation slowly degraded over

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

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

  -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/c6000090/attachment.sig>

More information about the Packman mailing list