On Thursday, August 30, 2012 11:53:49 AM Stéphane Graber wrote: > > - Let's document what constitutes a respin and what doesn't, so that > > whenever we see a bug we all know if that is going to trigger a respin > > or not, let's create guidelines for it. > > I suppose we can do that, ultimately it's always going to be up to the > release team to do a go/no-go on case by case basis, but writting some > generic guidelines can't hurt.
I am personally a bit leary of attempting too much precision in this kind of documentation. I don't recall a respin that I thought was a mistake or one that, if test timeline was seen as a potential issue, there wasn't discussions about the chances of getting retesting done in a timely manner. If we try and be too specific about criteria then we're going to get rules lawyers complaining we didn't follow the criteria rather than applying common sense. I see this happening with Feature Freeze exceptions, so I'm not concerned about this at random. As long as it's general guidelines to give a broad expectation about what's likely to happen, I think it's fine. If it's seen as an exclusive list of conditions, then people will start to argue about if something matches the respin criteria list and not focus on if the respin makes sense. Scott K -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
