[Mageia-dev] How will be the realese cycle?

[Buchan Milne]

On Friday, 8 October 2010 16:30:42 andré wrote:
> Michael Scherer a écrit :
> > Le jeudi 07 octobre 2010 à 11:14 -0400, Greg Harris a écrit :
> >> I certainly agree, and mean no disrespect to you and other maintainers
> >> who generously contribute their time and energy. But the Mandriva
> >> implementation of backports is not a solution for those who want a
> >> continuously updated distro. It works for me and I appreciate that it's
> >> there. But if you are going to design a new and appealing alternative,
> >> the effort required to make backports really known and useful needs to
> >> be taken into account.
> > 
> > Well, that's a long running task. First, we have added meta data to
> > repository so we could design a better interface for the software ( ie,
> > how to detect that a packages is a backport and how to see a software is
> > a update, a test update, or something else ), then we need to implement
> > the soft, etc.
> > 
> > You spoke of having backport by default. We used to do it, but too much
> > people faced issue and complained. So we 1) said the truth, aka backport
> > didn't have the same rigorous testing 2) disabled it by default.
> > 
> > Now, if things change ( ie, if we have a process with more QA ), we can
> > change again.
> 
> Backports are definitely an area needing improvement.  Firstly, it is a
> bit awkward - especially with the waiting for Rpmdrake to process - to
> temporarily access backports.

I thought you could just select the backports dropdown? If not, maybe you 
should rather use 'urpmi --searchmedia Backports <packagename>'.

Anyway, this isn't an issue with the "release cycle" aspect, it is a UI/design 
problem in rpmdrake.

> And when I have, most of the time what I was interested in was not as up
> to date as the developper's site, if there was a backport for the
> application (or type of application) in question.

Was it up-to-date in cooker? If not, this is probably purely a man-power 
problem. If it was, did you request a backport? As I mentioned before, I think 
one shortcoming of backports was knowing what packages people were interested 
in having backported.

But, I know of many instances where backports were requested on IRC, and 
provided within under an hour (on the fast mirrors).

> Luckily, being a programmer, it is not problematic for me to compile and
> create menu entries, etc, if necessary.

There's no reason you should waste time that could be better spent. In some 
cases, pushing a backport takes all of 2 minutes.