Re: Care of your packages Was: Accepted dh-ocaml 0.4.1~bpo50+1 (source all)
Andres Salomon schrieb am Dienstag, den 02. Februar 2010:
Hi,
> > On Tuesday 02 February 2010 04:36:12 Andres Salomon wrote:
> [...]
> > > This is all imho, of course. I'd just personally prefer to not
> > > have to deal w/ moving targets when using lenny-backports on my
> > > stable machines.
> >
> > Okay .... so lets summarize this point. There maybe different
> > expectations from backports. Some people may want recent versions of
> > some packages and other people want anything between this and a
> > stable distibution. Personly I don't have a general preference, cause
> > this may depend on the specific package.
>
> Exactly, it would be good to get clarification regarding this point. It
> affects my usage of bpo, both as a (lenny) user, and as an uploader.
There is none possible.
At least not more than "Don’t backport minor version changes without any user
visible changes or bugfixes". I expect uploaders to use their brain:
- if your upload doesn't fix grave bugs, don't upload.
- if your upload does not have any additional benefit for the user - don't
upload.
- if your upload fixes important bugs - upload
- if your upload has interesting new features users are interested in or
asking for - upload
- if your upload fixes security problems - upload immediately.
If in doubt - don't upload or ask me or the users ml.
*snip*
> > Lets come back to the update on "an as-needed basis". This an good
> > example of the complete opposite what I did with dh-ocaml. I guess it
> > may be a result of missing tracking tools, but for both issues where
> > fixes available at least since december.
> > You can burn my at the pyre, but this is one of the major problems of
> > backporting. Uploaded packages with less or even without care (no,
> > I'm not talking about any special package).
> > Thanks Rhonda for doing the great security work of backports.org.
>
> I'll be the first to admit that I typically don't have time to track
> CVEs in my backported packages, nor in my sid/etch/lenny packages (the
> security team or someone else generally brings it to my attention).
> Given that, I typically encourage correctly-done NMUs and
> co-maintenance of packages. Tracking tools would be quite useful here,
> as well.
There is already Rhondas tracker and I expect uploaders to track the unstable
/ stable-security versions of a package (unless they are also the maintainer
in debian) and/or to react immediately after they get known of the security
problem (same as I expect that from any non-backports maintainer).
Don't know if this makes things clearer - but at least I hope so.
Alex
--
Alexander Wirt, formorer@formorer.de
CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A
Reply to: