* Jason Guiditta (jguiditt(a)redhat.com) wrote:
but it seems we are entangling the upstream project with what our
packagers need to do in order to have a released pushed to fedora,
rhel, centos, <insert-distro-here>.
Decoupling upstream and its releases from a downstream distro packaging
step makes it easier for other distros to be involved. Goodness.
Arguably tasks such as those saying "As a Fedora 17 user..." are
packaging bugs, especially those that include SELinux policy, for
example. And perhaps this distinction would help make that clear.
1. Still have some kind of cutoff date for patches pushed to master.
Once that date is hit, we branch/tag and test the RC. Bug introduced
by new code that can be reasonably quickly fixed are pushed to master
and pulled onto the release branch. This is a potnetial can of wrms,
I realize, as we would have to be much more diligent to begin with in
our testing (public jenkins on openshift would go a long way toward
helping this), and we would have to be careful not to try to fix
_every_ bug that turns up, as they likely are not all caused by new
code. Existing bugs should be handled in standard process of
working on a sprint.
2. As part of the _next_ sprint, package up the release from the
previous sprint for whatever distros we wish to have packages for.
What actually makes it into those distros is entirely different than
what is released upstream, and is a separate conversation entirely,
imo. For instance, whether to only do bugfix release for a given
version of fedora, or to always push the latest aeolus release - this
decision is unrelated to the upstream release schedule.
I'm curious, why tie any packaging effort into upstream sprints at all?
thanks,
-chris