9:50 a.m.
The current repo layout will have to change some to support the 3.1
release that might be happening on the 25th. We are going to have to
move stuff around to archive the 3.0 release as well as setup the 3.1
release in my option we can do it one of two ways. 1) Create an archive
folder and just copy 3.0 to it well we do the 3.1 release and keep the
same structure we have now. 2) Redo the layout to something that will
long term support version and be less confusing to people using the project.
Personally I think this is a good time to redesign. The existing 3.0
repo files are going to break when we move things around for the 3.1
release and we are going to need to make sure everything is in place.
Since we are going to have to disrupt thing already why not do a full
clean-up instead of just patch the current layout. Our current layout.
release/[stable|beta|nightly]/[binary|fedora|RHEL|src]/[16|17|18]
I recommend we switching to the following structure.
release/[3.0|3.1|3.2|stable|testing]/[nightly|beta|released]/[tools|fedora|RHEL|src]/[16|17|18|rawhide]
With symlinks for stable and testing point to the current version for
each. I also suggest a symlink called release/fedora-ovirt-latest.rpm
that points to the latest ovirt-release-*.rpm file.
Inside each version there will be a repo file that enables released
disables beta & nightly.
Since each repo file will simple reference everything by version number
each new release wont break old releases.
What does everyone think?
Thanks
Robert
12:54 a.m.
----- Original Message -----
From: "Robert Middleswarth"
<robert(a)middleswarth.net>
To: "infra" <infra(a)ovirt.org>
Sent: Friday, July 20, 2012 5:50:02 PM
Subject: Repo layout. We really need to make the call by Tuesday 2012/7/24.
The current repo layout will have to change some to support the 3.1
release that might be happening on the 25th. We are going to have to
move stuff around to archive the 3.0 release as well as setup the 3.1
release in my option we can do it one of two ways. 1) Create an
archive
folder and just copy 3.0 to it well we do the 3.1 release and keep
the
same structure we have now. 2) Redo the layout to something that
will
long term support version and be less confusing to people using the
project.
Personally I think this is a good time to redesign. The existing 3.0
repo files are going to break when we move things around for the 3.1
release and we are going to need to make sure everything is in place.
Since we are going to have to disrupt thing already why not do a full
clean-up instead of just patch the current layout. Our current
layout.
release/[stable|beta|nightly]/[binary|fedora|RHEL|src]/[16|17|18]
I recommend we switching to the following structure.
release/[3.0|3.1|3.2|stable|testing]/[nightly|beta|released]/[tools|fedora|RHEL|src]/[16|17|18|rawhide]
i don't see the reason for 'stable|testing' dir in the version section.
i recommend:
release/$VERSION/$RELEASE-STATE/$OS/$OS_VER/$TYPE
$VERSION = 3.0,3.1,3.X
$RELEASE-STATE = released/beta/nightly
$OS = Fedora, RHEL, Ubunto, RHEVH
$OS_VERSION = 16,17,6.2,6,3
$TYPE = binary, src, tools
examples -> this is where jenkins will deploy nightly rpms:
release/3.1/nightly/fedora/17/[src | binary | tools]
i imagine that we'll deploy beta/release version manually when needed.
With symlinks for stable and testing point to the current version for
each. I also suggest a symlink called
release/fedora-ovirt-latest.rpm
that points to the latest ovirt-release-*.rpm file.
not sure why this is needed and how we will update these sym links all the time ( manually
?)
people should know that d/l rpms from the 'stable' directory will give them stable
release,
question is if we put more than one version or nighties in the unstable dir, or just the
latest..
if we're keeping versions back then:
1. how many
2. need a cleaner to delete old version
3. keeping all version in a single yum repo is common practise?
Inside each version there will be a repo file that enables released
disables beta & nightly.
Since each repo file will simple reference everything by version
number
each new release wont break old releases.
What does everyone think?
Thanks
Robert
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
1:29 a.m.
New subject: Repo layout. We really need to make the call by Tuesday 2012/7/24.
On 07/23/2012 01:54 AM, Eyal Edri wrote:
----- Original Message -----
> From: "Robert Middleswarth" <robert(a)middleswarth.net>
> To: "infra" <infra(a)ovirt.org>
> Sent: Friday, July 20, 2012 5:50:02 PM
> Subject: Repo layout. We really need to make the call by Tuesday 2012/7/24.
>
> The current repo layout will have to change some to support the 3.1
> release that might be happening on the 25th. We are going to have to
> move stuff around to archive the 3.0 release as well as setup the 3.1
> release in my option we can do it one of two ways. 1) Create an
> archive
> folder and just copy 3.0 to it well we do the 3.1 release and keep
> the
> same structure we have now. 2) Redo the layout to something that
> will
> long term support version and be less confusing to people using the
> project.
>
> Personally I think this is a good time to redesign. The existing 3.0
> repo files are going to break when we move things around for the 3.1
> release and we are going to need to make sure everything is in place.
> Since we are going to have to disrupt thing already why not do a full
> clean-up instead of just patch the current layout. Our current
> layout.
>
> release/[stable|beta|nightly]/[binary|fedora|RHEL|src]/[16|17|18]
>
> I recommend we switching to the following structure.
>
>
release/[3.0|3.1|3.2|stable|testing]/[nightly|beta|released]/[tools|fedora|RHEL|src]/[16|17|18|rawhide]
i don't see the reason for 'stable|testing' dir in the version section.
They would just be convent links to the current release and testing
releases. Right now stable would point at 3.0 and testing would point
at 3.1. Assuming 3.1 gets released on the 25th then the links would be
updated so stable would point at 3.1 and testing would point at 3.2
i recommend:
release/$VERSION/$RELEASE-STATE/$OS/$OS_VER/$TYPE
$VERSION = 3.0,3.1,3.X
$RELEASE-STATE = released/beta/nightly
$OS = Fedora, RHEL, Ubunto, RHEVH
$OS_VERSION = 16,17,6.2,6,3
$TYPE = binary, src, tools
Agree with the structure. Pretty much what I was
recommending.
examples -> this is where jenkins will deploy nightly rpms:
release/3.1/nightly/fedora/17/[src | binary | tools]
My with the engine branched
nightly should be called 3.2 not 3.1 since
they are master. Although in theory would could have a folder called
master and one for each release?
i imagine that we'll deploy beta/release version manually when
needed.
I would actually prefer that we get the beta and release processes into
Jenkins and have Jenkins handle the beta and release builds it will make
it easier to push out releases without someone from the infra team
required to make anything happen.
> With symlinks for stable and testing point to the current version for
> each. I also suggest a symlink called
> release/fedora-ovirt-latest.rpm
> that points to the latest ovirt-release-*.rpm file.
>
The idea is to create one place the documentation can link to that will
update over time without having to update the documentation.
not sure why this is needed and how we will update these sym links
all the time ( manually ?)
people should know that d/l rpms from the 'stable' directory will give them
stable release,
question is if we put more than one version or nighties in the unstable dir, or just the
latest..
if we're keeping versions back then:
1. how many
I was thinking a few days worth. Sometime it helps to keep a few days
worth in case something goes wrong with the create repo.
2. need a cleaner to delete old version
Yes. We need a way to
clean up old builds.
3. keeping all version in a single yum repo is common practise?
? All Versions of oVirt? Or all OS versions?
> Inside each version there will be a repo file that enables
released
> disables beta & nightly.
>
> Since each repo file will simple reference everything by version
> number
> each new release wont break old releases.
>
> What does everyone think?
>
> Thanks
> Robert
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
4288
days inactive
4291
days old
2 comments
2 participants
participants (2)
-
Eyal Edri -
Robert Middleswarth