Re: tlug: Mozilla, uh, M15

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Shimpei" == Shimpei Yamashita <shimpei@example.com> writes:

    Shimpei> I guess I wasn't clear. That's exactly what I'm asking
    Shimpei> for--just patches from M15 to M16, or M16 to M17.

Oh, I see.  Well, I don't consider Mozilla something that
non-developers should want to play with yet, anyway. ;-)  But, yeah,
that is a bit unfriendly to people without broadband connections.

    Shimpei> people who are only interested in compiling the milestone
    Shimpei> releases.

I guess a few people would be interested in patching up each milestone
to save bandwidth, but nowhere near as many for Mozilla as for the
kernel.  Most people are just going to do binary updates (sorry,
Chris, but that's the way it is).

    Shimpei> Release versions, no.  You aren't seriously suggesting
    Shimpei> that the Linux kernel patches are primarily for
    Shimpei> developers, are you?

The kernel is a special case.  That kind of situation shouldn't be
using pull technology anyway, the releases should be distributed by
push technology (cf. Jim Gemmell, "Scalable Multicast File
Distribution," Dr. Dobb's Journal #312 (May 2000), pp.~82-89 -- pay no
attention to that employer behind the curtain).

No doubt that this point is valid for the kernel, though.  But what
other package would it apply to?

    >> CVS also makes it possible to back out bad changes in a regular
    >> way, without the cooperation of the release engineer.

    Shimpei> Well...yes, sorta, but I'd be wary of any project that
    Shimpei> uses CVS as a substitute for a release engineer. Kind of
    Shimpei> like using a hammer as a substitute for a carpenter.

Not the project, the sometime hacker.  If there are good changelogs,
the downloader can often back out individual changes by using the -r
or -d flags, and on a file by file basis.  Can't do that with
megapatches without lots of pain.

    Shimpei> That's about what I see when I sync a much smaller
    Shimpei> project over CVS every night. Of course, the time spent
    Shimpei> generating patches/updates versus time spent transmitting
    Shimpei> is irrelevant for dialup access customers because we get
    Shimpei> billed for both.

True; my point was that whereas on my home connection it probably
takes 10 minutes to do an XEmacs CVS update that touches one file, and
(with luck) 1 second to download a 200 byte patch file, that 600:1
ratio compresses down to something pretty reasonable for larger
updates (true, you still have to pay more for CVS, but if you're going
to do the updates regularly the flexibility is worth the extra minutes
and yen).

    Shimpei> However, it's not so great if you are just a user trying

But my point is that "just a user" is inaccurate.  There's a whole
continuum, and my contention is that most of the people far enough out
toward developer on the scale to be compiling from source (not very
far, but still) are likely to be willing to pay the extra bandwidth
for the advantages of CVS.  Even on the other side of that 14.4
bottleneck, if I compile it myself and it's got a CVS source, I use
CVS.  This is true for several packages like Ghostscript and Coda
where I never have time to look at source anymore.  (^^;

My experience has been that even "releases" often have major bugs in
them; typically they get fixed within 24 hours.  CVS allows me to pick
up those fixes.  (Ghostscript provides incremental patches, but I have
to do the work of connecting to the FTP server.  XEmacs doesn't do a
new patch until the next release---on the stable branch that will be
asap of course, but we're probably not talking about the stable
branch; on the unstable branch we accept bug reports---you want
immediate updates even for fatal bugs, you use CVS :).

    Shimpei> to compile from source--aside from the extra bandwidth
    Shimpei> involved, you're never sure which tag on which branch is
    Shimpei> the "best" release unless you actually follow the

Can't speak for other projects; on XEmacs "-r rrelease-$MAJOR-$STABLE"
gets the most recent stable release, and "-r release-$MAJOR-$UNSTABLE"
gets the most recent unstable release that is known to compile on at
least one machine (ie, the release engineer's, and in fact he normally
tries on four or five systems).  If that doesn't work for you, you
back it out to "-r release-$MAJOR-$UNSTABLE-$(($REVNO -1))".  (This
last does require a bit of extra understanding of CVS, but if you're
on the bleeding edge, you asked for it.)

I would imagine that most projects do something similar.

    Shimpei> developers' mailing list. Not to mention the fact that
    Shimpei> you have to learn CVS, which is a bit much to ask for
    Shimpei> from non-developers who just want to use the latest
    Shimpei> general release.

Not as much as asking a developer-type to learn how to use GNOME's
fscking detachable toolbars (or shouldn't I have admitted that I don't
know how to put them back when they come loose? ;)

It's really not that hard to use CVS for the purpose of downloading,
no harder than wget or w3mir.

The bottom line is that I think that both the set of projects and the
set of users where providing patch files is preferable to CVS is
small, and the latter will get smaller over time.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
-----------------------------------------------------------------------
Next Technical Meeting: July 8 (Sat)  13:30  Place: LinuxProbe Hall
Next Nomikai meeting: August 18 (Fri) 19:00  Place: TBD
-----------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan