End of Sprint code check-in deadline approaches
Chris Wright
chrisw at redhat.com
Tue Jun 19 21:50:13 UTC 2012
* Jason Guiditta (jguiditt at 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
More information about the aeolus-devel
mailing list