Le vendredi 10 juin 2011 10:56:35, Colin Guthrie a écrit : > 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble: > > On 9 June 2011 14:22, Oliver Burger <[email protected]> wrote: > >> Dexter Morgan <[email protected]> schrieb am 09.06.2011 > >> > >>> On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie <[email protected]> > >>> > >>> 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
I agree with Colin here. Samuel
