F21 schedule: what would you do with more time?

[Dennis Gilmore]

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

On Thu, 22 Aug 2013 11:03:52 -0400
Matthew Miller <mattdm at fedoraproject.org> wrote:

> Based on discussion at Flock, on the devel mailing list, and in the
> FESCo meeting, we are looking for feedback on the idea of a longer
> release cycle for Fedora 21 -- not (right now at least) the bigger
> question of the 6-month cycle overall, but just, right now, slowing
> down for a release to get some things in order.
> 
> Specifically, both Release Engineering and QA have clear needs (and
> even plans for) greater automatiion, but are also incredibly busy
> simply doing the things they need to do _now_ to get the release out
> the door.
> 
> So, FESCo would like to see some specifics, like "If we had one week
> with nothing else to worry about, we could have automated generation
> and upload of cloud images" (to pick an example I personally care
> about). Or "with six months of overall delay, we could have
> continuous integration testing of a key subset of rawhide". Or "we
> could spend a couple of weeks and automate the new package and review
> workflow".
> 
> What Infrastructure projects would be helped by this? Web and design
> team, would slowing down the release focus allow time to work on, oh,
> say, getting the Wiki beautiful (or does it not matter)? What else?
> 
> As we look at Fedora.next ideas and possibly decide to start
> implementation in the F21 timeframe, we will likely find _new_ things
> that take specific work. Let's not worry about that right now. What
> things we do _now_ could be improved with the investment of some
> effort?

some of the things I would like to work on include, fully automating
the release process, today i have to do mutliple things from multiple
locations to trigger off the different pieces of the release. write a
tool like mash for pulling together the Live Spins and Images trees.
run pungi and mash inside of koji so that all parts of the release
compose process are done as koji tasks and make greater transparency on
what Release Engineering do.
get time to update all the documentation, and list out all the thoughts
in my brain and try to build a community around release engineering so
I don't have to work 60-80 hours a week just to try and keep up.

work on a composedb that gives easier insight into where things are in
the release cycles. where releases are in their cycle, i.e end of life,
stable or in development, for stable releases when updates where last
pushed, or if updates push is in progress, for in development, last
nightly compose, last milestone compose,  and if things are in progress.

ive probably missed a bunch of things here but thats a brief dump of
some of what ive been wanting to work on for ages and not had thetime
to do so.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlIWMXMACgkQkSxm47BaWffsKgCffKmZQCYcFT31N0Eday93+zFu
QTkAmwYqf9b2ZNMvW0sRY5iG5lK4u+dA
=GrLI
-----END PGP SIGNATURE-----