On Thu, 21 Jun 2001, Vincent Danen wrote:
> > > QA process is not a 24hr deal... =) It sometimes takes a little bit
> > > longer, and kdelibs is a big package that needs thorough testing
> > > (this isn't cooker we're talking about!). So the delay is not in
> > > mirroring, but in QA. We could do it faster and not as thorough, but
> > > then we'd be doing it over again many more times, I'm sure.
> > OK, that makes sense, but how about releasing the packages to cooker as
> > soon as they are built and then releasing as updates once QA is complete?
> > That way, everyone knows when an update is being worked on and you also
> > benefit from extra testing.
> I just checked, and kdelibs in cooker is 2.2-0.alpha2... I don't know
> how we can get kdelibs 2.1.2 into cooker without causing even more
> problems... =) Remember, cooker moves fast and usually has the latest
> and greatest... versions that we support in updates cannot always use
> cooker as a vehicle for testing.
Into unsupported (instead of cooker), then into updates after QA passed?
Failing this, maybe updates should be announced on the cooker ML when they
enter QA, so that bug-hunters are aware that a new build exists.
Michael
