What do we think of this?

[Toshio Kuratomi]

On Tue, 2007-03-27 at 14:14 -0400, Jesse Keating wrote:
> On Tuesday 27 March 2007 13:47:19 Greg Dekoenigsberg wrote:
> > Surely it's not in the interests of the 3rd party repos to contribute to
> > Fedora breakage.  Right?
> >
> > Is it *theroetically* possible to have a set of standards that unofficial
> > repos could follow to be less likely to break us?  And if so, what
> > prevents those standards from being created, and met?
> >
> > Maybe these are stupid questions -- but I like putting stupid questions on
> > the record.
> 
> Standards are great, and we can ask that of them, but since we don't allow our 
> name to be on it, and we aren't allowed to link to it in any way so long as 
> they hold non-legal software, we don't have much recourse for enforcement.
> 
> Add to that the implicit problem of two(or more) disconnected repositories.  
> When we push updates in Fedora, we can and do break deps in the 3rd party 
> repos.  They have to rebuild against what we're publishing as updates before 
> their deps are fixed.  For OUR repos, we can prepare all these builds before 
> pushing live so that the repos stay consistant.  External parties do not have 
> this luxury.  And I'm not about to run repoclosure on N+ 3rd party repos 
> before pushing out an update.

Here's where things could get interesting -- Can we make it easy for
third party repositories to stay informed of what dep-breaking packages
have been built and are waiting to be pushed to the repository?  Can we
make it easy for them to grab those packages and do a rebuild that waits
in the wings for our push to make the new package live?

And most importantly, how much work do they want to put into taking the
data we provide and turning it into something that helps them keep up to
date?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20070327/f26bced5/attachment.bin