gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.


From: James Blackwell
Subject: Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.
Date: Wed, 21 Jul 2004 23:48:32 -0400

> James Blackwell wrote:
>> That's a lot of stuff to tack onto a revision control system, right?
>> Well, this is how we win the game. We make it so easy for a project to
>> handle every aspect of revision control (there's a lot more than just
>> merging cleanly), that o use anything else would be idioic. Already,
>> some of our compeitors, like darcs and bitkeeper, already have some of
>> these things in place. 
>

Aaron Bentley wrote:
> I disagree here.  Choice is important.  When you glom everything up 
> together, you reduce choice, and everyone gets stuck with one solution 
> that fits no one perfectly.  I think that changes that would enhance 
> Arch at the cost of hobbling other programs are not to be made lightly. 
>   Otherwise, feel free to turn Arch into a PQM.

I like choice too. And some day, there's going to be multiple pqms out
in the wild that we can support.

Tom's shown a history of doing things in such a way that
(appropriate) replacements can be put in place. 

>> About the worst that you'll bump into will
>> 
>>     (define mirror-locations ( '("http://siteone.com";
>>                                  "http://sitetwo.com";
>>                                  "http://sitethree.com";)))
>
> If that's the case, Tom should stop posting code like this:
> tom>                 (define my-default-archive
> tom>                   (archive-of my-default-fq-vesion))
>
> If Tom promises we'll never see code like that example, then we can all 
> go home early.  But that would raise the question: why go further than xl0?
>
> See, xl0 looks like a perfect balance to me, in terms of its structure. 
>   I agree that it's better to have one system for managing configuration 
> data, and I can't imagine having difficulty writing a parser for xl0.

I *think* we can go home early. My belief was only simple assignments
and lists. But I'm not sure, so let me play devil's advocate for a
moment. Let's hypothesize that he did institute these calculated
variables.  

Surely, the calculated variables, though opaque on the filesystem level,
wouldn't be opaque if the gui program happened to use libarch (since it
would make the same configuration calls that arch would make).


[several things the gui could handle changing calculated variables]

I'd say that we solve setting the variables the same way I propose that
the variables be read in the first place -- by using libarch.


> But in the ideal, I think the GUI should look like this:
> +-----------------------------------------------------------+
>| Default version                                           |
>| address@hidden/tlacontib--aba--1.3] |
>|                                                           |
>| [X] Override default archive                              |
>| address@hidden                     |
> +-----------------------------------------------------------+
>
> What have I done here?  I've blessed the common cases, and sacrificed 
> fringe functionality for the sake of ease of use.  There are no computed 
> values; either my-default-archive is assigned to a string, or it's not 
> defined.  If it's not defined, there's a rule that conforming Arch 
> implementations must substitute the archive of the default version. 
> That rule may be implemented in whatever languages the Arch 
> implementation is written in, including POSIX shell, C, Furth, xl1, 
> Perl, Python, Haskell...

I think that's a matter of preference, and I don't care which way we go.
I'm not even convinced we want a default version in the first place. I
work with a lot of versions though, so perhaps I'm suffering from error
of locality.

> I believe this is an appropriate approch for most kinds of configuration 
> data.  How many useful ways can there be to assign a value to 
> "upstream"?  Isn't it better to give them first-class support than to 
> throw a scripting language at the problem?

Its really not a case of throwing a scripting language at the
configuration issue problem. I'm thinking that since this puppy
is going to be designed, implemented and used with a bunch of stuff
that's *meant* to work hand in hand with tla, we might as well go along
for a free ride and use it too.

> For especially strange functionality, people are going to want to use 
> their own languages anyhow.

> When you treat code as data, you make data opaque to other programs. 
> That reduces choice, and in some cases, forces people to execute code in 
> their heads in order to evaluate values.  I think that for most cases, 
> the cost is not worth it.

Tom has promised that its going to remain simple. 
 
> And, if you think this just applies to GUIS, ask yourself how you'd deal 
> with it in "tla my-default-archive".  Surely "tla my-default-archive 
> $(tla my-default-archive)" should be a no-op.

The way I'd like to see it handled is that tla only sets variables
explicitely. If the user wants to throw something more complicated at
the parser, he can do so with the understanding that if it breaks, he
gets both pieces.

>> In
>> order to help addres this exact issue, I have created
>> address@hidden/tla--devo--1.3, and into that branch I have
>> started merging changesets from a variety of sources.
>
> I appreciate you taking this on, and I'll do my best to support you.  I 
> have faith in your ability to put out a 1.2.1 release that that's an 
> icremental, but useful improvement on 1.2.

Thank you! This means a lot coming from you. And yeah. 1.2.1 will be
small things. As I do successive releases, I'll get bolder, as my
experience with the full code set improves.
 
> But my feeling is that Tom's irreplaceable.  Even if Tom's clone were to 
> wander in from the street and offer to take over, I wouldn't hand him 
> stuff like the backbuilder, because only Tom knows the archive format 
> inside out.  Twice now, I've caught bugs in the backbuilder that would 
> not be caught by testing normal archives, because

Tom is absolutely irreplacable and I bet he's going nowhere. I plan
on sticking to evolutionary stuff, and leaving the revolutionary stuff 
with Tom. Everybody wins; Tom gets to work on the really intersting
stuff without worrying about the day-to-day crap that wears him out. I
get to work with lots of really cool people and get that did something
useful feeling. Other arch developers get their stuff merged up and out
there much quicker. 

> - no one* tags into a version after committing (but it's valid).

Its my understanding is that its *not* valid. 

> - only larch can do an import after base-0 (but it's valid).

This shouldn't be valid either.

> *except David Allouche, and he started long after I wrote the code.
>
> Both of these came as nagging doubts long after I'd written the code in 
> question.  There's no way I'd have seen it if someone submitted it to 
> me, and even Tom didn't see the deficiency in my proposed interface.

You're human. I'm human. Even Tom is human. :)

Yeah. Self-doubt is a tough one. I figure the only thing you can do is
to remember that you're human. Mistakes *will* inevitably happen. They
can slip by you, me or even Tom. What is important is that we minimize
the likelyhood of these mistakes, and learn from them quickly when they
do happen.

I know, going forward, that I'm going to make some mistakes. I know
you'll probably make the occasional mistake too. When we do that,
we'll find it, deal with it, learn from it, and move on.

With the understanding that we're all going to make mistakes, the right
thing to do is for us as a group to review each other's work, and take
small, safe steps. We should also be particularly paranoid of any code
that writes to archives. Also, we can help protect ourself against
mistakes by pushing (and I mean REALLY pushing) test cases. The more
test cases we have, the less likely that a mistake will come along and
bite us in the rear later.

With that said, I'm not putting any changesets into arch unless I
understand them, or enough people I trust say "Yeah, this one's safe". I
have absolutely no compunction about holding up a changeset for six
months while Tom takes his sweet time getting around to it.

I can guarantee you that this is going to annoy some people. There's
going to be cases where people submit good, quality code that's going to
get held up because I'm not able to evaluate it properly at that time.
When that happens (and I'll bet you 10 to 1 that it will), there's
really two choices. Either take the time out to get me up to speed, or 
start working on endorsements from other hard-care developers. 


> On the other hand, maybe it's a question of which invasive features are 
> most important.  I can keep the backbuilder from going stale until Tom's 
> ready to look at it.

Yeah, I think holding off on the backbuilder for either Tom or later is
the right choice at this point.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400




reply via email to

[Prev in Thread] Current Thread [Next in Thread]