Foreman planning + Katello

Hi,

I learned this morning that 1.7 is closed for features and getting ready
to go to RC, which was a bit of a surprise. Katello 2.1 needs the mail
features in this PR (https://github.com/theforeman/foreman/pull/1813),
which is not merged. And as I understand, 1.8 is probably going
to be post-FOSDEM unlike previous years, so we're looking at sometime
in February at the earliest.

It makes it difficult for us to contribute features back up to Foreman
if we can't have any idea when they'll be accepted, and it really
made sense for this feature to go to Foreman instead of doing it on
our own in Katello – there's a bunch of low-numbered and frequently
asked about Foreman issues that are also addressed by this.

How can we ensure that Katello interests (or any other plugin's)
can be taken into account? Would it be possible to open up Foreman
planning more to the community, so that we know in advance the features
planned for 1.8, and have our proposals accepted as blockers to
Foreman core?

Thanks,

Stephen Benjamin

> Hi,
>
> I learned this morning that 1.7 is closed for features and getting ready
> to go to RC, which was a bit of a surprise. Katello 2.1 needs the mail
> features in this PR (https://github.com/theforeman/foreman/pull/1813),
> which is not merged. And as I understand, 1.8 is probably going
> to be post-FOSDEM unlike previous years, so we're looking at sometime
> in February at the earliest.

I think start of March at the earliest (December + 3 months), or April
if December is a slow month again.

http://projects.theforeman.org/projects/foreman/wiki/Foreman_18_Schedule

> It makes it difficult for us to contribute features back up to Foreman
> if we can't have any idea when they'll be accepted, and it really
> made sense for this feature to go to Foreman instead of doing it on
> our own in Katello – there's a bunch of low-numbered and frequently
> asked about Foreman issues that are also addressed by this.
>
> How can we ensure that Katello interests (or any other plugin's)
> can be taken into account? Would it be possible to open up Foreman
> planning more to the community, so that we know in advance the features
> planned for 1.8, and have our proposals accepted as blockers to
> Foreman core?

Foreman releases are on about a quarterly schedule, so what's merged is
what's released. People aim to work on certain features in the
three/four months that we're developing it. Development began in July
and August.

I think your PR was submitted with a reasonable amount of time to go,
the failing is probably in lack of a timely review from us maintainers,
making the process unpredictable. If that had happened, this would be a
non-issue.

I don't think we'd be very good at doing feature-led releases based on
past attempts to plan.

··· On 28/10/14 10:25, Stephen Benjamin wrote:


Dominic Cleal
Red Hat Engineering

If not feature-led, then would it be possible to provide a last call to
the mailing list for contributions 2-3 weeks before (maybe a whole
sprint?) so that we can avoid circumstances like this? Would it be
possible to implement this for 1.7?

If not, is it at all possible that #7586 can be taken for 1.7?

I'm generally aware of a quarterly-ish Foreman release schedule, but not
specific dates - I only discovered
http://projects.theforeman.org/projects/foreman/wiki/Foreman_18_Schedule
today, which is helpful, thanks. I do prefer mailing list announcements
for critical events though (stopping feature work for a release being such
an event).

··· On Tue, Oct 28, 2014 at 10:53:31AM +0000, Dominic Cleal wrote: > On 28/10/14 10:25, Stephen Benjamin wrote:

It makes it difficult for us to contribute features back up to Foreman
if we can’t have any idea when they’ll be accepted, and it really
made sense for this feature to go to Foreman instead of doing it on
our own in Katello – there’s a bunch of low-numbered and frequently
asked about Foreman issues that are also addressed by this.

How can we ensure that Katello interests (or any other plugin’s)
can be taken into account? Would it be possible to open up Foreman
planning more to the community, so that we know in advance the features
planned for 1.8, and have our proposals accepted as blockers to
Foreman core?

Foreman releases are on about a quarterly schedule, so what’s merged is
what’s released. People aim to work on certain features in the
three/four months that we’re developing it. Development began in July
and August.

I think your PR was submitted with a reasonable amount of time to go,
the failing is probably in lack of a timely review from us maintainers,
making the process unpredictable. If that had happened, this would be a
non-issue.

I don’t think we’d be very good at doing feature-led releases based on
past attempts to plan.


Stephen Benjamin


Red Hat GmbH | http://de.redhat.com/ | Sitz: Grasbrunn
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham,
Michael O’Neill, Charles Peters

It appears that it was unclear 1.7 would close this morning. What can
help mitigate the problem is an announcement in advance. If you really
want to get burocratic, you can create a procedure to file for an
exception but I'd start with announcements.

··· On Tue, Oct 28, 2014 at 10:53:31AM +0000, Dominic Cleal wrote: > On 28/10/14 10:25, Stephen Benjamin wrote: > > Hi, > > > > I learned this morning that 1.7 is closed for features and getting ready > > to go to RC, which was a bit of a surprise. Katello 2.1 needs the mail > > features in this PR (https://github.com/theforeman/foreman/pull/1813), > > which is not merged. And as I understand, 1.8 is probably going > > to be post-FOSDEM unlike previous years, so we're looking at sometime > > in February at the earliest. > > I think start of March at the earliest (December + 3 months), or April > if December is a slow month again. > > http://projects.theforeman.org/projects/foreman/wiki/Foreman_18_Schedule > > > It makes it difficult for us to contribute features back up to Foreman > > if we can't have any idea when they'll be accepted, and it really > > made sense for this feature to go to Foreman instead of doing it on > > our own in Katello -- there's a bunch of low-numbered and frequently > > asked about Foreman issues that are also addressed by this. > > > > How can we ensure that Katello interests (or any other plugin's) > > can be taken into account? Would it be possible to open up Foreman > > planning more to the community, so that we know in advance the features > > planned for 1.8, and have our proposals accepted as blockers to > > Foreman core? > > Foreman releases are on about a quarterly schedule, so what's merged is > what's released. People aim to work on certain features in the > three/four months that we're developing it. Development began in July > and August. > > I think your PR was submitted with a reasonable amount of time to go, > the failing is probably in lack of a timely review from us maintainers, > making the process unpredictable. If that had happened, this would be a > non-issue. > > I don't think we'd be very good at doing feature-led releases based on > past attempts to plan.

>
>>> It makes it difficult for us to contribute features back up to Foreman
>>> if we can't have any idea when they'll be accepted, and it really
>>> made sense for this feature to go to Foreman instead of doing it on
>>> our own in Katello – there's a bunch of low-numbered and frequently
>>> asked about Foreman issues that are also addressed by this.
>>>
>>> How can we ensure that Katello interests (or any other plugin's)
>>> can be taken into account? Would it be possible to open up Foreman
>>> planning more to the community, so that we know in advance the features
>>> planned for 1.8, and have our proposals accepted as blockers to
>>> Foreman core?
>>
>> Foreman releases are on about a quarterly schedule, so what's merged is
>> what's released. People aim to work on certain features in the
>> three/four months that we're developing it. Development began in July
>> and August.
>>
>> I think your PR was submitted with a reasonable amount of time to go,
>> the failing is probably in lack of a timely review from us maintainers,
>> making the process unpredictable. If that had happened, this would be a
>> non-issue.
>>
>> I don't think we'd be very good at doing feature-led releases based on
>> past attempts to plan.
>>
>
> If not feature-led, then would it be possible to provide a last call to
> the mailing list for contributions 2-3 weeks before (maybe a whole
> sprint?) so that we can avoid circumstances like this? Would it be
> possible to implement this for 1.7?

Happily. That was my fault, I'm sorry, I usually do. I've added it to
the 1.8 schedule.

> If not, is it at all possible that #7586 can be taken for 1.7?

If it's merged by the time RC1's cut next week, then it may. I would
like any change to have been in develop for a day or two before it's in
a release so we catch any show-stopping regressions. Tagging normally
happens the day before a release.

> I'm generally aware of a quarterly-ish Foreman release schedule, but not
> specific dates - I only discovered
> Foreman 18 Schedule - Foreman
> today, which is helpful, thanks. I do prefer mailing list announcements
> for critical events though (stopping feature work for a release being such
> an event).

Releases - Foreman is the other
authoritative home of this release dates. I've started linking to the
series wiki pages from there. I've found quite a few users are relying
on the release schedules posted.

(Note, feature work doesn't stop, it continues to hit develop.)

··· On 28/10/14 11:14, Stephen Benjamin wrote: > On Tue, Oct 28, 2014 at 10:53:31AM +0000, Dominic Cleal wrote: >> On 28/10/14 10:25, Stephen Benjamin wrote:


Dominic Cleal
Red Hat Engineering

> >
> >>> It makes it difficult for us to contribute features back up to Foreman
> >>> if we can't have any idea when they'll be accepted, and it really
> >>> made sense for this feature to go to Foreman instead of doing it on
> >>> our own in Katello – there's a bunch of low-numbered and frequently
> >>> asked about Foreman issues that are also addressed by this.
> >>>
> >>> How can we ensure that Katello interests (or any other plugin's)
> >>> can be taken into account? Would it be possible to open up Foreman
> >>> planning more to the community, so that we know in advance the features
> >>> planned for 1.8, and have our proposals accepted as blockers to
> >>> Foreman core?
> >>
> >> Foreman releases are on about a quarterly schedule, so what's merged is
> >> what's released. People aim to work on certain features in the
> >> three/four months that we're developing it. Development began in July
> >> and August.
> >>
> >> I think your PR was submitted with a reasonable amount of time to go,
> >> the failing is probably in lack of a timely review from us maintainers,
> >> making the process unpredictable. If that had happened, this would be a
> >> non-issue.
> >>
> >> I don't think we'd be very good at doing feature-led releases based on
> >> past attempts to plan.
> >>
> >
> > If not feature-led, then would it be possible to provide a last call to
> > the mailing list for contributions 2-3 weeks before (maybe a whole
> > sprint?) so that we can avoid circumstances like this? Would it be
> > possible to implement this for 1.7?
>
> Happily. That was my fault, I'm sorry, I usually do. I've added it to
> the 1.8 schedule.

Thanks!

> > If not, is it at all possible that #7586 can be taken for 1.7?
>
> If it's merged by the time RC1's cut next week, then it may. I would
> like any change to have been in develop for a day or two before it's in
> a release so we catch any show-stopping regressions. Tagging normally
> happens the day before a release.

Ok, I'm available to address feedback if any Foreman maintainers have
time to review + test.

> > I'm generally aware of a quarterly-ish Foreman release schedule, but not
> > specific dates - I only discovered
> > Foreman 18 Schedule - Foreman
> > today, which is helpful, thanks. I do prefer mailing list announcements
> > for critical events though (stopping feature work for a release being such
> > an event).
>
> Releases - Foreman is the other
> authoritative home of this release dates. I've started linking to the
> series wiki pages from there. I've found quite a few users are relying
> on the release schedules posted.
>
> (Note, feature work doesn't stop, it continues to hit develop.)

Right I just meant a heads up prior to branching for the release - the
new note in the 1.8 schedule covers that.

··· On Tue, Oct 28, 2014 at 11:21:34AM +0000, Dominic Cleal wrote: > On 28/10/14 11:14, Stephen Benjamin wrote: > > On Tue, Oct 28, 2014 at 10:53:31AM +0000, Dominic Cleal wrote: > >> On 28/10/14 10:25, Stephen Benjamin wrote:

>
> > >
> > >>> It makes it difficult for us to contribute features back up to
Foreman
> > >>> if we can't have any idea when they'll be accepted, and it really
> > >>> made sense for this feature to go to Foreman instead of doing it on
> > >>> our own in Katello – there's a bunch of low-numbered and frequently
> > >>> asked about Foreman issues that are also addressed by this.
> > >>>
> > >>> How can we ensure that Katello interests (or any other plugin's)
> > >>> can be taken into account? Would it be possible to open up Foreman
> > >>> planning more to the community, so that we know in advance the
features
> > >>> planned for 1.8, and have our proposals accepted as blockers to
> > >>> Foreman core?
> > >>
> > >> Foreman releases are on about a quarterly schedule, so what's merged
is
> > >> what's released. People aim to work on certain features in the
> > >> three/four months that we're developing it. Development began in
July
> > >> and August.
> > >>
> > >> I think your PR was submitted with a reasonable amount of time to go,
> > >> the failing is probably in lack of a timely review from us
maintainers,
> > >> making the process unpredictable. If that had happened, this would
be a
> > >> non-issue.
> > >>
> > >> I don't think we'd be very good at doing feature-led releases based
on
> > >> past attempts to plan.
> > >>
> > >
> > > If not feature-led, then would it be possible to provide a last call
to
> > > the mailing list for contributions 2-3 weeks before (maybe a whole
> > > sprint?) so that we can avoid circumstances like this? Would it be
> > > possible to implement this for 1.7?
> >
> > Happily. That was my fault, I'm sorry, I usually do. I've added it to
> > the 1.8 schedule.

What are the open prs that are either important or that people think they
are ready? I would like to try to merge what we can before rc1.

Ohad
>
> Thanks!
>
> > > If not, is it at all possible that #7586 can be taken for 1.7?
> >
> > If it's merged by the time RC1's cut next week, then it may. I would
> > like any change to have been in develop for a day or two before it's in
> > a release so we catch any show-stopping regressions. Tagging normally
> > happens the day before a release.
>
> Ok, I'm available to address feedback if any Foreman maintainers have
> time to review + test.
>
> > > I'm generally aware of a quarterly-ish Foreman release schedule, but
not
> > > specific dates - I only discovered
> > >
http://projects.theforeman.org/projects/foreman/wiki/Foreman_18_Schedule
> > > today, which is helpful, thanks. I do prefer mailing list
announcements
> > > for critical events though (stopping feature work for a release being
such

··· On Oct 28, 2014 1:30 PM, "Stephen Benjamin" wrote: > On Tue, Oct 28, 2014 at 11:21:34AM +0000, Dominic Cleal wrote: > > On 28/10/14 11:14, Stephen Benjamin wrote: > > > On Tue, Oct 28, 2014 at 10:53:31AM +0000, Dominic Cleal wrote: > > >> On 28/10/14 10:25, Stephen Benjamin wrote: > > > an event). > > > > http://projects.theforeman.org/rb/releases/foreman is the other > > authoritative home of this release dates. I've started linking to the > > series wiki pages from there. I've found quite a few users are relying > > on the release schedules posted. > > > > (Note, feature work doesn't stop, it continues to hit develop.) > > Right I just meant a heads up prior to branching for the release - the > new note in the 1.8 schedule covers that. > >