Mailinglist Archive: opensuse-buildservice (219 mails)

< Previous Next >
Re: [opensuse-buildservice] [opensuse-project] How should we inform packagers about new upstream versions?
  • From: Dirk Stoecker <opensuse@xxxxxxxxxxxx>
  • Date: Thu, 28 Feb 2008 09:53:03 +0100 (CET)
  • Message-id: <alpine.LNX.1.00.0802280943040.3230@xxxxxxxxxxxxxxxxx>
On Thu, 28 Feb 2008, Adrian Schröter wrote:

IMO the easiest option would be to use the %PACKAGER tag in the rpm
files for that ("rpm -q --qf '%{PACKAGER}\n' foobar" or "rpm -qi
foobar"), but it would require adding that feature to the OBS (or
rather, to build).

The problem with that was that people tend to mail the packagers directly
instead of using bugzilla. So, I personally fear that reports get duplicated
and not tracked in bugzilla anymore ..

You see this from you companies point of view, where bugzilla entries are a good thing. From my point of "community user" it is not (at least for minor topics like package upgrades). Why?

a) I have about 5 different bugzilla/bugtracker/xxx accounts (very likely much more, but these are the important ones). Each of these has slightly different usage, semantics, passwords, ...

b) When I get a mail it needs less than 5 minutes to answer it (for such easy topics). For bugtracking bug reports I need the 5 minutes at least to find login page, to find login data, to login, ...

c) For the reporter it is the same:
1) Creating an account, as usually anonymous reports are not allowed.
2) Finding the correct topic/target (can take several minutes).
3) Entering the report, verify, send.
Usually the will stop before point 1.

And all these efforts only for "Your package is not up-to-date. Version xxx has been released 3 weeks ago".

Better would be a button "package should be updated" on the download/search pages and a "status flag" in the and an email from the buildservice to the maintainers.

The maintainers can then decide, if a bug-entry in the bug-tracker is useful or if the update is done fast and without bug tracking.

-- (PGP key available)
< Previous Next >
Follow Ups