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-September/008496.html | 131 ++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-September/008496.html (limited to 'zarb-ml/mageia-dev/2011-September/008496.html') diff --git a/zarb-ml/mageia-dev/2011-September/008496.html b/zarb-ml/mageia-dev/2011-September/008496.html new file mode 100644 index 000000000..c7587f637 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-September/008496.html @@ -0,0 +1,131 @@ + + + + [Mageia-dev] Opening backports (was Re: [Mageia-sysadm] Using SQL database for youri) + + + + + + + + + +

[Mageia-dev] Opening backports (was Re: [Mageia-sysadm] Using SQL database for youri)

+ Samuel Verschelde + stormi at laposte.net +
+ Thu Sep 29 10:24:56 CEST 2011 +

+
+ +
(Forwarding to mageia-dev too as I mention a potential policy change as a 
+solution to speed up backports opening)
+
+(Summary from the sysadmin discussion: current settings don't allow per media 
+pre-submit checks, only per release. Boklm proposes a rewrite using a 
+database, which would be more flexible, but is, according to him, likely to 
+take several weeks. Another (very quick to do, unless I'm mistaken) solution 
+would be to always allow to submit from cauldron to updates_testing or 
+backports_testing, but it means that we would lose the current checking that 
+updates come from the 1/updates branch)
+
+Le mercredi 21 septembre 2011 16:46:53, nicolas vigier a écrit :
+> On Wed, 21 Sep 2011, Pascal Terjan wrote:
+> > On Wed, Sep 21, 2011 at 15:29, nicolas vigier <boklm at mars-attacks.org> 
+wrote:
+> > > We also have a problem with markrelease commits always done on the
+> > > cauldron directory, even for mageia 1 updates. Youri always run
+> > > markrelease on the cauldron directory because it doesn't know the URL
+> > > that was used for the submit, this URL is only known by create-srpm
+> > > which only uses it to generate the src.rpm, before sending the src.rpm
+> > > to youri.
+> > 
+> > How did it work for mandriva?
+> > I don't remember having such problem while backports came from cooker
+> > and updates from the branch
+> 
+> According to this :
+> http://svn.mandriva.com/viewvc/config/cluster/etc/repsys.conf?revision=1095
+> &view=markup they have this in repsys.conf :
+> [submit 2010.0]
+> allowed = svn+ssh://svn.mandriva.com/svn/packages/updates/2010.0
+> svn+ssh://svn.mandriva.com/svn/packages/cooker
+> svn+ssh://svn.mandriva.com/svn/packages/branches/cooker target =
+> /export/home/repsys
+> rpm-macros = global 2010.0
+> 
+> We can do the same. But this would allow someone to submit from cauldron
+> to 1/updates_testing.
+> 
+
+Given that the "full" solution is likely to take weeks with current sysadmin 
+resources and workload (no rant here, just a statement), I favor this 
+mandriva-like solution so that we don't wait any longer. I don't think there 
+will be major problems and I can make the QA team check each update candidate 
+in updates_testing to make sure it was submitted from the 1/updates branch and 
+not cauldron.
+
+Another quick solution would be to change the policy and have packagers submit 
+to backports from the 1/backports branch, like I (and several others) first 
+proposed during the policy discussion. This would require only a little change 
+to the configuration of the BS, unless I'm mistaken. AFAIK this solution was 
+first discarded as a means to "simplify", but it appears that with current 
+implementation it's harder to apply the "submit from cauldron" solution. The 
+drawback would be extra steps for packagers before submitting, but we can 
+workaround that easily with our extraordinary scripting powers, from client 
+side, and maybe even patches to mgarepo :)
+
+Could we go for one of those solutions (first one temporarily, or second one 
+definitively) ?
+
+Best regards 
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + +
+

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