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