'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: > On 9 June 2011 14:22, Oliver Burger <oliver....@googlemail.com> wrote: >> Dexter Morgan <dmorga...@gmail.com> schrieb am 09.06.2011 >> >>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <mag...@colin.guthr.ie> >>> wrote: >> >>>> I think updates would be the right place. >> >>> >> >>> Please no 3rd repo :) >> >>> But i agree with you for updates for "new" packages ( no "new" >> >>> versions ;) ) >> >> >> I would prefer using updates over backports as well. If we use backports we >> would get more problems then benefit (like people not having backports >> enabled or people having backports enabled and thus getting problems they >> can't handle e.g. with new kernels, graphic drivers and so on). >> >> >> Perhaps we could upload them to updates/testing for a really short qa before >> moving them to updates/ ? >> >> >> Oliver > > If it's pushed to /updates then it should be imported to the stable > release SVN tree; note that at some point Cauldron could get a newer > version than the one in /updates, and maybe it's not backportable, new > deps, regressions... etc. But now if there's a bug in the version in > the stable */updates, and it needs a patch, what are you gonna base > the patch on if you submit directly from the Cauldron SVN checkout to > */updates, and the Cauldron package has already changed? > > But if new package can go directly to updates.. that doesn't look > right to me, because at which point will "new" packages stop going to > a stable release */updates? if it goes on and on, then we're talking > about a semi-cauldron-like repo.
So just svn cp it to the /1/updates tree in svn and job's a good 'un. (well svn cp is no longer just one step due to source separation, but the principle is the same!). > Also note that a new package in Cauldron gets tested for a while > (depending at which point it was imported during the release cycle), > but if gets pushed to /updates and not backports (which is "not > supported"), that testing period is short-circuited. Yeah but then the examples I've got so far are: * trac * supybot * supybot-Meetbot * passwd-gen * dd_rescue In all these cases, these are packages I use. I will be testing them on that version of the distro. And when I don't use them every day, (e.g. passwd-gen, dd_rescue), they are pretty standard, stable and standalone apps. IMO we can over-analyse the "risk" factor here massive to the detriment of the overall offering. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]