Greetings!
As some of you know, I've been working on migrating Foreman from Rails 3.2
to 4.1, and it took most of my time for the better part of the last 4
months. The current status on foreman is tests are finally passing, but
failing every time I rebase develop into it (I try to do so daily) - which
brings me a lot of frustration. We need this task to be completed, thus, I
want to open a discussion on how to approach this. The way I see it, we
have three options:
We can go "cold turkey", i.e. merge rails 4 branch into foreman's
develop, and break all of the plugins, bringing the Katello team to panic
mode.
this means highly agitating a lot of people, but should also prove
to be the most time-efficient method
not very realistic due to ^^
We can maintain a rails 4 branch and have daily rebases of the
develop branch of foreman and each plugin.
This means daily tough rebases which will get a lot of people down.
Large features will be very painful to get in.
We can trust me to just do all the work and hope I don't crash and
burn spectacularly
The main issue is Katello, which should be very hard to migrate. Ohad
suggested that I do it myself, which has the added benefit of me getting
familiar with Katello's code. Problem is it would take me quite a while to
figure this out and may not be a very time-efficient way of doing it
> As some of you know, I've been working on migrating Foreman from Rails
> 3.2 to 4.1, and it took most of my time for the better part of the last
> 4 months. The current status on foreman is tests are finally passing,
> but failing every time I rebase develop into it (I try to do so daily) -
> which brings me a lot of frustration. We need this task to be completed,
> thus, I want to open a discussion on how to approach this.
Note there's a previous thread from a few days ago on this subject too,
I hope you've seen that.
> 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
> develop, and break all of the plugins
There are too many plugins to wait for them, so we should do this.
Plugins can update at their own pace.
> Greetings!
> As some of you know, I've been working on migrating Foreman from Rails 3.2
> to 4.1, and it took most of my time for the better part of the last 4
> months. The current status on foreman is tests are finally passing, but
> failing every time I rebase develop into it (I try to do so daily) - which
> brings me a lot of frustration. We need this task to be completed, thus, I
> want to open a discussion on how to approach this. The way I see it, we
> have three options:
>
> 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
> develop, and break all of the plugins, bringing the Katello team to panic
> mode.
> - this means highly agitating a lot of people, but should also
> prove to be the most time-efficient method
> - not very realistic due to ^^
> 2. We can maintain a rails 4 branch and have daily rebases of the
> develop branch of foreman and each plugin.
> - This means daily tough rebases which will get a lot of people
> down. Large features will be very painful to get in.
>
>
My vote is on a rail4 branch, other plugin authors can test against it, and
we could reduce the scope of the pr review.
e.g. instead of a massive rebase each time (which introduce a huge pr to
review) i would suggest to create a new cherry-pick for each new commit
into foreman.
I am not sure if there are any shortcuts with git using this (e.g.
detecting if i merged all commits or not), but I think overall this would
be more valuable, and allow more people to take part in the process.
When we actually merge, we could rebase or just apply a new commit to
develop without the history of the branch development.
Going forward, I would suggest:
take the pr as is and change it to a rails 4 branch.
every new develop merge, cherrypick if it cleanly merge, otherwise open
a new pr.
reduce the scope of the branch by extracting stuff that can work in
rails3 (what Daniel already started, strong params etc etc).
set a date (post 1.9 of course) for merge.
I would strongly recommend all plugin authors to start looking on this
branch, together with the links Tom sent for guidance on the migration.
Ohad
···
On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy wrote:
We can trust me to just do all the work and hope I don’t crash and
burn spectacularly
The main issue is Katello, which should be very hard to migrate. Ohad
suggested that I do it myself, which has the added benefit of me getting
familiar with Katello’s code. Problem is it would take me quite a while to
figure this out and may not be a very time-efficient way of doing it
> > As some of you know, I've been working on migrating Foreman from Rails
> > 3.2 to 4.1, and it took most of my time for the better part of the last
> > 4 months. The current status on foreman is tests are finally passing,
> > but failing every time I rebase develop into it (I try to do so daily) -
> > which brings me a lot of frustration. We need this task to be completed,
> > thus, I want to open a discussion on how to approach this.
>
> Note there's a previous thread from a few days ago on this subject too,
> I hope you've seen that.
>
> > 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
> > develop, and break all of the plugins
>
> There are too many plugins to wait for them, so we should do this.
> Plugins can update at their own pace.
I think before you go merging into develop, you should convert a couple
non-trivial plugins and update the Wiki so maintainers understand what
the possible things they have to change are.
Not fair to just dump this into develop, break everyone, and tell them
they're on their own to update. And it doesn't sound like too much work
based on what Daniel did for Docker.
What's the timeline for Rails 4 now if you're talking about merging?
1.9?
That's especially bad for Katello, as the idea was to co-release, but
forcing this into Foreman and ignoring Katello means we're going to have
a significant delay in 2.3, right?
It also makes Katello on Existing Foreman work impossible to begin.
···
On Mon, Jun 01, 2015 at 08:41:45AM +0100, Dominic Cleal wrote:
> On 01/06/15 08:32, Tom Caspy wrote:
>>> > > As some of you know, I've been working on migrating Foreman from Rails
>>> > > 3.2 to 4.1, and it took most of my time for the better part of the last
>>> > > 4 months. The current status on foreman is tests are finally passing,
>>> > > but failing every time I rebase develop into it (I try to do so daily) -
>>> > > which brings me a lot of frustration. We need this task to be completed,
>>> > > thus, I want to open a discussion on how to approach this.
>> >
>> > Note there's a previous thread from a few days ago on this subject too,
>> > I hope you've seen that.
>> >
>>> > > 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
>>> > > develop, and break all of the plugins
>> >
>> > There are too many plugins to wait for them, so we should do this.
>> > Plugins can update at their own pace.
> I think before you go merging into develop, you should convert a couple
> non-trivial plugins and update the Wiki so maintainers understand what
> the possible things they have to change are.
>
> Not fair to just dump this into develop, break everyone, and tell them
> they're on their own to update.
I hadn't meant to imply that plugin authors would be entirely on their
own, these are all sensible suggestions, but that merging should not be
blocked waiting for plugins. That'll happen in time.
> What's the timeline for Rails 4 now if you're talking about merging?
> 1.9?
Seems rather unlikely to me, as discussed in the other thread, and that
branching is soon, and that we can't package it yet.
···
On 01/06/15 11:38, Stephen Benjamin wrote:
> On Mon, Jun 01, 2015 at 08:41:45AM +0100, Dominic Cleal wrote:
>> > On 01/06/15 08:32, Tom Caspy wrote:
The installer does default to installing the setup plugin, so I'd at
least make sure that keeps working.
···
On Mon, Jun 01, 2015 at 08:41:45AM +0100, Dominic Cleal wrote:
> On 01/06/15 08:32, Tom Caspy wrote:
> > As some of you know, I've been working on migrating Foreman from Rails
> > 3.2 to 4.1, and it took most of my time for the better part of the last
> > 4 months. The current status on foreman is tests are finally passing,
> > but failing every time I rebase develop into it (I try to do so daily) -
> > which brings me a lot of frustration. We need this task to be completed,
> > thus, I want to open a discussion on how to approach this.
>
> Note there's a previous thread from a few days ago on this subject too,
> I hope you've seen that.
>
> > 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
> > develop, and break all of the plugins
>
> There are too many plugins to wait for them, so we should do this.
> Plugins can update at their own pace.
>
> > Greetings!
> > As some of you know, I've been working on migrating Foreman from Rails 3.2
> > to 4.1, and it took most of my time for the better part of the last 4
> > months. The current status on foreman is tests are finally passing, but
> > failing every time I rebase develop into it (I try to do so daily) - which
> > brings me a lot of frustration. We need this task to be completed, thus, I
> > want to open a discussion on how to approach this. The way I see it, we
> > have three options:
> >
> > 1. We can go "cold turkey", i.e. merge rails 4 branch into foreman's
> > develop, and break all of the plugins, bringing the Katello team to panic
> > mode.
> > - this means highly agitating a lot of people, but should also
> > prove to be the most time-efficient method
> > - not very realistic due to ^^
> > 2. We can maintain a rails 4 branch and have daily rebases of the
> > develop branch of foreman and each plugin.
> > - This means daily tough rebases which will get a lot of people
> > down. Large features will be very painful to get in.
> >
> >
> My vote is on a rail4 branch, other plugin authors can test against it, and
> we could reduce the scope of the pr review.
> e.g. instead of a massive rebase each time (which introduce a huge pr to
> review) i would suggest to create a new cherry-pick for each new commit
> into foreman.
> I am not sure if there are any shortcuts with git using this (e.g.
> detecting if i merged all commits or not), but I think overall this would
> be more valuable, and allow more people to take part in the process.
>
> When we actually merge, we could rebase or just apply a new commit to
> develop without the history of the branch development.
>
> Going forward, I would suggest:
> 1. take the pr as is and change it to a rails 4 branch.
> 2. every new develop merge, cherrypick if it cleanly merge, otherwise open
> a new pr.
Not that I'm aware. Gerrit has some tooling to detect this by attaching
a Change-Id to every commit and then tracking that, but that's not part
of git.
> 3. reduce the scope of the branch by extracting stuff that can work in
> rails3 (what Daniel already started, strong params etc etc).
In my (non-Foreman) experience this is the best strategy. Then you will
most likely still end up with a big PR, but the smaller it is, the
better. I'd actually start with this as soon as possible so Daniel++
···
On Tue, Jun 02, 2015 at 11:52:05AM +0300, Ohad Levy wrote:
> On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy wrote:
set a date (post 1.9 of course) for merge.
I would strongly recommend all plugin authors to start looking on this
branch, together with the links Tom sent for guidance on the migration.
Isn't it easier to periodically merge develop into rails4? At least
then they have a shared, rather than duplicate history. It'll be hard
to tell which changes are from develop and which are Rails 4 related if
it's cherry picked, especially if you're thinking to fix issues inside
the commit during cherry pick.
···
On 02/06/15 09:52, Ohad Levy wrote:
>
>
> On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy > wrote:
>
> Greetings!
> As some of you know, I've been working on migrating Foreman from
> Rails 3.2 to 4.1, and it took most of my time for the better part of
> the last 4 months. The current status on foreman is tests are
> finally passing, but failing every time I rebase develop into it (I
> try to do so daily) - which brings me a lot of frustration. We need
> this task to be completed, thus, I want to open a discussion on how
> to approach this. The way I see it, we have three options:
>
> 1. We can go "cold turkey", i.e. merge rails 4 branch into
> foreman's develop, and break all of the plugins, bringing the
> Katello team to panic mode.
> * this means highly agitating a lot of people, but should also
> prove to be the most time-efficient method
> * not very realistic due to ^^
> 2. We can maintain a rails 4 branch and have daily rebases of the
> develop branch of foreman and each plugin.
> * This means daily tough rebases which will get a lot of
> people down. Large features will be very painful to get in.
>
>
> My vote is on a rail4 branch, other plugin authors can test against it,
> and we could reduce the scope of the pr review.
> e.g. instead of a massive rebase each time (which introduce a huge pr to
> review) i would suggest to create a new cherry-pick for each new commit
> into foreman.
Based on past experiences with large changes, I tend to agree that at some
point the band aid has to be ripped off and there will be down time for
various aspects of our projects. However, I think our goal should be to
minimize that downtime and have a plan for navigating them.
Has anyone tried to convert Katello yet? If we have a benchmark of how
many changes need to be made and roughly how much effort that will take we
can better account for the steps we should take. I assume we can use the
foreman_docker conversion work as a baseline for other plugins of that
size. My feeling is that if we can get the key plugins nearly converted,
then we could have a succession of days of subsequently rebasing/merging
each.
Where does packaging fit into this? I know Dominic has an open PR to
convert to a new SCL and then the newer Rails SCLs but has the downtime
between the codebase (and developers using gems) being converted over and
packaging being updated been considered?
I assume certain Jenkins jobs will go into failure mode (repeatedly)
during this period. Should those be identified and turned off/set to
warning mode during this time period if there is a period of days in
between?
Eric
···
On Mon, Jun 1, 2015 at 6:51 AM, Dominic Cleal wrote:
On 01/06/15 11:38, Stephen Benjamin wrote:
On Mon, Jun 01, 2015 at 08:41:45AM +0100, Dominic Cleal wrote:
On 01/06/15 08:32, Tom Caspy wrote:
As some of you know, I’ve been working on migrating Foreman from
Rails
3.2 to 4.1, and it took most of my time for the better part of the
last
4 months. The current status on foreman is tests are finally
passing,
but failing every time I rebase develop into it (I try to do so
daily) -
which brings me a lot of frustration. We need this task to be
completed,
thus, I want to open a discussion on how to approach this.
Note there’s a previous thread from a few days ago on this subject
too,
I hope you’ve seen that.
We can go “cold turkey”, i.e. merge rails 4 branch into
foreman’s
develop, and break all of the plugins
There are too many plugins to wait for them, so we should do this.
Plugins can update at their own pace.
I think before you go merging into develop, you should convert a couple
non-trivial plugins and update the Wiki so maintainers understand what
the possible things they have to change are.
Not fair to just dump this into develop, break everyone, and tell them
they’re on their own to update.
I hadn’t meant to imply that plugin authors would be entirely on their
own, these are all sensible suggestions, but that merging should not be
blocked waiting for plugins. That’ll happen in time.
What’s the timeline for Rails 4 now if you’re talking about merging?
1.9?
Seems rather unlikely to me, as discussed in the other thread, and that
branching is soon, and that we can’t package it yet.
> 2) Where does packaging fit into this? I know Dominic has an open PR to
> convert to a new SCL and then the newer Rails SCLs but has the downtime
> between the codebase (and developers using gems) being converted over
> and packaging being updated been considered?
I haven't yet tried moving to a new Rails 4 enabled SCL, I don't know
precisely what's involved, just that it should be easier once the move
to our own SCL is complete. I scripted most of that, and intend to do
the same. Not too many deps have changed, so I don't think it'll be too
bad.
> 3) I assume certain Jenkins jobs will go into failure mode (repeatedly)
> during this period. Should those be identified and turned off/set to
> warning mode during this time period if there is a period of days in
> between?
Sure, that should be the case for anything today that we know is failing
and isn't likely to get fixed. Save resources if we can.
> >
> >
> >
> > Greetings!
> > As some of you know, I've been working on migrating Foreman from
> > Rails 3.2 to 4.1, and it took most of my time for the better part of
> > the last 4 months. The current status on foreman is tests are
> > finally passing, but failing every time I rebase develop into it (I
> > try to do so daily) - which brings me a lot of frustration. We need
> > this task to be completed, thus, I want to open a discussion on how
> > to approach this. The way I see it, we have three options:
> >
> > 1. We can go "cold turkey", i.e. merge rails 4 branch into
> > foreman's develop, and break all of the plugins, bringing the
> > Katello team to panic mode.
> > * this means highly agitating a lot of people, but should also
> > prove to be the most time-efficient method
> > * not very realistic due to ^^
> > 2. We can maintain a rails 4 branch and have daily rebases of the
> > develop branch of foreman and each plugin.
> > * This means daily tough rebases which will get a lot of
> > people down. Large features will be very painful to get in.
> >
> >
> > My vote is on a rail4 branch, other plugin authors can test against it,
> > and we could reduce the scope of the pr review.
> > e.g. instead of a massive rebase each time (which introduce a huge pr to
> > review) i would suggest to create a new cherry-pick for each new commit
> > into foreman.
>
> Isn't it easier to periodically merge develop into rails4? At least
> then they have a shared, rather than duplicate history. It'll be hard
> to tell which changes are from develop and which are Rails 4 related if
> it's cherry picked, especially if you're thinking to fix issues inside
> the commit during cherry pick.
>
my assumption was that they can't be merged, if I'm wrong then I'm fine
with that.
Ohad
···
On Wed, Jun 3, 2015 at 5:37 PM, Dominic Cleal wrote:
> On 02/06/15 09:52, Ohad Levy wrote:
> > On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy > > wrote:
I'm not sure I see why they couldn't be merged - you're just merging two
branches together, both with a common ancestor (an old develop).
If they conflict, then you resolve the conflicts in the merge commit.
If there's a Rails 4 incompatibility, then you either do it in the merge
commit or make an additional commit to change the behaviour and ref the
original ticket.
That is, if we don't mind merging across branches and eventually using a
merge of the branch - or unpicking all the changes again.
···
On 03/06/15 16:02, Ohad Levy wrote:
>
>
> On Wed, Jun 3, 2015 at 5:37 PM, Dominic Cleal > wrote:
>
> On 02/06/15 09:52, Ohad Levy wrote:
> >
> >
> > On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy <tcaspy@gmail.com > > <mailto:tcaspy@gmail.com >> wrote:
> >
> > Greetings!
> > As some of you know, I've been working on migrating Foreman from
> > Rails 3.2 to 4.1, and it took most of my time for the better part of
> > the last 4 months. The current status on foreman is tests are
> > finally passing, but failing every time I rebase develop into it (I
> > try to do so daily) - which brings me a lot of frustration. We need
> > this task to be completed, thus, I want to open a discussion on how
> > to approach this. The way I see it, we have three options:
> >
> > 1. We can go "cold turkey", i.e. merge rails 4 branch into
> > foreman's develop, and break all of the plugins, bringing the
> > Katello team to panic mode.
> > * this means highly agitating a lot of people, but
> should also
> > prove to be the most time-efficient method
> > * not very realistic due to ^^
> > 2. We can maintain a rails 4 branch and have daily rebases of the
> > develop branch of foreman and each plugin.
> > * This means daily tough rebases which will get a lot of
> > people down. Large features will be very painful to get in.
> >
> >
> > My vote is on a rail4 branch, other plugin authors can test against it,
> > and we could reduce the scope of the pr review.
> > e.g. instead of a massive rebase each time (which introduce a huge pr to
> > review) i would suggest to create a new cherry-pick for each new commit
> > into foreman.
>
> Isn't it easier to periodically merge develop into rails4? At least
> then they have a shared, rather than duplicate history. It'll be hard
> to tell which changes are from develop and which are Rails 4 related if
> it's cherry picked, especially if you're thinking to fix issues inside
> the commit during cherry pick.
>
>
> my assumption was that they can't be merged, if I'm wrong then I'm fine
> with that.
On 02/06/15 09:52, Ohad Levy wrote:
>
>
> On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy <tcaspy@gmail.com > <mailto:tcaspy@gmail.com> > > > <mailto:tcaspy@gmail.com <mailto:tcaspy@gmail.com>>> wrote:
>
> Greetings!
> As some of you know, I've been working on migrating Foreman
from
> Rails 3.2 to 4.1, and it took most of my time for the better
part of
> the last 4 months. The current status on foreman is tests are
> finally passing, but failing every time I rebase develop into
it (I
> try to do so daily) - which brings me a lot of frustration. We
need
> this task to be completed, thus, I want to open a discussion
on how
> to approach this. The way I see it, we have three options:
>
> 1. We can go "cold turkey", i.e. merge rails 4 branch into
> foreman's develop, and break all of the plugins, bringing
the
> Katello team to panic mode.
> * this means highly agitating a lot of people, but
should also
> prove to be the most time-efficient method
> * not very realistic due to ^^
> 2. We can maintain a rails 4 branch and have daily rebases of
the
> develop branch of foreman and each plugin.
> * This means daily tough rebases which will get a lot of
> people down. Large features will be very painful to
get in.
>
>
> My vote is on a rail4 branch, other plugin authors can test
against it,
> and we could reduce the scope of the pr review.
> e.g. instead of a massive rebase each time (which introduce a huge
pr to
> review) i would suggest to create a new cherry-pick for each new
commit
> into foreman.
Isn't it easier to periodically merge develop into rails4? At least
then they have a shared, rather than duplicate history. It'll be
hard
to tell which changes are from develop and which are Rails 4 related
if
it's cherry picked, especially if you're thinking to fix issues
inside
the commit during cherry pick.
my assumption was that they can’t be merged, if I’m wrong then I’m fine
with that.
I’m not sure I see why they couldn’t be merged - you’re just merging two
branches together, both with a common ancestor (an old develop).
If they conflict, then you resolve the conflicts in the merge commit.
If there’s a Rails 4 incompatibility, then you either do it in the merge
commit or make an additional commit to change the behaviour and ref the
original ticket.
That is, if we don’t mind merging across branches and eventually using a
merge of the branch - or unpicking all the changes again.
>
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > Greetings!
> > > > As some of you know, I've been working on migrating Foreman
> > from
> > > > Rails 3.2 to 4.1, and it took most of my time for the better
> > part of
> > > > the last 4 months. The current status on foreman is tests are
> > > > finally passing, but failing every time I rebase develop into
> > it (I
> > > > try to do so daily) - which brings me a lot of frustration. We
> > need
> > > > this task to be completed, thus, I want to open a discussion
> > on how
> > > > to approach this. The way I see it, we have three options:
> > > >
> > > > 1. We can go "cold turkey", i.e. merge rails 4 branch into
> > > > foreman's develop, and break all of the plugins, bringing
> > the
> > > > Katello team to panic mode.
> > > > * this means highly agitating a lot of people, but
> > > should also
> > > > prove to be the most time-efficient method
> > > > * not very realistic due to ^^
> > > > 2. We can maintain a rails 4 branch and have daily rebases of
> > the
> > > > develop branch of foreman and each plugin.
> > > > * This means daily tough rebases which will get a lot of
> > > > people down. Large features will be very painful to
> > get in.
> > > >
> > > >
> > > > My vote is on a rail4 branch, other plugin authors can test
> > against it,
> > > > and we could reduce the scope of the pr review.
> > > > e.g. instead of a massive rebase each time (which introduce a huge
> > pr to
> > > > review) i would suggest to create a new cherry-pick for each new
> > commit
> > > > into foreman.
> > >
> > > Isn't it easier to periodically merge develop into rails4? At least
> > > then they have a shared, rather than duplicate history. It'll be
> > hard
> > > to tell which changes are from develop and which are Rails 4 related
> > if
> > > it's cherry picked, especially if you're thinking to fix issues
> > inside
> > > the commit during cherry pick.
> > >
> > >
> > > my assumption was that they can't be merged, if I'm wrong then I'm fine
> > > with that.
> >
> > I'm not sure I see why they couldn't be merged - you're just merging two
> > branches together, both with a common ancestor (an old develop).
> >
> > If they conflict, then you resolve the conflicts in the merge commit.
> > If there's a Rails 4 incompatibility, then you either do it in the merge
> > commit or make an additional commit to change the behaviour and ref the
> > original ticket.
> >
> > That is, if we don't mind merging across branches and eventually using a
> > merge of the branch - or unpicking all the changes again.
> >
> >
>
> the main concern was the size of the PR to review, how about the following:
>
> 1. take the pr as is and change it to a rails 4 branch.
> 2. do weekly (or so) merges - if thats too hard, consider moving to
> something else (cherrypick, PR etc).
> 3. reduce the scope of the branch by extracting stuff that can work in
> rails3 (what Daniel already started, strong params etc etc).
Currently on it, really https://github.com/theforeman/foreman/pull/2358
should be 1 step away from merge, it's more than likely we can take
other parts as Dominic mentioned in the other thread.
> 4. set a date (post 1.9 of course) for merge.
This last point I'm not sure I get it, it can't be merged if it's not
ready/plugins are not ready etc…
···
On 06/03, Ohad Levy wrote:
> On Wed, Jun 3, 2015 at 6:13 PM, Dominic Cleal wrote:
> > On 03/06/15 16:02, Ohad Levy wrote:
> > > On Wed, Jun 3, 2015 at 5:37 PM, Dominic Cleal > > > wrote:
> > > On 02/06/15 09:52, Ohad Levy wrote:
> > > > On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy > > > > > <mailto:tcaspy@gmail.com >> wrote:
>
> Ohad
>
> --
> > Dominic Cleal
> > 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.
> >
>
> --
> 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.
> >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Greetings!
> > > > > As some of you know, I've been working on migrating Foreman
> > > from
> > > > > Rails 3.2 to 4.1, and it took most of my time for the
> better
> > > part of
> > > > > the last 4 months. The current status on foreman is tests
> are
> > > > > finally passing, but failing every time I rebase develop
> into
> > > it (I
> > > > > try to do so daily) - which brings me a lot of
> frustration. We
> > > need
> > > > > this task to be completed, thus, I want to open a
> discussion
> > > on how
> > > > > to approach this. The way I see it, we have three options:
> > > > >
> > > > > 1. We can go "cold turkey", i.e. merge rails 4 branch into
> > > > > foreman's develop, and break all of the plugins,
> bringing
> > > the
> > > > > Katello team to panic mode.
> > > > > * this means highly agitating a lot of people, but
> > > > should also
> > > > > prove to be the most time-efficient method
> > > > > * not very realistic due to ^^
> > > > > 2. We can maintain a rails 4 branch and have daily
> rebases of
> > > the
> > > > > develop branch of foreman and each plugin.
> > > > > * This means daily tough rebases which will get a
> lot of
> > > > > people down. Large features will be very painful to
> > > get in.
> > > > >
> > > > >
> > > > > My vote is on a rail4 branch, other plugin authors can test
> > > against it,
> > > > > and we could reduce the scope of the pr review.
> > > > > e.g. instead of a massive rebase each time (which introduce a
> huge
> > > pr to
> > > > > review) i would suggest to create a new cherry-pick for each
> new
> > > commit
> > > > > into foreman.
> > > >
> > > > Isn't it easier to periodically merge develop into rails4? At
> least
> > > > then they have a shared, rather than duplicate history. It'll be
> > > hard
> > > > to tell which changes are from develop and which are Rails 4
> related
> > > if
> > > > it's cherry picked, especially if you're thinking to fix issues
> > > inside
> > > > the commit during cherry pick.
> > > >
> > > >
> > > > my assumption was that they can't be merged, if I'm wrong then I'm
> fine
> > > > with that.
> > >
> > > I'm not sure I see why they couldn't be merged - you're just merging
> two
> > > branches together, both with a common ancestor (an old develop).
> > >
> > > If they conflict, then you resolve the conflicts in the merge commit.
> > > If there's a Rails 4 incompatibility, then you either do it in the
> merge
> > > commit or make an additional commit to change the behaviour and ref the
> > > original ticket.
> > >
> > > That is, if we don't mind merging across branches and eventually using
> a
> > > merge of the branch - or unpicking all the changes again.
> > >
> > >
> >
> > the main concern was the size of the PR to review, how about the
> following:
> >
> > 1. take the pr as is and change it to a rails 4 branch.
> > 2. do weekly (or so) merges - if thats too hard, consider moving to
> > something else (cherrypick, PR etc).
> > 3. reduce the scope of the branch by extracting stuff that can work in
> > rails3 (what Daniel already started, strong params etc etc).
> Currently on it, really https://github.com/theforeman/foreman/pull/2358
> should be 1 step away from merge, it's more than likely we can take
> other parts as Dominic mentioned in the other thread.
> > 4. set a date (post 1.9 of course) for merge.
> This last point I'm not sure I get it, it can't be merged if it's not
> ready/plugins are not ready etc…
>
Assuming steps 1-3 are done / foreman core is ready for a while, and
majority of plugins has started to work on migration, we need to establish
a date when we merge, similar to how stable branches are made?
Does that make sense?
Ohad
···
On Wed, Jun 10, 2015 at 7:38 PM, Daniel Lobato Garcia wrote:
> On 06/03, Ohad Levy wrote:
> > On Wed, Jun 3, 2015 at 6:13 PM, Dominic Cleal > wrote:
> > > On 03/06/15 16:02, Ohad Levy wrote:
> > > > On Wed, Jun 3, 2015 at 5:37 PM, Dominic Cleal > > > > wrote:
> > > > On 02/06/15 09:52, Ohad Levy wrote:
> > > > > On Mon, Jun 1, 2015 at 10:32 AM, Tom Caspy > > > > > > > <mailto:tcaspy@gmail.com >> wrote:
Ohad
–
Dominic Cleal
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
