<div class="gmail_quote">2009/4/7 Adam Williamson <<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">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... > > > > <a href="http://www.happyassassin.net/2007/10/24/mistakes/" target="_blank">http://www.happyassassin.net/2007/10/24/mistakes/</a> > > Interesting. Perhaps you should make your concerns known to anyone that > will be implementing KoPeR then: > > <a href="http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos" target="_blank">http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos</a> </div>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.</blockquote><div> 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 </div></div>