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

[Samuel Verschelde]

(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