End of Sprint code check-in deadline approaches

Michael Orazi morazi at redhat.com
Tue Jun 19 19:52:44 UTC 2012



----- Original Message -----
> On Tue, 19 Jun 2012 15:29:02 -0400, Jason Guiditta
> <jguiditt at redhat.com> wrote:
> > On 19/06/12 13:59 -0500, Steve Linabery wrote:
> > >On Tue, Jun 19, 2012 at 11:45:00AM -0500, Steve Linabery wrote:
> > >> Hello aeolus community developers,
> > >>
> > >> I would like to allow an additional day at the end of each
> > >> sprint for packaging work.
> > >>
> > >> I propose setting our deadline for pushing commits to 'master'
> > >> to close-of-business, Monday, 25 Jun 2012.
> > >>
> > >> We had a number of issues surface at the end of the last sprint
> > >> related to packaging and rpm-based installations. I would like
> > >> to budget some additional time pre-demo to catch and address
> > >> any such issues.
> > >>
> > >> Please speak up now if that deadline seems unreasonable or
> > >> unworkable.
> > >>
> > >> Thanks in advance,
> > >> Steve|eggmaster
> > >> Software Engineer   Red Hat, Inc.
> > >
> > >My apologies for the off-by-one (week) error.
> > >
> > >The actual code-pushed-to-master deadline is: close-of-business,
> > >Monday, 02 Jul 2012.
> > >
> > Phew, that seemed like an awfully short sprint.  I just returned
> > from
> > one week off, and it sounded like things were ending already!
> > 
> > Now, at the risk of starting (another) firestorm, I'd like to see
> > some
> > discussion here on this topic of when sprint ends vs when code is
> > pushed. Before I saw some controversial things here, let me outline
> > a
> > few assumptions wrt sprints and releases:
> > * A sprint encapsulates a list of features/tasks that will add a
> > chunk
> >    (big or small) of new functionality to one or more components of
> >    the
> >    project.
> > * The output of these tasks at the end of the sprint can (but will
> >    not always?) result in a community release.
> > * the community release is a tarball or zipfile, and can be
> > accessed
> >    by release tag on github at any time, with no extra work on our
> >    part
> >    (we need to get the link up for this, as I keep forgetting where
> >    to
> >    find it myself)
> > 
> > You may well disagree with even that, but I'll assume agreement
> > as a pre-requisite for my next thoughts. It seems to me that
> > cutting rpms
> > has absolutely nothing to do with any step in this process, and
> > can,
> > in fact be done at any time after a release.  I am in no way
> > suggesting releases should be untested, or just tossed into the
> > wild,
> > 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>.  Since many of us who use the
> > project issue tracking are, in fact responsible for this step, if
> > we
> > need to track work on package releases there (Redmine), I would
> > like
> > to propose a slightly different flow that woudl not impact the
> > community release, while still allocating resources to packaging.
> > 
> > 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.
> > 
> > -j
> 
> I am 100% in agreement.  Holy crap, what is happening?
> 

And we have a third.  Magic!

m




More information about the aeolus-devel mailing list