[Fwd: Re: Virtual build environments]

[Lucas Albers]

Forwarded from freshrpms.
Have we started thinking about what build method we will use.
Where is our primary buildhost going to be?
Bugzilla database?
Erratta Database?
Who is going to be the primary host?

How long a cycle are we going to have from exploit to update release?

Are we going to use http/apt/up2date or what to distribute the releases?
Who has final say on whether to do rpm upgrades or not.
Has anyone asked a knowledgable rpm package at redhat their private
opinion on the matter, in order to get some expert advice on this?

Are their any experts on rpm packaging with practical experience that can
say that we need to upgrade rpm packages or not upgrade packages?

What is our release cycle going to be? What are our deadlines?

Are we supporting desktop applications or just server applications?

The deadlines that I see are thus:

Finalize Draft.
Implement Bugzilla database.
Come up with primary build committee.
Start monitoring erratta for our versions.
Do a test build for all our supported os version.
Determine what QA structure we will be using, how much if any QA testing
will we be doing?
Will we be releasing binary or src rpms?
How to prevent random evil people from sticking in trojans in a patch they
submit?
Setup up distribution repository.
Setup mirrors.
Setup synchronization schedule.
Distribute directions on using fedora-legacy.
Distribute gpg key for use.
Distribute a rpm upgrade if necessary for everyone who will use.
Ideas?


Axel Thimm wrote :

> On Sat, Nov 08, 2003 at 07:06:30PM -0800, Jesse Keating wrote:
> > For those of you that find vmware a bit too heavy and/or expensive,
whats wrong with plain old chroots?  I have a RHL9 chroot in my FC1
box that I use to produce RHL9 rpms, I'll be making a RHEL3 and RHL7.3
chroot soon as well.
>
> Nothing. All of ATrpms for RH7.3, RH8.0, RH9 and FC1 are built in
chroots. While I use a tool of my own, I'd recommend mach for managing
chroots.
>
> The true problems are setting up a new chroot (filling with required
packages), adding BuildRequires and removing them again. mach uses
apt-get to do this job, and apt-get is a good tool for managing rpm
pools. ;)

Yeah. Quick answer : Use mach if you're looking at where to start. It's
really wonderful to be able to be 100% sure that no build requirements
have been missed, and that rebuilding a package won't get any extra
dependencies inside that shouldn't have been there.

I hope Thomas will release a new version soon, as the latest changes
(hacks?), he's made fill all my requirements at last (expanded macros in
version, source etc. tags).

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 1 (Yarrow) - Linux kernel 2.4.22-1.2115.nptl
Load : 1.14 0.88 0.66

_______________________________________________
RPM-List mailing list <RPM-List at freshrpms.net>
http://lists.freshrpms.net/mailman/listinfo/rpm-list