On Wed, 1 Oct 2003, Vincent Danen wrote:
> On Wed Oct 01, 2003 at 09:46:27PM +0200, Guillaume Rousse wrote:
>
> > > Suddenly I'm getting very tired of all of this again. Seems no matter how
> > > hard you try, someone has something negative to say without contributing
> > > something useful.
> > Vincent, i didn't intend to be rude, just to say that we first to have to make
> > the club work in a scalable and efficient manner first, and integrate it into
> > standard development process whereas it is currently completly run in a
> > parallel and amateurish way.
>
> I agree with you on this, but you need to provide a way to make it better,
> or at least begin that process. Simply saying it's no good doesn't help.
>
> Yes, Club building has to be managed in a better way and, realistically, it
> should leverage the resources we have... you guys. For instance, if there
> was a simple way to do a build on klama for current contribs and handle the
> backport/build in a chroot on the same machine and "ftpclub" or
> "ftpclub-testing", "ftpclub-stable", "ftpclub-commercial", (you know what I
> mean) to get something into Club easily would be a bonus.
As a first step, how about just having an ftpclub script (or multiple if
it's really necessary) which uses one account in the current Club setup
('contrib' or something) which allows people to upload from klama. We'll
assume for now that they have built the package on a suitable (clean
install for the related packages plus available updates), and we can get
to chroots later. This will allow contributors to provide updates without
the hassle of getting a club upload account etc etc (most benefit for
least effort).
On bigger packages, I scp to klama first, and then to Club from there
(since I don't want to upload another 30MB when the package goes straight
from testing to done).
>
> Retrieval of packages is easy; voting is still a good idea. It's the
> submission/building/management process that is trying that should be fixed.
>
> > Automatic rebuilding of all cooker packages for current stable version should
> > be enough to solve contrib update problems IMHO.
>
> I don't think so. I do a lot of backports all the time... =) You cannot
> just grab something from "current" (by which I refer to cooker and contribs)
> and just rebuild it. That will not work. It is a manual process.
Depends on the package. In a similar way, some packages can't be rebuilt
on the same release they were originally built on (ie due to buildrequires
etc). One is considered a bug, should we not consider the possibility that
automatic rebuilds on older releases are both possible, and desirable?
Regards,
Buchan
--
|----------------Registered Linux User #182071-----------------|
Buchan Milne Mechanical Engineer, Network Manager
Cellphone * Work +27 82 472 2231 * +27 21 8828820x121
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
*****************************************************************
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
*****************************************************************
