With foreman-1.8 being pushed out a couple weeks and katello-2.2 lining up well with that, I'd like to propose that it's time to "cross the streams"[1]. Can we, starting with these releases not after, make it a requirement that foreman and katello release together?
Satellite-6, the downstream Red Hat product, is dependent on these two once-separate projects working perfectly together. Neither the upstream community nor the Red Hat developers on the projects benefit from the current disjoint work pattern that exists currently. A lot of time is spent unnecessarily trying to compensate for the lack of coordination.
As @ehelms wrote[2] a few days back there are some areas that still need to be tackled, but I believe that really pooling resources could address them more quickly. Specifically, getting katello installable on an existing foreman would greatly benefit everyone. It would also get done sooner if both teams made it a joint priority.
As a unified community of developers perhaps we can address these issues with some finality and move on to greater success.
Since many emails go unanswered until something actually starts to happen, consider this starting to happen and speak up please! I, as a very interested party, will be lobbying for some movement on this delayed topic. (The topic is largely a rehash of initial meetings 18 months ago.)
Hope to hear from other devs!
Tom
[1] http://en.wikipedia.org/wiki/Proton_pack#Crossing_the_streams
There's something very important I forgot to tell you! Don't cross the streams… It would be bad… Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
— Egon Spengler (Harold Ramis) on crossing proton streams
–
“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle
“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School
Perhaps the first step is to get all of the "core" and "optional" packages into yum.theforeman.org[1]? Or is the precursor to decide what is considered core and optional? Ideally it would be great to have a reference table of package versions (with links to github branch/tag?) with each release. Is there a list somewhere of what repos we would version ourselves versus what we consume from external community projects? (eg. since apipie[2] is something we version and distribute, could we sync releases with it to insure compatibility?)
···
----- Original Message -----
>
> With foreman-1.8 being pushed out a couple weeks and katello-2.2 lining up
> well with that, I'd like to propose that it's time to "cross the
> streams"[1]. Can we, starting with these releases not after, make it a
> requirement that foreman and katello release together?
>
> Satellite-6, the downstream Red Hat product, is dependent on these two
> once-separate projects working perfectly together. Neither the upstream
> community nor the Red Hat developers on the projects benefit from the
> current disjoint work pattern that exists currently. A lot of time is spent
> unnecessarily trying to compensate for the lack of coordination.
>
> As @ehelms wrote[2] a few days back there are some areas that still need to
> be tackled, but I believe that really pooling resources could address them
> more quickly. Specifically, getting katello installable on an existing
> foreman would greatly benefit everyone. It would also get done sooner if
> both teams made it a joint priority.
>
> As a unified community of developers perhaps we can address these issues with
> some finality and move on to greater success.
>
> Since many emails go unanswered until something actually starts to happen,
> consider this starting to happen and speak up please! I, as a very
> interested party, will be lobbying for some movement on this delayed topic.
> (The topic is largely a rehash of initial meetings 18 months ago.)
>
> Hope to hear from other devs!
>
> Tom
>
>
>
> [1] http://en.wikipedia.org/wiki/Proton_pack#Crossing_the_streams
> There's something very important I forgot to tell you! Don't cross the
> streams… It would be bad… Try to imagine all life as you know it
> stopping instantaneously and every molecule in your body exploding at
> the speed of light.
> — Egon Spengler (Harold Ramis) on crossing proton streams
>
> [2] https://groups.google.com/forum/#!topic/foreman-dev/ScS415TWRvQ
>
>
> --
> @thomasmckay
>
> --
> "The leader must aim high, see big, judge widely, thus setting himself apart
> form the ordinary people who debate in narrow confines." ~ Charles De Gaulle
>
> "Leadership is about making others better as a result of your presence and
> making sure that impact lasts in your absence." ~ Harvard Business School
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Informal discussions on this seem in favor of something like this (sync'ing releases). Speak up if you have thoughts on pros/cons.
···
----- Original Message -----
>
>
> ----- Original Message -----
> >
> > With foreman-1.8 being pushed out a couple weeks and katello-2.2 lining up
> > well with that, I'd like to propose that it's time to "cross the
> > streams"[1]. Can we, starting with these releases not after, make it a
> > requirement that foreman and katello release together?
> >
> > Satellite-6, the downstream Red Hat product, is dependent on these two
> > once-separate projects working perfectly together. Neither the upstream
> > community nor the Red Hat developers on the projects benefit from the
> > current disjoint work pattern that exists currently. A lot of time is spent
> > unnecessarily trying to compensate for the lack of coordination.
> >
> > As @ehelms wrote[2] a few days back there are some areas that still need to
> > be tackled, but I believe that really pooling resources could address them
> > more quickly. Specifically, getting katello installable on an existing
> > foreman would greatly benefit everyone. It would also get done sooner if
> > both teams made it a joint priority.
> >
> > As a unified community of developers perhaps we can address these issues
> > with
> > some finality and move on to greater success.
> >
> > Since many emails go unanswered until something actually starts to happen,
> > consider this starting to happen and speak up please! I, as a very
> > interested party, will be lobbying for some movement on this delayed topic.
> > (The topic is largely a rehash of initial meetings 18 months ago.)
> >
> > Hope to hear from other devs!
> >
> > Tom
> >
> >
> >
> > [1] http://en.wikipedia.org/wiki/Proton_pack#Crossing_the_streams
> > There's something very important I forgot to tell you! Don't cross the
> > streams… It would be bad… Try to imagine all life as you know it
> > stopping instantaneously and every molecule in your body exploding at
> > the speed of light.
> > — Egon Spengler (Harold Ramis) on crossing proton streams
> >
> > [2] https://groups.google.com/forum/#!topic/foreman-dev/ScS415TWRvQ
> >
> >
> > --
> > @thomasmckay
> >
> > --
> > "The leader must aim high, see big, judge widely, thus setting himself
> > apart
> > form the ordinary people who debate in narrow confines." ~ Charles De
> > Gaulle
> >
> > "Leadership is about making others better as a result of your presence and
> > making sure that impact lasts in your absence." ~ Harvard Business School
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> Perhaps the first step is to get all of the "core" and "optional" packages
> into yum.theforeman.org[1]? Or is the precursor to decide what is considered
> core and optional? Ideally it would be great to have a reference table of
> package versions (with links to github branch/tag?) with each release. Is
> there a list somewhere of what repos we would version ourselves versus what
> we consume from external community projects? (eg. since apipie[2] is
> something we version and distribute, could we sync releases with it to
> insure compatibility?)
>
> [1] http://yum.theforeman.org/releases/
> [2] https://github.com/Apipie/apipie-rails
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
How do we do it though? The release strategies are different:
Foreman - release when enough stuff has built up - about every 3 months
Katello - release when features are done
I would prefer Katello releases not be bound by having a full set of X,
Y, and Z features. Finish X and Y and RC/GA within a day or two of
Foreman - "Z" can be done later.
Release early, release often would get features lots more exposure to a
wider base before Red Hat consumes it in Satellite, and gives the
Foreman community cool new Katello things to play with much more often.
···
On Thu, Jan 22, 2015 at 08:51:59AM -0500, Tom McKay wrote:
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > >
> > > With foreman-1.8 being pushed out a couple weeks and katello-2.2 lining up
> > > well with that, I'd like to propose that it's time to "cross the
> > > streams"[1]. Can we, starting with these releases not after, make it a
> > > requirement that foreman and katello release together?
> > >
> > > Satellite-6, the downstream Red Hat product, is dependent on these two
> > > once-separate projects working perfectly together. Neither the upstream
> > > community nor the Red Hat developers on the projects benefit from the
> > > current disjoint work pattern that exists currently. A lot of time is spent
> > > unnecessarily trying to compensate for the lack of coordination.
> > >
> > > As @ehelms wrote[2] a few days back there are some areas that still need to
> > > be tackled, but I believe that really pooling resources could address them
> > > more quickly. Specifically, getting katello installable on an existing
> > > foreman would greatly benefit everyone. It would also get done sooner if
> > > both teams made it a joint priority.
> > >
> > > As a unified community of developers perhaps we can address these issues
> > > with
> > > some finality and move on to greater success.
> > >
> > > Since many emails go unanswered until something actually starts to happen,
> > > consider this starting to happen and speak up please! I, as a very
> > > interested party, will be lobbying for some movement on this delayed topic.
> > > (The topic is largely a rehash of initial meetings 18 months ago.)
> > >
> > > Hope to hear from other devs!
> > >
> > > Tom
> > >
> > >
> > >
> > > [1] http://en.wikipedia.org/wiki/Proton_pack#Crossing_the_streams
> > > There's something very important I forgot to tell you! Don't cross the
> > > streams… It would be bad… Try to imagine all life as you know it
> > > stopping instantaneously and every molecule in your body exploding at
> > > the speed of light.
> > > — Egon Spengler (Harold Ramis) on crossing proton streams
> > >
> > > [2] https://groups.google.com/forum/#!topic/foreman-dev/ScS415TWRvQ
> > >
> > >
> > > --
> > > @thomasmckay
> > >
> > > --
> > > "The leader must aim high, see big, judge widely, thus setting himself
> > > apart
> > > form the ordinary people who debate in narrow confines." ~ Charles De
> > > Gaulle
> > >
> > > "Leadership is about making others better as a result of your presence and
> > > making sure that impact lasts in your absence." ~ Harvard Business School
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "foreman-dev" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to foreman-dev+unsubscribe@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> >
> > Perhaps the first step is to get all of the "core" and "optional" packages
> > into yum.theforeman.org[1]? Or is the precursor to decide what is considered
> > core and optional? Ideally it would be great to have a reference table of
> > package versions (with links to github branch/tag?) with each release. Is
> > there a list somewhere of what repos we would version ourselves versus what
> > we consume from external community projects? (eg. since apipie[2] is
> > something we version and distribute, could we sync releases with it to
> > insure compatibility?)
> >
> > [1] http://yum.theforeman.org/releases/
> > [2] https://github.com/Apipie/apipie-rails
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "foreman-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to foreman-dev+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> Informal discussions on this seem in favor of something like this (sync'ing releases). Speak up if you have thoughts on pros/cons.
>>
>>>
>>>> With foreman-1.8 being pushed out a couple weeks and katello-2.2 lining up
>>>> well with that, I'd like to propose that it's time to "cross the
>>>> streams"[1]. Can we, starting with these releases not after, make it a
>>>> requirement that foreman and katello release together?
>>>>
>>>> Satellite-6, the downstream Red Hat product, is dependent on these two
>>>> once-separate projects working perfectly together. Neither the upstream
>>>> community nor the Red Hat developers on the projects benefit from the
>>>> current disjoint work pattern that exists currently. A lot of time is spent
>>>> unnecessarily trying to compensate for the lack of coordination.
>>>>
>>>> As @ehelms wrote[2] a few days back there are some areas that still need to
>>>> be tackled, but I believe that really pooling resources could address them
>>>> more quickly. Specifically, getting katello installable on an existing
>>>> foreman would greatly benefit everyone. It would also get done sooner if
>>>> both teams made it a joint priority.
>>>>
>>>> As a unified community of developers perhaps we can address these issues
>>>> with
>>>> some finality and move on to greater success.
>>>>
>>>> Since many emails go unanswered until something actually starts to happen,
>>>> consider this starting to happen and speak up please! I, as a very
>>>> interested party, will be lobbying for some movement on this delayed topic.
>>>> (The topic is largely a rehash of initial meetings 18 months ago.)
>>>>
>>>> Hope to hear from other devs!
>>>>
>>>> Tom
>>>>
>>>>
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Proton_pack#Crossing_the_streams
>>>> There's something very important I forgot to tell you! Don't cross the
>>>> streams… It would be bad… Try to imagine all life as you know it
>>>> stopping instantaneously and every molecule in your body exploding at
>>>> the speed of light.
>>>> — Egon Spengler (Harold Ramis) on crossing proton streams
>>>>
>>>> [2] https://groups.google.com/forum/#!topic/foreman-dev/ScS415TWRvQ
>>>>
>>>>
>>>> –
>>>> @thomasmckay
>>>>
>>>> –
>>>> "The leader must aim high, see big, judge widely, thus setting himself
>>>> apart
>>>> form the ordinary people who debate in narrow confines." ~ Charles De
>>>> Gaulle
>>>>
>>>> "Leadership is about making others better as a result of your presence and
>>>> making sure that impact lasts in your absence." ~ Harvard Business School
>>>>
>>>> –
>>>> You received this message because you are subscribed to the Google Groups
>>>> "foreman-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> Perhaps the first step is to get all of the "core" and "optional" packages
>>> into yum.theforeman.org[1]? Or is the precursor to decide what is considered
>>> core and optional? Ideally it would be great to have a reference table of
>>> package versions (with links to github branch/tag?) with each release. Is
>>> there a list somewhere of what repos we would version ourselves versus what
>>> we consume from external community projects? (eg. since apipie[2] is
>>> something we version and distribute, could we sync releases with it to
>>> insure compatibility?)
>>>
>>> [1] http://yum.theforeman.org/releases/
>>> [2] https://github.com/Apipie/apipie-rails
>>>
>>> –
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> Informal discussions on this seem in favor of something like this (sync'ing releases). Speak up if you have thoughts on pros/cons.
> How do we do it though? The release strategies are different:
>
> Foreman - release when enough stuff has built up - about every 3 months
> Katello - release when features are done
>
> I would prefer Katello releases not be bound by having a full set of X,
> Y, and Z features. Finish X and Y and RC/GA within a day or two of
> Foreman - "Z" can be done later.
I think katello should be bound by the foreman release cycle. If larger
features aren't fully complete, release anyways. Nothing should be
going into master that a) doesn't work and b) doesn't stand on its own
(in some way). So i don't think there is any harm in this.
-Justin
···
On 01/22/2015 09:30 AM, Stephen Benjamin wrote:
> On Thu, Jan 22, 2015 at 08:51:59AM -0500, Tom McKay wrote:
>> ----- Original Message -----
>>> ----- Original Message -----
>
> Release early, release often would get features lots more exposure to a
> wider base before Red Hat consumes it in Satellite, and gives the
> Foreman community cool new Katello things to play with much more often.
>
>
> --
> Best Regards,
>
> Stephen Benjamin
> Red Hat Engineering
>
>
>
> How do we do it though? The release strategies are different:
>
> Foreman - release when enough stuff has built up - about every 3 months
> Katello - release when features are done
>
This is not entirely true. While we have lagged, the target of 2.0 and 2.1
has been to release within 2weeks to a month of when Foreman releases
(there are reasons we haven't achieved this yet). Since we are following
the Foreman release, we aren't releasing completely finished features.
Personally, I prefer feature based releases, but as long as we get the
workflow worked out I don't mind the timed releases.
> I would prefer Katello releases not be bound by having a full set of X,
> Y, and Z features. Finish X and Y and RC/GA within a day or two of
> Foreman - "Z" can be done later.
>
> Release early, release often would get features lots more exposure to a
> wider base before Red Hat consumes it in Satellite, and gives the
> Foreman community cool new Katello things to play with much more often.
>
>
We release every night - that's often But really, releasing incomplete
features doesn't, in my mind, serve anyone. I think a balance is required
to pick the set of features that make sense, get you a timely release and
then act on those and release. Rinse and repeat.
As for coordinating releases, I think you may need to clarify Tom. The
Katello devs intend to follow the 1.8 cycle of branching and release for
2.2. I am assuming your intent is to gather support for and change the
workflow to require mutual assured releases. In other words, they only
release when both are green lit.
Eric
···
>
> --
> Best Regards,
>
> Stephen Benjamin
> Red Hat Engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>> I think katello should be bound by the foreman release cycle. If larger
> features aren't fully complete, release anyways. Nothing should be going
> into master that a) doesn't work and b) doesn't stand on its own (in some
> way). So i don't think there is any harm in this.
>
>
Given the above, why do versioned releases like we do then? Nightly
represents master, so there are releases every night. Let's just say we do
continuous delivery and call it a day
Eric
···
> -Justin
>
>
>> Release early, release often would get features lots more exposure to a
>> wider base before Red Hat consumes it in Satellite, and gives the
>> Foreman community cool new Katello things to play with much more often.
>>
>>
>> --
>> Best Regards,
>>
>> Stephen Benjamin
>> Red Hat Engineering
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> I think katello should be bound by the foreman release cycle. If
> larger features aren't fully complete, release anyways. Nothing
> should be going into master that a) doesn't work and b) doesn't
> stand on its own (in some way). So i don't think there is any
> harm in this.
>
>
> Given the above, why do versioned releases like we do then? Nightly
> represents master, so there are releases every night. Let's just say
> we do continuous delivery and call it a day
>
Stability
···
On 01/22/2015 09:42 AM, Eric D Helms wrote:
Eric
-Justin
Release early, release often would get features lots more
exposure to a
wider base before Red Hat consumes it in Satellite, and gives the
Foreman community cool new Katello things to play with much
more often.
--
Best Regards,
Stephen Benjamin
Red Hat Engineering
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
> >
> >
> > How do we do it though? The release strategies are different:
> >
> > Foreman - release when enough stuff has built up - about every 3 months
> > Katello - release when features are done
> >
>
> This is not entirely true. While we have lagged, the target of 2.0 and 2.1
> has been to release within 2weeks to a month of when Foreman releases
> (there are reasons we haven't achieved this yet). Since we are following
> the Foreman release, we aren't releasing completely finished features.
> Personally, I prefer feature based releases, but as long as we get the
> workflow worked out I don't mind the timed releases.
>
>
> > I would prefer Katello releases not be bound by having a full set of X,
> > Y, and Z features. Finish X and Y and RC/GA within a day or two of
> > Foreman - "Z" can be done later.
> >
> > Release early, release often would get features lots more exposure to a
> > wider base before Red Hat consumes it in Satellite, and gives the
> > Foreman community cool new Katello things to play with much more often.
> >
> >
> We release every night - that's often But really, releasing incomplete
> features doesn't, in my mind, serve anyone. I think a balance is required
> to pick the set of features that make sense, get you a timely release and
> then act on those and release. Rinse and repeat.
>
> As for coordinating releases, I think you may need to clarify Tom. The
> Katello devs intend to follow the 1.8 cycle of branching and release for
> 2.2. I am assuming your intent is to gather support for and change the
> workflow to require mutual assured releases. In other words, they only
> release when both are green lit.
To clarify: Both foreman and katello release together and when both are green. (ie. They are treated as a single project in terms of scheduling releases and the actual release.)
Foreman releases on a rough schedule and they load that schedule with features/work/bugs appropriate to the time. Katello would do the same. In fact, both projects, really being funded and worked by a single Red Hat Satellite-6 in-house staff, could probably coordinate this work so that it is always reasonable to accomplish the synchronization.
If one side or the other needs to slip, they slip together. The slip-or-skip for features, be they foreman, katello, or combination, would be made jointly as release time neared. Just like @domcleal does for foreman releases, it would be a unified discussion.
Besides, "I need to get my features done in this time frame," are there downsides to this? The upsides outweight anything I've heard so far.
But really, releasing incomplete