From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-June/005971.html | 134 +++++++++++++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-June/005971.html (limited to 'zarb-ml/mageia-dev/2011-June/005971.html') diff --git a/zarb-ml/mageia-dev/2011-June/005971.html b/zarb-ml/mageia-dev/2011-June/005971.html new file mode 100644 index 000000000..aaf90954b --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/005971.html @@ -0,0 +1,134 @@ + + + + [Mageia-dev] Firefox 5 + + + + + + + + + +

[Mageia-dev] Firefox 5

+ Ahmad Samir + ahmadsamir3891 at gmail.com +
+ Fri Jun 24 00:17:57 CEST 2011 +

+
+ +
On 23 June 2011 23:48, David W. Hodgins <davidwhodgins at gmail.com> wrote:
+> On Thu, 23 Jun 2011 15:52:30 -0400, Ahmad Samir <ahmadsamir3891 at gmail.com>
+> wrote:
+>
+>> On 23 June 2011 07:58, Dexter Morgan <dmorganec at gmail.com> wrote:
+>
+>>> yes it needs to go to backports_testing before iirc
+>
+>> Got a link to a thread on -dev ML / irc meeting log / <insert your
+>> favourite communication method here>, where this was decided?
+>
+> This mailing list, thread "Release cycles proposals, and discussion",
+> messageid BANLkTimrPR-=UgQOnfvAkqPft80LNi9seQ at mail.gmail.com
+>
+> Where Anne posted ...
+>
+>> exactly what I had in mind. Having backports can allow choice between
+>> "the last version of" and "the stable version with which I'm happy
+>> with". But indeed we need more quality in backport rpms that is policy
+>> and tests.
+>
+> In order for the qa team to perform the tests, before they go to the
+> backports repository, they have to go to to the testing repository
+> first.
+>
+
+1) It doesn't say "we're going to use backports_testing", does it?
+guessing != an instated policy
+2) IMHO, QA is too small to handle backports too
+
+> Something that works in cauldron may not work when moved to backports,
+> if a dependency is missed.  By using backports_testing, we can catch
+> that before it hits the average user.
+>
+> Regards, Dave Hodgins
+>
+
+Right so, the plan is:
+- A packager submits to backports_testing and assigns to QA
+- QA tests, the package is good to go
+- The report is assigned to <whoever has privileges to move packages
+from backports_testing to backports>, atm that's sysadm team
+- Package is moved and the report closed
+
+Caveats:
+- QA is too small, and it'll take time/effort to get through the
+backported packages requiring tests, unless you depend on the user
+asking for the backport to have tested the package properly, the user
+will say it works if it works on his box for the arch he's using, he
+won't do both archs, not just because he's lazy, but maybe he has one
+Mageia box for example
+- Sysadm team is already overworked with many other tasks, meaning the
+packages requiring a move will rot for a while in backports_testing.
+
+Now compare that to what's used in e.g. mdv:
+- User asks for a backport
+- Packager submits the backport and closes the report
+
+Do you see the problem I am talking about yet? adding more complexity
+to backporting may result in less backports; the more the hoops, the
+less the backports, the more the users' complaints about
+I-want-the-latest-version-of-foo-yesterday.
+
+The "quality of backports" is a sentence that lacks statistics and
+numbers; in e.g. mdv, how many packages were backported to release
+foo? how many of them worked(tm)? how many of them didn't work and
+required a bit of fixing? how many of them didn't work and won't work
+due to any number of reasons?
+
+I think backports in mdv worked pretty well all those years, not all
+of them worked, but most of them did.
+
+-- 
+Ahmad Samir
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1