Versioning foreman-rpms

Development
1

Hi,

We currently don't version the foreman-rpms repo, but I think we should probably start doing so. It's hard to find the right commit to use if we need to go back and rebuild packages or revert. I think the ideal workflow is:

  1. Commit changes until everything for the release is committed.
  2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5)
  3. Have Jenkins build stable/RC packages from that tag.

Does this workflow make sense?

2

Works for me. That said, does it make sense to rebuild old packages with
old bugs in them?

··· On 11 February 2013 14:09, Sam Kottler wrote:

Hi,

We currently don’t version the foreman-rpms repo, but I think we should
probably start doing so. It’s hard to find the right commit to use if we
need to go back and rebuild packages or revert. I think the ideal workflow
is:

  1. Commit changes until everything for the release is committed.
  2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5)
  3. Have Jenkins build stable/RC packages from that tag.

Does this workflow make sense?

3

FYI there is this nice tool called tito (in Fedora already) which
greatly helps you avoiding making rel-eng mistakes:

LZ

··· On Mon, Feb 11, 2013 at 09:09:19AM -0500, Sam Kottler wrote: > Hi, > > We currently don't version the foreman-rpms repo, but I think we should probably start doing so. It's hard to find the right commit to use if we need to go back and rebuild packages or revert. I think the ideal workflow is: > > 1. Commit changes until everything for the release is committed. > 2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5) > 3. Have Jenkins build stable/RC packages from that tag. > > Does this workflow make sense? > > -- > 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/groups/opt_out. > >

–
Later,

Lukas “lzap” Zapletal
#katello #systemengine

4

There may be times when we will need to backport bug fixes and cut newer tags, but since we rebuild old packages fairly rarely it probably isn't all that much of an issue from what I've seen.

··· ----- Original Message ----- From: "Greg Sutcliffe" To: "Foreman ." Sent: Monday, February 11, 2013 10:31:15 AM Subject: Re: [foreman-dev] Versioning foreman-rpms

On 11 February 2013 14:09, Sam Kottler < skottler@redhat.com > wrote:

Hi,

We currently don’t version the foreman-rpms repo, but I think we should probably start doing so. It’s hard to find the right commit to use if we need to go back and rebuild packages or revert. I think the ideal workflow is:

  1. Commit changes until everything for the release is committed.
  2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5)
  3. Have Jenkins build stable/RC packages from that tag.

Does this workflow make sense?

Works for me. That said, does it make sense to rebuild old packages with old bugs in them?

–
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/groups/opt_out .

5

> FYI there is this nice tool called tito (in Fedora already) which
> greatly helps you avoiding making rel-eng mistakes:
>
> https://github.com/dgoodwin/tito
>
> LZ
>

+1 for tito. It forces the exact workflow you mentioned, and the only
"downside" is it forces a particular directory structure. However, that
is pretty minimal. If I recall, it supports releasing to file system,
koji, and a few others.

A cool thing would be to get tito to do debs as well as rpms.

– bk

··· On 02/13/2013 07:21 AM, Lukas Zapletal wrote:

On Mon, Feb 11, 2013 at 09:09:19AM -0500, Sam Kottler wrote:

Hi,

We currently don’t version the foreman-rpms repo, but I think we should probably start doing so. It’s hard to find the right commit to use if we need to go back and rebuild packages or revert. I think the ideal workflow is:

  1. Commit changes until everything for the release is committed.
  2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5)
  3. Have Jenkins build stable/RC packages from that tag.

Does this workflow make sense?

–
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/groups/opt_out.

6

Yep, I've been meaning to try it out for a while. We don't keep the release
engineering files in the main repository, but it's easy to script pulling
those in and setting up the directory structure. Thanks guys!

-S

··· On Wed, Feb 13, 2013 at 8:01 AM, Bryan Kearney wrote:

On 02/13/2013 07:21 AM, Lukas Zapletal wrote:

FYI there is this nice tool called tito (in Fedora already) which
greatly helps you avoiding making rel-eng mistakes:

https://github.com/dgoodwin/**tito https://github.com/dgoodwin/tito

LZ

+1 for tito. It forces the exact workflow you mentioned, and the only
"downside" is it forces a particular directory structure. However, that is
pretty minimal. If I recall, it supports releasing to file system, koji,
and a few others.

A cool thing would be to get tito to do debs as well as rpms.

– bk

On Mon, Feb 11, 2013 at 09:09:19AM -0500, Sam Kottler wrote:

Hi,

We currently don’t version the foreman-rpms repo, but I think we should
probably start doing so. It’s hard to find the right commit to use if we
need to go back and rebuild packages or revert. I think the ideal workflow
is:

  1. Commit changes until everything for the release is committed.
  2. Cut a tag with the version (i.e. 1.1stable or 1.1RC5)
  3. Have Jenkins build stable/RC packages from that tag.

Does this workflow make sense?

–
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.comforeman-dev%2Bunsubscribe@googlegroups.com
.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

–
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.comforeman-dev%2Bunsubscribe@googlegroups.com
.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

7

So… it will force you do keep them in the same tree. As a point of
process, i think that makes sense. You want the tag to be everything you
need to recreate the packages.
– bk

··· On 02/13/2013 09:09 AM, Sam Kottler wrote: > Yep, I've been meaning to try it out for a while. We don't keep the > release engineering files in the main repository, but it's easy to > script pulling those in and setting up the directory structure. Thanks guys! > > -S
8

Maybe I should take a look…

··· On 13 February 2013 13:01, Bryan Kearney wrote:

On 02/13/2013 07:21 AM, Lukas Zapletal wrote:

https://github.com/dgoodwin/**tito https://github.com/dgoodwin/tito

A cool thing would be to get tito to do debs as well as rpms.

9

Tito allows even a manager to do the release :slight_smile:
– bk

··· On 02/13/2013 09:12 AM, Greg Sutcliffe wrote: > > On 13 February 2013 13:01, Bryan Kearney > wrote: > > On 02/13/2013 07:21 AM, Lukas Zapletal wrote: > > https://github.com/dgoodwin/__tito > > > A cool thing would be to get tito to do debs as well as rpms. > > > Maybe I should take a look.... >