Re: [Gnu-arch-users] 1.1 feature freeze

[Tom Lord]

    > From: James Blackwell <address@hidden>

    > I'm aware of these outststanding issues, in order of importance: 

    > 1. (This one comes from Andrew Suffield). The tree-lint and inventory
    >   commands have a habit of listing .arch-ids in their output. This can
    >   have some negative side effects when piped through a tla add command
    >   that can catch both newbies and the unwary . 

    >   I've already come up with a couple easy ways to solve this. Though I'm
    >   looking for better ways to handle the problem, my progress is
    >   currently delayed due to lack of experience in the inventory code. 

Not sure I follow exactly what the bug is (I have a guess though) but,
yes, let's fix that.


    > 2. Tla grab, which I really want in 1.1, is still broken. The problem
    >   seems to be in the way that grab is calling through the pfs layer
    >   (everything comes up 404).

    >   Prior to 1.1, grab should either be fixed or disabled. I'm a big
    >   proponent of fixing it because this allows us to "get newbies going"
    >   very, very quickly so that they can play the other commands and get a
    >   feel for arch quicker.

The tutorial is currently silent on it so I see no need to disable it.
I have no objection to merging further fixes to it before 1.1 (nor
plans to hold up 1.1 for fixes -- but you have a few days at least).


    > 3. tla 1.1 on shipment should have a library-browse command of some
    >   sort. We need this because right now there isn't a user friendly 
    >   way to inventory what libraries have been collected. My proposal
    >   for this would be an rbrowse equivilant for libraries.

    >   I could handle this one on my own in an afternoon.

Likewise.  Don't stress over it.   If it's there I don't mind merging
it.

On the other hand, both library-browse and grab are arguably the kind
of convenience commands that are "officially" one of the subjects of
the 1.2 series.


    > 4. rbrowse doesn't have all of the capabilities that abrwose does.
    >   However, rbrowse and abrowse in their current incarnations look stable
    >   to me so perhaps it would be better to save the full rbrowse
    >   implementation for 1.2. 

Ok.

    >   The problem I'm having with with porting abrowse functionality into
    >   rbrowse is that the abrowse code is deeply nested and I have
    >   difficulty understanding exactly what functionality abrowse provides. 
    >   However, I'm starting to figure it out.

    >   My gut feeling is to leave things as they stand now and then I can
    >   dive into it properly after stability freeze. Though I could probably
    >   hack up rbrowse to do everything abrowse quickly, I don't want it to
    >   end up with an unmaintainable pile of spagetti...

Yeah, let's leave further rbrowse/abrowse foo till 1.2.

-t