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. 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. Just my 0.002€ -- Ahmad Samir
