[packman] Package update workflow?

[Stefan Seyfried]

Hi Pascal,

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


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

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.

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


Sounds sensible.

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


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.


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

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


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

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

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.

Best regards,

	seife

-- 

Stefan Seyfried

"Dispatch war rocket Ajax to bring back his body!"