RFC: Fedora revamp proposal

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/2013 11:47 AM, Kevin Fenzi wrote:
> On Tue, 5 Mar 2013 03:48:29 -0500 (EST) Jaroslav Reznik
> <jreznik at redhat.com> wrote:
> 
>> 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...
> 
> So, say I do the following:
> 
> - announce a week in advance that libfoo is going to break abi. -
> mail all the affected package maintainers that I will rebuild
> their packages. - test rebuilding locally and fix things. - push
> new libfoo to build against it in rawhide.
> 
> Then the new check says "Sorry, there's an ABI bump, fail"
> 
> How am I going to be able to tell it, 'yes, I know, but do it
> anyhow'
> 
> Then, when we answer that, whats to prevent people from just doing
> that without doing all the proper steps. ;)
> 
> I suppose one way would be to have the checker be the thing that 
> actually tags the package into f19 (or whatever). If it fails a
> test it doesn't move it over, but a koji admin could manually tag
> something in. That would lead to more work for releng tho.
> 
> We could leave the tag open (as it is now) and anyone could
> override and tag into f19, but then it's open for some abuse as
> someone might just do that when they shouldn't.
> 
> For released versions we could tie this check into bodhi I suppose.
>  Have it require a 'pass' from some set of tests before being
> allowed to go out as an update.
> 


Our original thoughts on this were that we would tie this to the
bodhi/repocreate phase of things. Basically, before each automatic
repocreate run in Rawhide, we would run the set of tier 1 and tier 2
acceptance tests. If any of them failed, we would send out emails to
the owners of any package that would have been pushed to the repo and
not push any of them.

Yes, it would be a manual step to update the tests to allow the push
to go through. I'm not going to deny the possibility that some people
might opt to bypass the process and just update the tests as they go.
We would prefer they did not (and if someone gets caught doing this
repeatedly, there are steps that can be taken), but it helps us to
avoid *unintentional* breakage, which is the hallmark of Rawhide at
this point.

It's worth noting that right now we are less than a week from Alpha
freeze for Fedora 19, and yet Rawhide is not installable. This is what
we would like to avoid.


> ...snip...
> 
>> Yep, it's really about the detail - that's why we have this
>> thread. In the beginning it can definitely cause slow downs...
> 
> Sure.
> 
>> 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...).
> 
> yeah, I don't know.
> 
> Perhaps someone could ask around and see if there's any
> projects/setups inside Red Hat that would be good for this? ABI
> checking and perhaps rpm diffing?
> 
> Also, do any of the folks working on AutoQA think it could be used
> for this? Or would they suggest a different framework?


When we drafted the proposal, our expectation was that AutoQA would be
a good fit here, mostly due to its current positioning within the
updates system. We reasoned that it would be a fit place to make the
gating decisions. If this proposal sees sufficient support and
approval, we will petition Red Hat for dedicated resources on AutoQA
(or whatever framework we settle on). We believe that an installable
Rawhide and more stable development platform is in the best interests
of Red Hat as well (Note: I am not speaking in an official capacity as
a Red Hat employee here; this is my view as a member of both communities).


> 
> I think we should definitely start small here and slowly work
> forward.
> 
> The hardest part will be getting the initial tooling in place.
> 
> (All this is assuming that this is a good idea that people want I 
> guess). ;)
> 
> kevin
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlE2JyIACgkQeiVVYja6o6Or6ACeIl6kaHJoJTiRICQxInja39Af
YeoAnjvfovFRvUg8ZnY10NRiOSDTGTtg
=+G30
-----END PGP SIGNATURE-----