----- Original Message ----- > On Mon, 4 Mar 2013 20:35:08 +0100 > Miloslav Trmač <mitr@xxxxxxxx> wrote: > > On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer@xxxxxxxxx> > > wrote: > > ...snip... > > > >> Finally, the planning process will recognize the existence of > > >> these > > >> tiers by classifying each proposed change: > > >> > > >> * Changes to tiers 1 and 2: > > >> Strong recommendation that new stable APIs have new tests > > >> delivered at approximately the same time, if possible. This > > >> benefits change owners by diminishing the risk of accidental > > >> breakage of the functionality. Existing tests for the > > >> functionality must be updated at the same time as well. > > >> Waivers may be requested of FESCo. > > > > > > Are you envisioning the package maintainers to have to write > > > these > > > tests if they don't exist upstream? > > > > Yes. > > Are these tests that run as part of package build? > Or are we talking something like autoqa tests? Or ? The idea is autoqa (but those test run as part of package build could be part of it too). Yes, it means it will take a time to have a good set of tests and with autoqa support it's main problem I see but... > > > My personal opinion: > > > > * For UI and APIs, we want the things included in tier 2 to be > > sufficiently stable/tested, which probably means they should > > already > > have an upstream test suite; if they don't, and Fedora decides that > > they > > are important, Fedora should contribute an upstream test suite. > > > > * I expect that many "change" owners will find it worth their time > > to > > write a test - e.g. in the above example of Avahi it's one-time > > cost > > of writing a fairly simple test that will save manual checking and > > worry for the future. > > How is this gating to rawhide going to work? > > Or that's yet to be determined? > > While I like the idea overall, I think the devil will be in the > details > here. :) If we make the tests too strict, we are going to slow things > down, if we make them too manual we push more work on rel-eng, if we > don't make them strict enough, we have what we have today, but with > more red tape. Yep, it's really about the detail - that's why we have this thread. In the beginning it can definitely cause slow downs... >From tooling perspective - that's the question if we want to enhance our tools, step into other similar project (for collaboration with our downstreams? other distros...). Jaroslav > > kevin > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
