----- Original Message -----
On Tue, 19 Jun 2012 15:29:02 -0400, Jason Guiditta
<jguiditt(a)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