On Thu, 21 Jun 2001, Vincent Danen wrote:
> > > 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.
> I don't see how this will help. Security/bugfix updates are not
> "open" packages or "public" packages until they are published. In
> many cases, non-public bugs (security) are being fixed... making this
> available to cooker will cause us serious problems with other vendors.
> If anyone is sincerely interested in helping to beta test updates that
> make their way into rpmdrake, then please send me a note and we'll see
> if you qualify for our small secteam.
> Cooker is not updates, and vice versa. I typically update cooker
> *after* the updates for this same reason (non-disclosure until
> vulnerabilities are public). I'm sure you can appreciate this.
Sure, but there's still the issue that triggered this thread: an update
was built on Jun 4 but not released immediately (understandably), a new
bug+fix was reported on Jun 10 (and several subsequent occasions) and
received absolutely no response. There was (AFAIK) no way for me or
anyone else to know that anyone was doing anything about kdelibs2.1.2 -
even a short message such as "kdelibs 2.1.2-3mdk has entered QA and will
be in updates soon" with no other details would have helped because I
would then have waited for the release of the new build to see if the
issue had already been resolved.
Michael
