Re: Backports service becoming official
Hi!
* Simon McVittie <smcv@debian.org> [2010-09-06 19:33:34 CEST]:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> > What are the BTS limitations ?
>
> I assume the relevant limitation is that in the BTS' data model, each source
> package has a single maintainer, whereas the maintainer of a backport isn't
> necessarily anything to do with the maintainer of the original package (who'd
> end up receiving backport-specific bug reports, if using the BTS).
To me the solution is to see the person who does the backport as a part
of the packaging team. There is the need for having a communication
channel between the people anyway. Actually more and more packages are
moved into team maintenance and I'm pretty puzzled about the strong
objection on these grounds. And it would be very helpful for people that
store the packages in VCSes to have the backport changes in a seperate
branch so things won't get lost. It's IMHO the most natural thing to
do.[1][2][3]
[1] http://git.debian.org/?p=logcheck/logcheck.git;a=heads
[2] http://git.debian.org/?p=users/jgoerzen/bacula;a=heads
[3] http://git.deb.at/w/pkg/ejabberd.git/heads
Yes, more than often enough bugs that appear in the backport do also
apply to the package in testing, so claiming that heaven would fall onto
our heads is pretty much uncalled for. In the outrageous most times
packages on backports don't have any changes, at all, and the bugs that
are only relevant for the backports version can be reduced to not
adjusted dependencies.
I don't want to lie that bugs might not be backport specific. Just
recently the backport of iceweasel affected gnucash throug the new
libglib. This though was solved in close relationship with the involved
package maintainers and is thus a good example for how things can go
well.
So the only limitation that really should bother us is the version
tracking. But then, like said, most bugs aren't really backports
specific, so setting a found version to the version without the ~bpo.*
part of the version string is easy to do for the time being.
I really would like to see us trying to work together more effectively
instead of objecting to things right ahead without even knowing wether
it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
from it.
Of course, this is my private opinion and not enpowered with any hat or
role you might see me attached with these days. Even though I really
would wish that people would collaborate more.
Enjoy!
Rhonda
--
https://flattr.com/thing/47066/Debian-BTS-cleaning-up
Reply to: