2009/4/7 Adam Williamson <awilliam@redhat.com>
On Mon, 2009-04-06 at 17:28 -0400, Ignacio Vazquez-Abrams wrote:
> On Mon, 2009-04-06 at 14:19 -0700, Adam Williamson wrote:
> > On Mon, 2009-04-06 at 14:18 -0700, Adam Williamson wrote:
> > > FWIW I wrote something similar, but much more wordy and blathery, in the
> > > context of Ubuntu's PPAs, back when I was at MDV:
> >
> > The preceding mail nicely illustrates the dangers of the ctrl-enter
> > keybinding when trying to insert a couple of line feeds and immediately
> > afterwards paste the URL...
> >
> > http://www.happyassassin.net/2007/10/24/mistakes/
>
> Interesting. Perhaps you should make your concerns known to anyone that
> will be implementing KoPeR then:
>
> http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos

There's some key differences there. As the description and use cases
make clear, the point of KPR is basically to make it easier to do what
maintainers already in practice do today - use Koji scratch builds to
test potentially dangerous changes ahead of committing them to Rawhide
(or just test them quickly and avoid Rawhide's 24 hour turnaround).

Key points: the use cases (which all follow this pattern), the "work
flow" (note at the end "Bob commits his gtk2 changes to package SCM and
does a normal koji build") and - most importantly - the fact that KPRs
will only be available to Fedora maintainers, not to just about anyone
who signs up for one (as is the case for PPAs).

I do think that if anyone intended to use KPRs in a 'permanent' way,
that would be a bad idea, for the reasons given in my post.

Would a valid use case for a KPR be say the intrepid Mono SIG providing a test bed for backported updated to the Mono stack to facilitate a smooth experience without disturbing updates-testing where we might want to have more immediate bugfixes flowing into which should not be held up by what might grow to be a lenghty period of testing the full stack or is there another preferred way to do such things?

- David