[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: Archives use cases
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Re: Archives use cases |
Date: |
Wed, 8 Oct 2003 11:27:53 -0700 (PDT) |
> From: Clark McGrew <address@hidden>
> I can see how that would work with a project that is developing a small
> number of packages, but how does that work in a larger project. Using
> an example dear to my heart, the superk software is a collection of many
> different packages, and a large number of the libraries will be needed
> to build any given program.
I started to write a long answer about how to set things up in your
sitation but then realized that I don't know enough about your
situation.
Will you please tell me:
1) How many distinct software components are involved in this
collaboration? 10s? 100s? 1000s?
2) In the interesting "head revisions" of these components, how many
lines of source code are we talking about?
3) How many teams are involved in this collaboration?
4) What is the expected lifetime of these software components? 5
years? 20 years? 50+ years? How long has it been going so far?
5) I understand that the collaboration is essentially a cooperative
anarchy. Can you describe for me the current degree of
cooperation? Do groups use common build/config mechanisms? A
common testing framework? Common conventions for writing
documentation?
6) The collaboration is ongoing already. What mechanisms do you
currently use to catalog, distribute, access, and elaborate upon
the software components? What leads you to shop around for
alternatives?
7) In the past, what has been the process for acquiring and deploying
infrastructure tools for this collaboration?
8) If the time and size scale of your collaboration is significant,
that raises the question of turning into a first-class concern for
an effort to support it well. It is a timely problem of very wide
applicability and impressive economic significance (physics,
computation biology and pharmacology, free software development
practices, etc.) Have you contact or would you be interested in
contact with formal research and development projects chartered to
solve problems such as those you face, perhaps treating your
projects as case-study and customer?
9) The example you provided of the grad student directed to compile
and run a simulation for a discussion tomorrow was instructive.
Are there other common scenarios you'd like to mention?
Those questions aside:
I suspect that you've gotten off on the wrong foot by worrying about
how many archives to use and whether to use many categories per
archive or just a few. The answer is almost certainly:
1) Many archives
2) Few categories per archive
3) Some lightweight, simple, higher-level tools built as a
layer over arch
but those low level details tell you almost nothing of use. I
suspect we really should be talking about (3), in detail, perhaps even
cranking out some tools for you -- but that can't happen in a vacuum.
-t
- [Gnu-arch-users] Archives use cases, Clark McGrew, 2003/10/06
- Re: [Gnu-arch-users] Archives use cases, Robert Anderson, 2003/10/06
- Re: [Gnu-arch-users] Archives use cases, Clark McGrew, 2003/10/07
- Re: [Gnu-arch-users] Archives use cases, Robert Anderson, 2003/10/07
- Re: [Gnu-arch-users] Archives use cases, Clark McGrew, 2003/10/07
- [Gnu-arch-users] Re: Archives use cases, Miles Bader, 2003/10/07
- Re: [Gnu-arch-users] Re: Archives use cases, Clark McGrew, 2003/10/08
- Re: [Gnu-arch-users] Re: Archives use cases,
Tom Lord <=
- Re: [Gnu-arch-users] Re: Archives use cases, Robert Anderson, 2003/10/08
- Re: [Gnu-arch-users] Re: Archives use cases, Bruce Stephens, 2003/10/09
- Re: [Gnu-arch-users] Archives use cases, Robert Anderson, 2003/10/08