Le samedi 11 juin 2011 18:01:54, Maarten Vanraes a écrit :
> Op zaterdag 11 juni 2011 16:55:00 schreef Samuel Verschelde:
> > Le samedi 11 juin 2011 14:26:19, Maarten Vanraes a écrit :
> > > Op zaterdag 11 juni 2011 13:14:29 schreef Samuel Verschelde:
> > > > Le samedi 11 juin 2011 12:06:55, Christiaan Welvaart a écrit :
> > > > > On Fri, 10 Jun 2011, Michael Scherer wrote:
> > > > > > We can agree that everybody want something newer for some rpms,
> > > > > > but few people want everything to be newer ( ie, now one run
> > > > > > backports as a update media, I think ). So as much as I am
> > > > > > against asking to users questions, we must show them the choice
> > > > > > somewhere, in a non obstrusive way.
> > > > >
> > > > > Maybe, but how would be "support" this? We must be able to
> > > > > reproduce a reported problem. This becomes complicated when we
> > > > > don't know what is installed on the user's system. A guideline for
> > > > > bug reporters is (or should be) "make sure you installed the
> > > > > latest updates". What would be the equivalent for backports? I'm
> > > > > afraid it should be "if you installed any backports, make sure you
> > > > > installed all backports that are relevant for your system". If
> > > > > someone has a problem with any other combination, the bug report
> > > > > might be rejected. How would QA even work when only selected
> > > > > packages are upgraded from backports, or integration testing:
> > > > > integration with what?
> > > > >
> > > > > So the only combinations we can support are:
> > > > > - release + updates
> > > > > - release + updates + backports
> > > > >
> > > > > More practical: for mga1 I have a VM that I can keep updated. For
> > > > > mga1 backports I can install another VM with backports enabled. But
> > > > > for bugs reported with only selected backports installed I suppose
> > > > > I would have to install a new VM with mga1, update it, and install
> > > > > only those backports -
> > > > >
> > > > > for each bug report. But maybe I'm missing something, please
> > > > > explain.
>
> (:
> > > > If we suppose that either updates or backports are supported (with a
> > > > support level to be defined), the situation is simpler to me : a
> > > > good backport must work with all its dependencies coming from
> > > > updates or release OR it must explicitly require higher versions,
> > > > found only in the backports media and so automatically pulled.
> > > >
> > > > So I don't think that having picked up only certain backported
> > > > packages is a problem for the maintainer's support. Maybe I
> > > > over-simplified the situation, but I don't think it will be as
> > > > complex as you say.
> > > >
> > > > Samuel
> > >
> > > imho this creates more work for packagers or qa team to support
> > > backports, i'm not really in favor of this solution
> >
> > So it someone has a problem with a package you backported and reports it
> > in bugzilla, you'll answer "not supported" and close the door ? Then we
> > have not a single chance to have users accept to use backports rather
> > than ask for a rolling release (supposing that we want to stay with
> > stable releases model, which hasn't been decided yet).
> >
> > In my opinion, a backport must be either supported or not exist. Even in
> > Mandriva, where everybody keep saying "backports ain't supported",
> > usually people try to solve the problems caused by backports.
> >
> > However, the level of support can be different between backports and
> > updates, as I said in my previous message. The differences are yet to
> > define, but here are some I see :
> > - when a critical bug in a backport exists, you can simply update to a
> > newer version and see if it's solved
> > - if the program already is in its the latest version and has an upstream
> > bug, you can answer "report the bug upstream" and stop there until
> > upstream solves the bug. For packages in release or updates, ideally you
> > have to try to help fixing it or work it around because the bug is
> > considered part of the whole distribution.
> >
> > Best regards
> >
> > Samuel
>
> What about security fixes? if there's 1 version in release and 10 in
> backports? do the older backported packages have to be securitypatched?
>
> imho not supported backports means that if backports has an issue, try a
> newer backports...
>
> imho that is a good level, that doesn't require much effort.
I think we agree, because if we follow the Mandriva way, upload of a new backport for a given package removes the old one if there is one. So at a given time, you only have to support the package in release or updates + 0 or 1 backport.
Samuel