End of Sprint code check-in deadline approaches

Jason Guiditta jguiditt at redhat.com
Tue Jun 19 19:29:02 UTC 2012


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



More information about the aeolus-devel mailing list