[packman] Package update workflow?

[Pascal Bleser]

On 2012-05-05 22:21:39 (+0200), Stefan Seyfried <stefan.seyfried at googlemail.com> wrote:
> Am 04.05.2012 17:48, schrieb Pascal Bleser:
> > 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:
[...]
> > 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

> I actually did not even check the maintainership -- in the openSUSE BS I
> am maintainer of all the Projects I am maintaining packages in, so it
> didn't even occur to me that there might be a permissions issue :-)

Added you as maintainer in all toplevel projects (Essentials,
Multimedia, Games, Extra).

> Anyway, for now the submitrequest is the only thing I can do to get it
> updated and that's what I have done: request 196.

Thanks, accepted.

[...]
> I think a "common sense approach" makes sense here: trivial stuff (like
> my clipgrab update) can go in directly, especially if it is a leaf
> package with no dependencies.
> Updates to core stuff like ffmpeg & friends by people who have not yet
> proven they know what they are doing should be SR'ed and reviewed.

Yes, that's indeed what it boils down to :)

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

> I'm trying to help changing this -- for example by "encouraging" our
> trainees to help out on packman (and openSUSE BS) and my boss is
> indirectly sponsoring this effort by letting us do that in our paid time.

Awesome :)

> > 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
> > packages.

> That's actually what I'm trying to do :-)

Yes indeed, thanks a lot, even more useful from seasoned
packagers such as you (but every help is welcome, don't make me
say what I didn't :)).

> > Don't be afraid of stepping on other people's toes too much:
[...]
> > - 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
> >   doing
> > - 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

> Ok, I'll probably go through the impressive list of build failures in
> Extra and fix some of those to get comfortable with the workflow :-)

Note that many packages are also only there for historic reasons
(Packman predates build.o.o by many years).
We didn't import everything we had before we used OBS, but there
are definitely a bunch of packages that we could or even should
delete, especially what's not in Essentials and Multimedia.

Typically because it's maintained (better) somewhere on
build.o.o (often with spec files that have been copied from
Packman, almost always without letting us know).

But, obviously, common sense, before deleting a package, better
prod on the list first.

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

> Ok. I would feel quite uncomfortable to commit packages with only local
> build tested (although I'll try to implement some "automatic local build
> for all repos" thing so that I can run this overnight on my home server
> or something like that.

I think it's fine to do so.
Personally, I do local builds on 12.1 (x86_64) and then I
submit.
If builds fail on other variants, I do a local build to
reproduce, then fix, and probably also do local builds on a few
other distro versions (depends on the nature of the issue).
After all, if the build fails, the old version of the package
remains in the repository. Sometimes leads to issues when there
are interdependencies across packages (e.g. the gstreamer
stack), but typically that approach works fine.

Well, if I had only a handful of packages to maintain, I'm sure
I would test on all combos first but... ;)

> For now, I'll try to be careful to increase the quality of the packages
> I'm touchen and if I'm missing permissions on a project / package, I'll
> send a notification about the SR here so that someone can accept it.

You now have maintainership in all toplevel projects.

cheers, and thanks for joining the effort, it's much appreciated
(and that goes for everyone else on team as well of course :))

-- 
  -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/20120506/25382b18/attachment.sig>