On Tue, Mar 5, 2013 at 11:30 PM, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
> Miloslav Trmač wrote:
>> We also propose to build up automated tests to verify the tier 1 and
>> tier 2 functionality, and use those tests on newly-built packages to
>> gate inclusion in rawhide.
>
> Please no! Extending the already painful red tape we have in stable releases
> to Rawhide will completely stall development!
I think this would require very little red tape; certainly not the
14-day wait that bodhi typically imposes.
If a new package doesn't break tests, it will tagged into rawhide
immediately or overnight - just like now. No extra work needed, no
change in workflow.
If a new package does break tier 1/2 tests, yes, the rawhide gate
requires a change in the workflow: the breakage must be fixed "now".
OTOH the breakage will have to be fixed _anyway_; the tests will make
it:
1) easier to spot (we wouldn't need to rely on manual testing)
2) easier to diagnose (we would know fairly precisely what has changed
between the working and broken version, and it would be a fairly small
set of packages)
3) much better for everyone else working within rawhide.
All of these should save time for everybody involved. Yes, the
rawhide gate may mean more work "now", but overall shouldn't require
extra work for package owners. (It may require extra work for
"Change" owners that implies updating the tests.)
> And it's all the more ridiculous that this is being proposed after we
> allowed the team for one of our most "core" components (Anaconda) to
> KNOWINGLY break its functionality in Rawhide, forcing a release slip.
I don't think there is any obvious reason to exempt anaconda from this
process. Of course, we start with zero tests, and thus also zero
requirements on anaconda; OTOH I expect somebody will propose to add a
test that "minimal network install should always be working" very soon
after the infrastructure is ready. Such a test would obviously apply
both to anaconda updates and to changes of everything else that may
break anaconda.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
