-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/08/2013 11:23 AM, Kevin Fenzi wrote:
ok, so I finally sat down and looked at this some more...
But I'm still not sure I understand what you are proposing. ;)
Assuming base is releasing every 6 months, we make a 1.0pr1 against
f21 base, then a 1.0pr2 against f22 base, then a final 1.0 against
f23 base.
How is server 1.1 made? Do we not need to make security updates or
other changes to base? Or we only take the f23 base and use it for
the rest of 1.x's life?
My view was that we'd maintain F23's base for 1.x's life (and yes, I'm
aware that becomes trickier the longer it goes on).
What repo(s) does server use in this model?
Plenty of room to discuss that, I suppose. We could follow the RHEL
model of a separate repo containing both Base and Server or we could
have a repo for F23Base and FServer1.x
We wouldn't be releasing a 1.0 version for 12 months? I think
thats
the opposite of 'agile' ;)
There's a very big difference between an agile process and a fast
release schedule. That being said, we could have a discussion on
possibly truncating the 1.0 schedule such that we skip directly to the
stable, maintained release and then start the described lifecycle from
there (essentially taking Máirín's document and just shifting Base by
two versions.
That assumes of course that we are comfortable with the maintenance
releasing that way.
Also, I am not liking the release after base idea. We already
'freeze' for releases so we can get everything in a testable state.
If we do so, then release base, it becomes a moving target so
regressions can land when we are trying to test server.
Sure, I was mostly trying to account for possible dependencies. My
real intent was that we should stay as close to Base as possible, but
if the actual release required extra time, not to shoehorn us in there.
The shorter version of what I was trying to say there is this: "Base
blocks Server, but Server doesn't necessarily block Base". Is that
more clear?
I don't think we can do a increased lifecycle unless base also
supports that personally.
That's a conversation to have with the Base WG, I suppose.
I have some alternate ideas, will post in another thread. ;)
I await your thoughts with bated breath.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlJ9IUsACgkQeiVVYja6o6MQeACgrSPY3Y3BhLVLHABbqpCa3IIl
4acAn3wsDVvUSoqOIyuGp8P9HfDniQ+x
=+pYJ
-----END PGP SIGNATURE-----