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

Fri Oct 8 19:16:29 CEST 2010

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.
+
+