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

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



* Carsten Haitzler (raster@rasterman.com) wrote:
> On Thu, 17 Aug 2006 16:45:19 -0400 Lyle Kempler
> <term-e1@twistedpath.org> babbled:
> > * 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.

Looking at get-e.org, the download page points to the E17 User's Guide,
which starts with "Installing from CVS". If we instead changed the
download page to "download this script and run it, you'll need wget and
tar and bzip2 and ..", then new users could convert over without even
having to concern themselves about CVS. If the script had the ability to
download only a portion of the tree -- say, "minimal" vs "gadgets" vs
"full", etc -- that might also increase everyone's milage. I think a lot
of this is people just get everything because they're not familar enough
to know what they need or what might be cool (of course this all goes
back to packaging, no official recent releases.. etc). The script could
even check dependencies (which may lower the number of questions we
get). IIRC, someone may have even proposed this a long time ago..

> 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

Absolutely. A more wild possibility is that because most of our
configure scripts accept the same options, the script could even collect
htem and pass them in (so --prefix could be handed down from the
download or perhaps another script, and users can just walk off until
the build is done or have it run non-interactively from a cronjob,
etc..). IMO (and it's a somewhat uninformed one as of late), most users
want access to "product" and the obstacles to installation send them
looking to anoncvs.

> 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?

I'd like to believe that, though instant access to changes is alluring,
(just look at news sites).. :)

term