So, I think its time spot updated: http://fedoraproject.org/wiki/PackagingGuidelines
Just to mention to packagers how cvs/svn/arch checkouts are to be packaged. Some software never gets released (think say, Planet), and it'd be a good idea that folk had the proper way to package things
So 0.0.`date` (of course make sure that date is not an escaped one, I'm just being lazy here to write todays date) and a little note about the fact that it came outta cvs/etc... would be good
Thanks
On Wed, 2005-05-11 at 14:01 +1000, Colin Charles wrote:
So, I think its time spot updated: http://fedoraproject.org/wiki/PackagingGuidelines
Just to mention to packagers how cvs/svn/arch checkouts are to be packaged. Some software never gets released (think say, Planet), and it'd be a good idea that folk had the proper way to package things
So 0.0.`date` (of course make sure that date is not an escaped one, I'm just being lazy here to write todays date) and a little note about the fact that it came outta cvs/etc... would be good
Is there any precedent for this in FC (or in old fedora.us, or anywhere else)?
Basically, do I need to invent this standard from the ground up, or is there some existing standard that just needs to be documented?
Feedback is welcomed.
~spot
On Sun, 15 May 2005 12:02:00 -0500, Tom 'spot' Callaway wrote:
On Wed, 2005-05-11 at 14:01 +1000, Colin Charles wrote:
So, I think its time spot updated: http://fedoraproject.org/wiki/PackagingGuidelines
Just to mention to packagers how cvs/svn/arch checkouts are to be packaged. Some software never gets released (think say, Planet), and it'd be a good idea that folk had the proper way to package things
So 0.0.`date` (of course make sure that date is not an escaped one, I'm just being lazy here to write todays date) and a little note about the fact that it came outta cvs/etc... would be good
Is there any precedent for this in FC (or in old fedora.us, or anywhere else)?
Basically, do I need to invent this standard from the ground up, or is there some existing standard that just needs to be documented?
Feedback is welcomed.
Fedora.us' vepoch concept, which means to move the most significant part of %version-%release into the release tag and place any less significant portions to the right of it, e.g.:
fontforge-0.0-2.20050310.fc4.i386.rpm ^ http_ping-0.0-3.20020403.i386.rpm ^ libuninameslist-0.0-3.040707.i386.rpm ^ openal-0.0-0.3.20040726.i386.rpm ^^^
Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the first release of a program. Instead, move the snapshot date into the release tag.
On Sun, 2005-05-15 at 19:12 +0200, Michael Schwendt wrote:
Fedora.us' vepoch concept, which means to move the most significant part of %version-%release into the release tag and place any less significant portions to the right of it, e.g.:
fontforge-0.0-2.20050310.fc4.i386.rpm ^ http_ping-0.0-3.20020403.i386.rpm ^ libuninameslist-0.0-3.040707.i386.rpm ^ openal-0.0-0.3.20040726.i386.rpm ^^^
Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the first release of a program. Instead, move the snapshot date into the release tag.
So, under current guidelines, that would basically mean:
# cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # Increment first digit of release if making a change without new source # checkout, if new source checkout, reset to 1. Release: 1.%cvsdate%{?dist}
Does that seem reasonable?
~spot
On Sun, 15 May 2005 12:24:43 -0500, Tom 'spot' Callaway wrote:
On Sun, 2005-05-15 at 19:12 +0200, Michael Schwendt wrote:
Fedora.us' vepoch concept, which means to move the most significant part of %version-%release into the release tag and place any less significant portions to the right of it, e.g.:
fontforge-0.0-2.20050310.fc4.i386.rpm ^ http_ping-0.0-3.20020403.i386.rpm ^ libuninameslist-0.0-3.040707.i386.rpm ^ openal-0.0-0.3.20040726.i386.rpm ^^^
Don't use 0.0.`date` as it would be larger than 0.0.1, which could be the first release of a program. Instead, move the snapshot date into the release tag.
So, under current guidelines, that would basically mean:
# cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # Increment first digit of release if making a change without new source # checkout, if new source checkout, reset to 1. Release: 1.%cvsdate%{?dist}
Does that seem reasonable?
Yes, IMO.
For snapshots of software with a previous release, i.e. with a real % version, the string "cvs" or "svn" after cvsdate in the release field would make it more clear that it's a post-release snapshot.
On Sun, May 15, 2005 at 10:52:23PM +0200, Michael Schwendt wrote:
So, under current guidelines, that would basically mean: # cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # Increment first digit of release if making a change without new source # checkout, if new source checkout, reset to 1. Release: 1.%cvsdate%{?dist} Does that seem reasonable?
Yes, IMO. For snapshots of software with a previous release, i.e. with a real % version, the string "cvs" or "svn" after cvsdate in the release field would make it more clear that it's a post-release snapshot.
So:
Release: 1.cvs%{cvsdate}%{?dist}
On Sun, 2005-05-15 at 22:52 +0200, Michael Schwendt wrote:
So, under current guidelines, that would basically mean:
# cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # Increment first digit of release if making a change without new source # checkout, if new source checkout, reset to 1. Release: 1.%cvsdate%{?dist}
Does that seem reasonable?
Yes, IMO.
For snapshots of software with a previous release, i.e. with a real % version, the string "cvs" or "svn" after cvsdate in the release field would make it more clear that it's a post-release snapshot.
This is ok, its a logical extension of the "Non-Numeric Version in Release" in PackageNamingGuidelines. We should come up with standardized naming for the common version control systems ("cvs", "svn", "bk", "git", "arch"). If there are no objections, I'll just use the ones in the previous line. :)
Of course, this raises a few more issues:
Strictly speaking, as this falls under the "Non-Numeric Version in Release" case, we should have a preceeding 0.
This changes the example case to:
# cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # When the checkout is for a "pre-release", prepend with "0." # The build digit starts at 1, and increments if making a change # without new source checkout. If there is a new source checkout, reset # the second digit to 1. Release: 0.1.%{cvsdate}cvs%{?dist}
foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.0-1.20050514cvs.noarch.rpm (post-release cvs co)
The problem is that 1.20050514cvs < 2, when it should be considered as greater.
One possible workaround would be to increment the version number.
With this, we'd have: foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.1-1.20050514cvs.noarch.rpm (post-release cvs co) foo-1.1-2.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
The problem with this solution is that we're relying on the psychic abilities of the packager to guess the next release version. For some packages, this may be possible (they bump version number early in the source), but its a risky bet, since they could just as easily call the next release 1.01. Then we have to use Epoch, and the end user remains confused as to how foo-1.1 < foo-1.01.
Another workaround would be to use the value of the highest %{release} number from the stable release as the new "build digit".
With this, we'd have: foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.0-2.20050514cvs.noarch.rpm (post-release cvs co) foo-1.0-3.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
I'm inclined to document the latter option as the standard, but I'm open to advice/alternatives here.
~spot
On Sun, 15 May 2005 17:43:46 -0500, Tom 'spot' Callaway wrote:
Of course, this raises a few more issues:
Strictly speaking, as this falls under the "Non-Numeric Version in Release" case, we should have a preceeding 0.
This changes the example case to:
# cvsdate should be in the format YYYYMMDD %define cvsdate 20050515 # 0.0 is used for applications that do not have a proper version number. Version: 0.0 # When the checkout is for a "pre-release", prepend with "0." # The build digit starts at 1, and increments if making a change # without new source checkout. If there is a new source checkout, reset # the second digit to 1. Release: 0.1.%{cvsdate}cvs%{?dist}
Why? 0.0 is not the expected version of the final/stable release. So a "0." prefix in %release is not needed and doesn't make sense either.
Only if %version is at final version already and if you want to keep non-numerical parts, like "rc" or "alpha", outside %version, you move them into %release and use a prefix, so the final release can start at 1.
foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.0-1.20050514cvs.noarch.rpm (post-release cvs co)
The problem is that 1.20050514cvs < 2, when it should be considered as greater.
This is a problem not limited to comparing stable releases with snapshots. It's a pretty ordinary case. Assume you have:
foo-1.0-1.fc3.i386.rpm (stable release) foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)
and then:
foo-1.0-2.fc3.i386.rpm (first erratum) * foo-1.0-3.fc3.i386.rpm (second erratum)
The one with '*' is newer than the .fc4 snapshot. Compare that with a .fc4 package, which has a cvs co diff applied as patch and is not marked as a snapshot in %release:
foo-1.0-1.fc3.i386.rpm (stable release) foo-1.0-2.fc4.i386.rpm (post-release cvs changes applied as patch)
foo-1.0-2.fc3.i386.rpm (first erratum) * foo-1.0-3.fc3.i386.rpm (second erratum)
If the .fc4 cvs snapshot doesn't need an update, you get the same problems. Dist tags don't help in that case either. They only help for updates applied to multiple distribution versions at once.
Whenever you bump %release only on an older branch, you increase the likelihood that you violate the distribution upgrade path.
This can also happen if you have use an older cvs snapshot for FC3 and a recent one for FC4,
foo-0.0-1.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
and if you need to fix a security bug in the old snapshot and you can't upgrade to latest cvs co because build requirements are insufficient, you run into %release conflicts again:
* foo-0.0-2.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
One possible workaround would be to increment the version number.
With this, we'd have: foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.1-1.20050514cvs.noarch.rpm (post-release cvs co) foo-1.1-2.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
The problem with this solution is that we're relying on the psychic abilities of the packager to guess the next release version.
Exactly. And you could never go back to an older stable release in case you found major problems in the CVS changes. However:
foo-1.0-3.20050114cvs.fc4.noarch.rpm foo-1.0-4.fc4.noarch.rpm (revert to last stable release as last resort)
Another workaround would be to use the value of the highest %{release} number from the stable release as the new "build digit".
With this, we'd have: foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.0-2.20050514cvs.noarch.rpm (post-release cvs co) foo-1.0-3.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
I'm inclined to document the latter option as the standard, but I'm open to advice/alternatives here.
That is no silver bullet either. A second bugfix to the stable release, and you would get into trouble again. Why not just increase release in the context of all current packages?
fc3: foo-1.0-1.noarch.rpm (stable release) foo-1.0-1.2.noarch.rpm (bugfix to stable release) foo-1.0-1.3.noarch.rpm (security fix to stable release)
fc4: foo-1.0-2.20041225cvs.noarch.rpm (post-release cvs co)
Later for fc4: foo-1.0-3.20050301cvs.noarch.rpm (post-release cvs co) foo-1.0-4.20050514cvs.noarch.rpm (post-release cvs co) foo-1.0-5.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
Won't solve conflicts magically either, return to "bump most significant portion of %release with every package release, only reset to 1 if %version is increased." And if you need to bump %release only for an older distribution, avoid that the most significant part would be higher or equal than any package for a newer distribution. Extend integer release values to floating-point as a last resort, e.g. 1.fc3 < 1.2.fc3 < 1.3.fc3 < 2.20050514.fc4
Just like the versioning scheme for snapshots, the scheme for pre-releases is only to avoid unnecessary epoch bumps. Mixed with dist tags, it can get funny...
On Mon, 2005-05-16 at 02:32 +0200, Michael Schwendt wrote:
foo-1.0-1.fc3.i386.rpm (stable release) foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)
These two packages will never compare, unless you're doing a dist upgrade. But I'll assume you meant .fc3 for both rpms.
If the .fc4 cvs snapshot doesn't need an update, you get the same problems. Dist tags don't help in that case either. They only help for updates applied to multiple distribution versions at once.
Whenever you bump %release only on an older branch, you increase the likelihood that you violate the distribution upgrade path.
Then you have to bump it on both. We have to enforce that n-v-r of the previous current branch must be less than the current branch, if we want to be able to do upgrades. This is true with or without disttags.
This can also happen if you have use an older cvs snapshot for FC3 and a recent one for FC4,
foo-0.0-1.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
Well, no. In this case, the fc4 package is newer according to rpm. No conflict in each branch, no conflict on dist upgrade. The conflict only arises when you bump the FC-3 branch release, without bumping the FC-4 branch.
and if you need to fix a security bug in the old snapshot and you can't upgrade to latest cvs co because build requirements are insufficient, you run into %release conflicts again:
- foo-0.0-2.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
Again, this problem is avoided if both branches are incremented together.
The golden rule is that for supported release branches (not in devel), the packages in the most recent branch must be greater in n-v-r than the branch before it (and the branch before that, in the 3 supported release case). I know we're trying to keep the buildsystem dumb, but we might have to check for this at buildtime.
This is a problem that the cvs dates are overcomplicating.
If you have this package in FC-3:
foo-1.0-3.fc3.noarch.rpm
Then, your FC-4 package should have a higher n-v-r. If the v is the same, then the r has to be higher. With dist tags, you can have:
foo-1.0-3.fc4.noarch.rpm
Which is higher, and requires only that the release number be consistent between the branches. When you errata either, you bump both release numbers. Realistically speaking, the probability of both branches having the same n-v but not needing the same fix is slim, so this isn't a terrible requirement in my mind.
Without dist tags, in the FC-3 branch you'd have:
foo-1.0-3.noarch.rpm
And you'd need this in the FC-4 branch:
foo-1.0-4.noarch.rpm
Which causes problems if you have to errata the FC-3 branch, causing you to leapfrog to 5 (and then 6 in the FC-4 branch).
Either methodology will require rebuilds of both branches. Using dist tags keeps the numbers lower.
Another workaround would be to use the value of the highest %{release} number from the stable release as the new "build digit".
With this, we'd have: foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co) foo-1.0-1.noarch.rpm (stable release) foo-1.0-2.noarch.rpm (bugfix to stable release) foo-1.0-2.20050514cvs.noarch.rpm (post-release cvs co) foo-1.0-3.20050514cvs.noarch.rpm (bugfix to post-release cvs co)
I'm inclined to document the latter option as the standard, but I'm open to advice/alternatives here.
That is no silver bullet either. A second bugfix to the stable release, and you would get into trouble again. Why not just increase release in the context of all current packages?
I was presenting this case in a single branch. This only works if the golden rule above is followed.
The trick is making a packaging standard which makes it easy to follow the golden rule, and difficult not to.
Lets put the CVS case aside for a minute and try to figure out how to do this for the "normal" case first.
~spot
On Sun, 15 May 2005 20:40:11 -0500, Tom 'spot' Callaway wrote:
On Mon, 2005-05-16 at 02:32 +0200, Michael Schwendt wrote:
foo-1.0-1.fc3.i386.rpm (stable release) foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)
These two packages will never compare, unless you're doing a dist upgrade. But I'll assume you meant .fc3 for both rpms.
No, I didn't mean .fc3 for both rpms.
If the .fc4 cvs snapshot doesn't need an update, you get the same problems. Dist tags don't help in that case either. They only help for updates applied to multiple distribution versions at once.
Whenever you bump %release only on an older branch, you increase the likelihood that you violate the distribution upgrade path.
Then you have to bump it on both. We have to enforce that n-v-r of the previous current branch must be less than the current branch, if we want to be able to do upgrades. This is true with or without disttags.
No, it isn't. Surely you can avoid the necessity to bump release for all branches.
This can also happen if you have use an older cvs snapshot for FC3 and a recent one for FC4,
foo-0.0-1.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
Well, no. In this case, the fc4 package is newer according to rpm. No conflict in each branch, no conflict on dist upgrade. The conflict only arises when you bump the FC-3 branch release, without bumping the FC-4 branch.
No. Read the rest of that example, the part that starts with "and ...". With your plan I would bump the .fc4 package just for fun? That can't be true.
and if you need to fix a security bug in the old snapshot and you can't upgrade to latest cvs co because build requirements are insufficient, you run into %release conflicts again:
- foo-0.0-2.20040903cvs.fc3.i386.rpm foo-0.0-1.20050514cvs.fc4.i386.rpm
Again, this problem is avoided if both branches are incremented together.
Why? My example explains it. If there is no need to update the .fc4 package, why bump it? In this case, it's clearly more convenient to extend the first number in %release from integer to real number.
Lets put the CVS case aside for a minute and try to figure out how to do this for the "normal" case first.
The CVS case--and the general case of a src.rpm which applies a set of patches, regardless of whether from CVS--is an important one. It leads to cases, where you may need to bump release only for one branch, because the other branches don't need an update. To assume that every bug-fix update is released for all distribution branches, is a false assumption. There are competing and conflicting versioning schemes.
On Mon, 2005-05-16 at 12:03 +0200, Michael Schwendt wrote:
No, it isn't. Surely you can avoid the necessity to bump release for all branches.
Upon rereading your original mail, I still don't see how this is avoided. Can you help me understand how the following test cases would work:
(Assume that FC-3 and FC-4 are current, FC-5 in devel. Also keep in mind the aforementioned Golden Rule, that packages in FC-3 < FC-4)
1. The Normal Case
In the FC-3 repo, you have:
foo-1.0-1.noarch.rpm
In the FC-4 repo, you have:
foo-1.0-2.noarch.rpm
You need to errata the FC-3 repo.
2. The CVS Case (disconnected)
In the FC-3 repo, you start with:
foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
In FC-4, you need a later checkout:
foo-0.0-1.20050515.noarch.com
The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4 does not.
3. The CVS Case (same source)
In the FC-3 repo, you start with:
foo-0.0-1.20050515.noarch.com
You use the same cvs co for the FC-4 repo:
foo-0.0-1.20050515.noarch.com
Resolve the conflict in naming between branches, and perform an FC-3 only package errata.
(Note that I have avoided dist tag usage on purpose to avoid "complicating" the issue, but if they're useful in your solutions, feel free to reintroduce them here)
Thanks in advance,
~spot
On Mon, 16 May 2005 08:28:05 -0500, Tom 'spot' Callaway wrote:
On Mon, 2005-05-16 at 12:03 +0200, Michael Schwendt wrote:
No, it isn't. Surely you can avoid the necessity to bump release for all branches.
Upon rereading your original mail, I still don't see how this is avoided. Can you help me understand how the following test cases would work:
(Assume that FC-3 and FC-4 are current, FC-5 in devel. Also keep in mind the aforementioned Golden Rule, that packages in FC-3 < FC-4)
- The Normal Case
In the FC-3 repo, you have:
foo-1.0-1.noarch.rpm
In the FC-4 repo, you have:
foo-1.0-2.noarch.rpm
You need to errata the FC-3 repo.
First of all, more normal would be that the FC-4 package suffers from the same defects than the FC-3 package, so both branches need an update. In that case it's a scenario where dist tags make sense.
If however you really mean that no erratum for FC-4 is needed, you would not bump its release just make your "golden rule" happy, but instead keep the FC-3 erratum "older than" the latest FC-4 package:
foo-1.0-1.noarch.rpm (FC-3) => foo-1.0-1.2.noarch.rpm (erratum for FC-3)
- The CVS Case (disconnected)
In the FC-3 repo, you start with:
foo-0.0-1.20050315.noarch.com (pre-release cvs checkout)
In FC-4, you need a later checkout:
foo-0.0-1.20050515.noarch.com
The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4 does not.
This is my earlier example. Solution as above:
foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
- The CVS Case (same source)
In the FC-3 repo, you start with:
foo-0.0-1.20050515.noarch.com
You use the same cvs co for the FC-4 repo:
foo-0.0-1.20050515.noarch.com
Resolve the conflict in naming between branches, and perform an FC-3 only package errata.
Same as 1.
The example is flawed, because it violates your golden rule already prior to the needed erratum.
(Note that I have avoided dist tag usage on purpose to avoid "complicating" the issue, but if they're useful in your solutions, feel free to reintroduce them here)
Thanks in advance,
Dist tags don't help in these cases, since they are the least significant portion of EVR and don't add any value if you bump the most significant portion of Release only on an older branch.
[...]
We can continue to collect and examine problematic cases and possible solutions for them. E.g. ways to avoid Epoch inflation. But I'm inclined to say that the search for an ultimate versioning scheme would only result in a document much more complex than fedora.us' old versioning scheme.
On Mon, May 16, 2005 at 05:43:53PM +0200, Michael Schwendt wrote:
In the FC-3 repo, you start with: foo-0.0-1.20050315.noarch.com (pre-release cvs checkout) In FC-4, you need a later checkout: foo-0.0-1.20050515.noarch.com The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4 does not.
This is my earlier example. Solution as above: foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
Except, isn't that *older* than foo-0.0-1.20050315? (2 < 20050315)?
On Mon, 16 May 2005 12:32:27 -0400, Matthew Miller wrote:
On Mon, May 16, 2005 at 05:43:53PM +0200, Michael Schwendt wrote:
In the FC-3 repo, you start with: foo-0.0-1.20050315.noarch.com (pre-release cvs checkout) In FC-4, you need a later checkout: foo-0.0-1.20050515.noarch.com The FC-3 package needs a bugfix errata, without new cvs checkout. FC-4 does not.
This is my earlier example. Solution as above: foo-0.0-1.2.20050315.noarch.com (fixed pre-release cvs checkout)
Except, isn't that *older* than foo-0.0-1.20050315? (2 < 20050315)?
Yes, .2 inserted in the wrong place. In the context of above scenario:
FC-3: foo-0.0-1.20050315.noarch.rpm FC-4: foo-0.0-1.20050515.noarch.rpm
FC-3 => foo-0.0-1.20050315.2.noarch.rpm
The leading 1. is most-significant here to overrule the snapshot date, so an update to 1.20050315 would be created by appending a least-significant digit.
packaging@lists.fedoraproject.org
-
Colin Charles -
Matthew Miller -
Michael Schwendt -
Tom Callaway