Over time, community-templates has accumulated a lot of cruft, dues to
us trying to support multiple versions of Foreman within a single
template. That problem is about to get significantly worse with 1.8's
new networking stack.
Every other repo we have is branched per release (1.7-stable,
1.8-stable, develop). I propose we do the same for
community-templates. This shouldn't be much work - we'll have to
occaisionally cherry-pick things across multiple branches, but the
result should be much cleaner templates.
Side note: this may impact foreman-templates, which defaults to the
master branch of community-templates. I happen to be doing some work
in my spare time on this plugin at the moment anyway, so I can resolve
this by defaulting to the correct branch for the running Foreman
version.
Thoughts or concerns? I can do this next week if not.
Not against it, but I think foreman-templates should be updated first
(and land in the proper repositories) before I'd remove support from
master. Until the support is removed, there's no point in creating new
branches (besides perhaps when plugin support is only in some branches,
but I'd prefer to avoid that).
···
On Thu, Mar 05, 2015 at 03:47:46PM +0000, Greg Sutcliffe wrote:
> Hi all,
>
> Over time, community-templates has accumulated a lot of cruft, dues to
> us trying to support multiple versions of Foreman within a single
> template. That problem is about to get significantly worse with 1.8's
> new networking stack.
>
> Every other repo we have is branched per release (1.7-stable,
> 1.8-stable, develop). I propose we do the same for
> community-templates. This shouldn't be much work - we'll have to
> occaisionally cherry-pick things across multiple branches, but the
> result should be *much* cleaner templates.
>
> Side note: this may impact foreman-templates, which defaults to the
> master branch of community-templates. I happen to be doing some work
> in my spare time on this plugin at the moment anyway, so I can resolve
> this by defaulting to the correct branch for the running Foreman
> version.
>
> Thoughts or concerns? I can do this next week if not.
Note that we deleted the master branch, which caused open PRs to be
automatically closed as they're pointing at the wrong target. They'll
need to be reopened against develop, which you can do from your GitHub
fork homepage, select the branch and click the green button to the left.
···
On 05/03/15 15:47, Greg Sutcliffe wrote:
> Over time, community-templates has accumulated a lot of cruft, dues to
> us trying to support multiple versions of Foreman within a single
> template. That problem is about to get significantly worse with 1.8's
> new networking stack.
>
> Every other repo we have is branched per release (1.7-stable,
> 1.8-stable, develop). I propose we do the same for
> community-templates. This shouldn't be much work - we'll have to
> occaisionally cherry-pick things across multiple branches, but the
> result should be *much* cleaner templates.
>> Hi all,
>>
>> Over time, community-templates has accumulated a lot of cruft, dues to
>> us trying to support multiple versions of Foreman within a single
>> template. That problem is about to get significantly worse with 1.8's
>> new networking stack.
>>
>> Every other repo we have is branched per release (1.7-stable,
>> 1.8-stable, develop). I propose we do the same for
>> community-templates. This shouldn't be much work - we'll have to
>> occaisionally cherry-pick things across multiple branches, but the
>> result should be much cleaner templates.
>>
>> Side note: this may impact foreman-templates, which defaults to the
>> master branch of community-templates. I happen to be doing some work
>> in my spare time on this plugin at the moment anyway, so I can resolve
>> this by defaulting to the correct branch for the running Foreman
>> version.
>>
>> Thoughts or concerns? I can do this next week if not.
>
> Not against it, but I think foreman-templates should be updated first
> (and land in the proper repositories) before I'd remove support from
> master.
I can change that pretty easily - I'll try and throw a PR out for that tonight.
> Until the support is removed, there's no point in creating new
> branches (besides perhaps when plugin support is only in some branches,
> but I'd prefer to avoid that).
Not sure I follow what you're getting at here. Could you elaborate?
Greg
···
On 5 March 2015 at 16:11, Ewoud Kohl van Wijngaarden wrote:
> On Thu, Mar 05, 2015 at 03:47:46PM +0000, Greg Sutcliffe wrote:
I'd prefer to have the foreman-templates plugins available in all
repositories and give users a chance to upgrade before we start
requiring users to use a non-master branch. In my mind there was no
point in creating the new branches until you remove the support for
older versions, but I now realize that to give users a chance to
upgrade, you need to create them already.
···
On Thu, Mar 05, 2015 at 05:00:47PM +0000, Greg Sutcliffe wrote:
> On 5 March 2015 at 16:11, Ewoud Kohl van Wijngaarden > wrote:
> > On Thu, Mar 05, 2015 at 03:47:46PM +0000, Greg Sutcliffe wrote:
> >> Hi all,
> >>
> >> Over time, community-templates has accumulated a lot of cruft, dues to
> >> us trying to support multiple versions of Foreman within a single
> >> template. That problem is about to get significantly worse with 1.8's
> >> new networking stack.
> >>
> >> Every other repo we have is branched per release (1.7-stable,
> >> 1.8-stable, develop). I propose we do the same for
> >> community-templates. This shouldn't be much work - we'll have to
> >> occaisionally cherry-pick things across multiple branches, but the
> >> result should be *much* cleaner templates.
> >>
> >> Side note: this may impact foreman-templates, which defaults to the
> >> master branch of community-templates. I happen to be doing some work
> >> in my spare time on this plugin at the moment anyway, so I can resolve
> >> this by defaulting to the correct branch for the running Foreman
> >> version.
> >>
> >> Thoughts or concerns? I can do this next week if not.
> >
> > Not against it, but I think foreman-templates should be updated first
> > (and land in the proper repositories) before I'd remove support from
> > master.
>
> I can change that pretty easily - I'll try and throw a PR out for that tonight.
>
> > Until the support is removed, there's no point in creating new
> > branches (besides perhaps when plugin support is only in some branches,
> > but I'd prefer to avoid that).
>
> Not sure I follow what you're getting at here. Could you elaborate?
···
On 12 March 2015 at 13:25, Lukas Zapletal wrote:
>> Thoughts or concerns? I can do this next week if not.
>
> Idea: to add support for branches into the template sync plugin, which
> is great.
Right. I think we can keep the current "master" for a short while
(it'll be a clone of 1.7-stable) while we settle everything down. Then
anyone on older plugin versions won't be broken.
···
On 5 March 2015 at 17:28, Ewoud Kohl van Wijngaarden wrote:
> I'd prefer to have the foreman-templates plugins available in all
> repositories and give users a chance to upgrade before we start
> requiring users to use a non-master branch. In my mind there was no
> point in creating the new branches until you remove the support for
> older versions, but I now realize that to give users a chance to
> upgrade, you need to create them already.
Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
"master" - current default branch. Leave it as the default for now,
use it for basic templates that should work on any version of older
Foreman version
"develop" - latest version of templates, to be sync'd to foreman-nightly
"1.7-stable" - templates for 1.7
"1.8-stable" - templates for 1.8
With this structure, then:
A user with the old plugin will still get "master" as before
A user with the new plugin will get "master" for any branch we
haven't created yet
A user with the new plugin will get "1.X-stable" for any branch we
have created
A user with the new plugin will get "develop" if using foreman-nightly
I think that's all the use cases, and seems a sane set of defaults.
Obviously, a user can override the repo if need be, as well.
I don't really have a better suggestion, but I'm concerned that if we
leave the branch on master then people contributing to the repo will
simply not notice and continue to submit PRs there… we might be able
to alleviate it slightly with a large notice in the README, but you know
often people read those.
···
On 12/03/15 02:48, Greg Sutcliffe wrote:
> Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
>
> * "master" - current default branch. Leave it as the default for now,
> use it for basic templates that should work on any version of older
> Foreman version
> * "develop" - latest version of templates, to be sync'd to foreman-nightly
> Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
>
> * "master" - current default branch. Leave it as the default for now,
> use it for basic templates that should work on any version of older
> Foreman version
> * "develop" - latest version of templates, to be sync'd to foreman-nightly
Initially I didn't like this, but it follows the convention in the
primary foreman repository so at least it'd be consistent.
> * "1.7-stable" - templates for 1.7
> * "1.8-stable" - templates for 1.8
I'd prefer just 1.7 or foreman-1.7. stable implies it can't be used for
RCs and I see no reason not to.
> With this structure, then:
>
> * A user with the old plugin will still get "master" as before
> * A user with the new plugin will get "master" for any branch we
> haven't created yet
Why not develop? No branch most likely means unreleased which will most
likely be nightly. For RCs we should IMHO branch when we release but
otherwise nightly will very likely be the best option. It'd also allow
us to phase out master eventually.
> * A user with the new plugin will get "1.X-stable" for any branch we
> have created
> * A user with the new plugin will get "develop" if using foreman-nightly
>
> I think that's all the use cases, and seems a sane set of defaults.
> Obviously, a user can override the repo if need be, as well.
>
> Thoughts?
Some more thoughts in the PR.
···
On Thu, Mar 12, 2015 at 02:48:11AM +0000, Greg Sutcliffe wrote:
I agree it's not ideal, but I don't have a better transition strategy.
I'd suggest it's short-term only, while (a) the 1.X-stable branches
are created, and (b) the new version of the plugin gets adopted. Once
we're happy with the setup, we change the default branch to develop,
as users on released Foreman versions will get 1.X-stable. We can then
delete master once we believe the majority of people have upgraded.
In the meantime, we may just have to keep telling people where to
submit their changes. Readme will help, but also the fact that the PR
they want to send can't be written against master may be a clue
Greg
···
On 12 March 2015 at 08:10, Dominic Cleal wrote:
> I don't really have a better suggestion, but I'm concerned that if we
> leave the branch on master then people contributing to the repo will
> simply not notice and continue to submit PRs there... we might be able
> to alleviate it slightly with a large notice in the README, but you know
> often people read those.
You can change the default branch in github. Maybe that could help?
···
On Thu, Mar 12, 2015 at 08:10:32AM +0000, Dominic Cleal wrote:
> On 12/03/15 02:48, Greg Sutcliffe wrote:
> > Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
> >
> > * "master" - current default branch. Leave it as the default for now,
> > use it for basic templates that should work on any version of older
> > Foreman version
> > * "develop" - latest version of templates, to be sync'd to foreman-nightly
>
> I don't really have a better suggestion, but I'm concerned that if we
> leave the branch on master then people contributing to the repo will
> simply not notice and continue to submit PRs there... we might be able
> to alleviate it slightly with a large notice in the README, but you know
> often people read those.
I think Greg's reasoning is that existing versions of foreman_templates
will follow the default branch, so a 1.7 user with foreman_templates
1.4.0 may suddenly get 1.9 templates if they don't update the plugin.
···
On 12/03/15 10:22, Ewoud Kohl van Wijngaarden wrote:
> On Thu, Mar 12, 2015 at 08:10:32AM +0000, Dominic Cleal wrote:
>> On 12/03/15 02:48, Greg Sutcliffe wrote:
>>> Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
>>>
>>> * "master" - current default branch. Leave it as the default for now,
>>> use it for basic templates that should work on any version of older
>>> Foreman version
>>> * "develop" - latest version of templates, to be sync'd to foreman-nightly
>>
>> I don't really have a better suggestion, but I'm concerned that if we
>> leave the branch on master then people contributing to the repo will
>> simply not notice and continue to submit PRs there... we might be able
>> to alleviate it slightly with a large notice in the README, but you know
>> often people read those.
>
> You can change the default branch in github. Maybe that could help?
> I think Greg's reasoning is that existing versions of foreman_templates
> will follow the default branch, so a 1.7 user with foreman_templates
> 1.4.0 may suddenly get 1.9 templates if they don't update the plugin.
Exactly so. Once enough time has passed, I'm +1 for changing the
branch default to 'develop'.
···
On 12 March 2015 at 11:31, Dominic Cleal wrote:
···
On Thu, Mar 12, 2015 at 11:31:26AM +0000, Dominic Cleal wrote:
> On 12/03/15 10:22, Ewoud Kohl van Wijngaarden wrote:
> > On Thu, Mar 12, 2015 at 08:10:32AM +0000, Dominic Cleal wrote:
> >> On 12/03/15 02:48, Greg Sutcliffe wrote:
> >>> Ok, so [1] is open for handing this, Ewoud. If we assume this structure:
> >>>
> >>> * "master" - current default branch. Leave it as the default for now,
> >>> use it for basic templates that should work on any version of older
> >>> Foreman version
> >>> * "develop" - latest version of templates, to be sync'd to foreman-nightly
> >>
> >> I don't really have a better suggestion, but I'm concerned that if we
> >> leave the branch on master then people contributing to the repo will
> >> simply not notice and continue to submit PRs there... we might be able
> >> to alleviate it slightly with a large notice in the README, but you know
> >> often people read those.
> >
> > You can change the default branch in github. Maybe that could help?
>
> I think Greg's reasoning is that existing versions of foreman_templates
> will follow the default branch, so a 1.7 user with foreman_templates
> 1.4.0 may suddenly get 1.9 templates if they don't update the plugin.
···
On Thu, Mar 12, 2015 at 11:36:19AM +0000, Greg Sutcliffe wrote:
> On 12 March 2015 at 11:09, Ewoud Kohl van Wijngaarden > wrote:
> >> * "1.7-stable" - templates for 1.7
> >> * "1.8-stable" - templates for 1.8
> >
> > I'd prefer just 1.7 or foreman-1.7. stable implies it can't be used for
> > RCs and I see no reason not to.
>
> RCs are created from the 1.X-stable branches in core too. Consistency++ :)
