On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > On 29 January 2014 15:49, inode0 <inode0@xxxxxxxxx> wrote: >> On Wed, Jan 29, 2014 at 4:39 PM, Jon <jdisnard@xxxxxxxxx> wrote: >> > Putting on my rel-eng hat I can say that any spin that fails to >> > compose will be dropped. >> > >> > I believe we also encourage or even require the spin maintainers to >> > test their spin as functional. >> > (To work out if the spin succeeds to compose but fails to actually work) >> > >> > The idea is to encourage active spin process, inactive spins will auto >> > retire by policy if they fail. >> > >> > Another aspect I worry about is the mirroring stuff. >> > With the coming WGs I fear the rsync mirroring will grow very large, >> > and spins are an attractive piece of fat to cut. >> >> You probably didn't mean for that to sound so negative but a piece of >> fat to cut is how rel-eng thinks of spins? >> >> I recall being assured at the beginning that some interested company >> was willing to provide the necessary support for us to give this a >> fair try. >> > > How long is a fair try? It would help to define that before people go on a > rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. On the resources question we can either ask for them in order to allow us to do both or we can look for new ways to reduce the cost of spins to those complaining about the burden they impose. I'm open to either of those approaches. Getting rid of them to me would be an admission that are unwilling or unable to continue supporting something that is valuable to our users and our community (just my subjective opinion and I know not everyone shares it). John -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
