[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] cvs, servers and stuff.

On Thu, 17 Aug 2006 16:45:19 -0400 Lyle Kempler <term-e1@twistedpath.org>

> * Chady Kassouf (chady.kassouf@gmail.com) wrote:
> > On 8/17/06, The Rasterman Carsten Haitzler <raster@rasterman.com>
> > wrote:
> > >personally i would have no problem in a server-side auto-build of
> > >tarballs.  what do people think? should we perhaps have the anoncvs
> > >server do daily (or maybe several times per day) builds of packages?
> > >not rpm or deb but "make dist"; ie something like the following run
> > >maybe every 4 or 8 hours? once a day?
> > I think that while this option might be useful for load, it takes a
> > lot more bandwidth, and is bad for users, as they would have to
> > download hundreds of megabytes each time a 1 Kb patch is in.
> > 
> > I vote for the cvs mirrors as at least it's easier on the user's AND
> > the server's bandwidth.
> Eventually I'll corner KainX and he'll tell me what setting I don't have
> in mutt to read raster's emails other than through quotes.. anyway..
> Were I suggesting merely a new tarball every day, then I'd agree. My
> argument was for a weekly tarball and patches otherwise (and it doesn't
> just have to be patches since the last weekly tarball). A lot of CPU
> time and some bandwidth is consumed determining what changed since the
> last time you sync'd up. If you _knew_ where that last sync point was
> (e.g., yesterday's diff), then you'd be saving everyone a lot of
> resources by just getting the pregenerated, precompressed version,
> instead of making CVS do the diff, compressing on the fly (I'd like to
> believe most people are using -z3 :)). As I read over and over that
> people are using scripts to retrieve everything (be it ebuilds or
> hand-rolled), this could easily be switched to.
> * Hisham Mardam Bey (hisham.mardambey@gmail.com) wrote:
> > On 8/17/06, Lyle Kempler <term-e1@twistedpath.org> wrote:
> > > Personally I don't get why we're not creating nightly diffs and a
> > > tarball once a week and letting people use that (it's not exactly
> > > difficult to script). I highly doubt most users care about checkins
> > > in the last few hours, and I suggested doing so I think way back in
> > > January on IRC..
> > Actually they are. You'd be surprised how many people build E (and
> > related stuff) multiple times a day from anoncvs. Again, I agree with
> > the majority that is suggesting the mirrors idea. CVS has its quirks
> > here and there, but its been doing everything we wanted for a long
> > time. I think that having a 2 or 3 anoncvs mirrors should solve our
> > problems.
> I am actually surprised that so many people are "a CVS junkie" :) ..
> that's good feedback to have. I never advocated dumping the anoncvs
> servers. I was saying that we could reduce demand (and therefore improve
> performance for the remainder) by providing tarballs. And, as raster
> said, there's nothing keeping us from producing patches every 4 hours,
> etc..

agreed. i am not advocating REMOVING anoncvs as such - just removing it as a
"first priority anonymous source access" mechanism. putting anoncvs access info
into fineprint in some obscure page linked off a download page. moving the
"primary" access to something more server-friendly that matches people's needs
better. people dont NEED cvs. developers do. they simply need a way to "get the
latest code". also for those speaking of the bandwidth issues - a LOT of people
DONT keep their cvs trees after build they re-checkout a new tree.

so what we need to do is try alleviate the need for anoncvs mirrors and if
there are mirrors - make them "last longer" bye making an alternate way of
accessing updates available that gives people what they really need in a way
that is light on our resources, and thus can scale better.

imho making dist tarballs is also a good testing mechanism. that is our "end
product" anyway - a cvs tree where you ned to run autogen.sh (autofoo) is NOT
our "target product". it is an intermediate state developers can easily work
with. end users will work with the result of make dist and then do the usual
tar -xf file.tar.gz; cd file; ./configure && make && make install

if we move and encourage the primary mechanism to be this with regular enough
updates that people aren't waiting impatiently for that update/fix - then we
may solve a lot of our problems?

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)