On Fri, 12 Mar 2010, Jesse Keating wrote: >> I believe that we should build the infrastructure to support these policy >> changes first. >> >> As Spot eloquently pointed out, the number of users who are likely to help >> promote packages from testing to stable is currently a vanishingly small >> number. >> >> We must first solve this problem. When we are satisfied that we've got >> tools that significantly increase participation in updates-testing, then >> *and only then* should we change the policies around updates-testing. >> >> Which, to me, means "build improved updates-testing flow for F14, change >> policy starting with F15". >> >> My $0.02. >> >> --g > > Greg, it fully makes sense to build supporting infrastructure before > /enacting/ a policy. However, a policy is needed to guide the building > of said supporting infrastructure. In this case, I'm not sure I agree. The need -- to get more participants in the testing->update process -- is crystal clear, and completely independent of any policy changes. The policy could stay exactly the same, and the proposed tool, if properly built, would drive an order of magnitude more participation. > See numerous examples of release engineering proposing new policy and > changes, get approval for the change, build up the infrastructure to > support the change, and /then/ enact the change. It is quite difficult > to spend the time / energy to build up infrastructure for something that > may not be accepted in the first place. My point: we don't need to have a perfect policy in place to move, quickly and in parallel, on a project that is obviously valuable independently of the policy. I think it also allows us to hedge our bets a little bit. It's clear that there's still a lot of debate ahead regarding this policy change. I think it makes sense to give folks a big tactical win to embrace, while we continue to hash out the strategic questions. --g -- Educational materials should be high-quality, collaborative, and free. Visit http://opensource.com/education and join the conversation. _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
