"Tick-tock" release cadence?

[Dennis Gilmore]

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

On Mon, 8 Dec 2014 02:29:17 +0000
Peter Robinson <pbrobinson at gmail.com> wrote:

> On Thu, Dec 4, 2014 at 6:42 PM, Matthew Miller
> <mattdm at fedoraproject.org> wrote:
> > On Thu, Dec 04, 2014 at 11:02:28AM -0600, Bruno Wolff III wrote:
> >> >For us, that would mean alternating between concentrating on
> >> >release features and on release engineering and QA process and
> >> >tooling. During the "tick", we'd focus on new features and
> >> >minimize unrelated rel-eng change. During the "tock", we'd focus
> >> >on the tools, and minimize change that might affect that.
> >> Presumably we wouldn't need to do this even up. We want say 2 to 1
> >> or 3 to 1.
> >
> > A waltz beat, say. :)
> >
> >
> >
> >> >* prevent compounded delays caused by intersection of feature
> >> >needs
> >> >  and releng changes
> >> There was a bit of that this time. But this was a really big
> >> change. Are you thinking we will have this scale of change for
> >> releng on a regular basis?
> >
> >
> > So, frankly — and I think the rel eng team won't be offended here,
> > because they know it more than anyone! — we're beyond what the
> > current releng overall design can really scale to, and it needs an
> > order of magnitude _more_ work in order to allow us to keep
> > growing. (And that's not just with the Fedora.next stuff or new
> > things like Atomic — the sheer _size_ means composes are going to
> > take more than 24 hours in the forseeable future.)
> 
> No offence taken but it does depend on a number of things, some out of
> our control. We're working to be able to parallelise a bunch of the
> process but part of that isn't fixable with code alone. Parts are
> being improved with more human resources for time (like me) and some
> is due to things like IO on infrastructure.

None taken here either, I want to get to a point where the human cost
to doing a compose is next to nothing. but that does involve massive
amounts of work and the turn around time will depend on things like
network speed, storage speed, etc. but there is a high change
turnaround could be over 24 hours as we make more and more things.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUheJrAAoJEH7ltONmPFDREAkP/06kRYWtY5TdijxjEWX9YEem
24lmf56e00DI3EzGGn8g/2QmP7re4z8r18pRdMiP5QnicesH9AMxTFgBzg+kmQG5
Vspp40f9A6JrvQWucc3GwIi8NAj+pyK7/CQkOORKWe3VSr9qi4DP/De3OpHUV2ma
S1bHFQPQYs+FFGqqPzDi3qCak0UERWLefCSGu1EvYuNSvATxDkvSK2DynejO9V6c
jOID2Wxx566vnfjvjSMlfRXbM/NaZDiYNA7RrE84vFvnkkM5XMhdRiuC06sVxG+A
2ma3XyykzCnnP9HXYQynX/GITQUHJGgJlqWEoQ9Z5E6KU7YOmLrYQNCliwn7YuUr
PJw/iPIsnoq3L4soLZ26yzEy6qAwi3re7PcXslETIMFd9Db1a2NAUO/H2212/Emm
58BlkT7JEqVtIOtuLdbe+fyLYEzwTnvsC2iZrf8+L7NRFcghOBB9QbGzTSBNhNPG
DdjF0QYkCfpdPSeoUwVHvphcze6ZtCcHffIppGKPdBLX4c3+EVmkwhJd7hGovP6h
FRlaY2mSVtAI1tVY9s1LJJBFj6rdATM2MEiEZFyOFQf8tTA16fZ2WJxdoJDnQO3M
az/xVO06lqWYYfSfdr1pq5lhX9EUEs1L5JXG+qpoImIyC0X4M0+kV2RLxhv85TUM
lEp6xhn2MKfhkiAUhwV+
=hbQD
-----END PGP SIGNATURE-----