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

RE: the big news



Ed,

>Hmmmm ... perhaps someone in the R project would be willing to volunteer to
>"adopt" ATLAS? If no one here is on the R lists, I can certainly bring it up
>there.

Well, I think adoption might be premature, in that the plan is not to orphan
ATLAS in the first place.  As I said before, I plan to still support, but
just not at the same levels.

The first place I'd hope to get help is in the user question area, as I
mentioned in the first mail.  The second is in getting stable releases out.
The way this used to work, is that Antoine and I would decide on a code
freeze, and then test on as many platforms as possible, over the course of
a month or two, until we had a stable release.  This is what will no longer
be possible.

So, what seems viable to me is have developer releases, and keep track of where
they have been installed.  At some point we stop accepting new code, 
applying only bug fixes.  After a given point, the last bug-fixed developer
release rolls into a new stable.  There's a lot of stuff glossed over that
will have to be nailed down, but that certainly seems to be a viable idea
to me . . .

We can use CVS branch to allow a frozen developer branch (heading towards
stable), that wouldn't effect continued developer work as well.

In the coming time, I will be posting other stuff to the developer website
that will facilitate this kind of deal.  For instance, Antoine developed
a test suite that we run to verify ATLAS, and I'll be posting it . . .

Anyway, I hope not to orphan the package, but rather feel that since it
is out of it's adolescence, perhaps it can safely have a greater amount
of independence :)

However, if R developers (I don't know much about the R project, except that
R can utilize ATLAS) would help with the testing and so on, that would
certainly be great.  It makes some sense that packages that use ATLAS
could help out in that regard if they have the time, often perhaps as part
of their own internal testing . . .

Cheers,
Clint

> -----Original Message-----
> From: R Clint Whaley [mailto:rwhaley@cs.utk.edu]
> Sent: Friday, August 31, 2001 2:45 PM
> To: atlas-comm@cs.utk.edu
> Subject: the big news
>
>
> Guys,
>
> I guess most people know that Antoine left the ATLAS group a bit back.
> This was a pretty big blow, since he was roughly half the group.
> The second
> shoe is now dropping, in that I am going back to school to finish my Ph.D.
> This leaves 0 full-time ATLAS developers.
>
> Unfortunately, I was unable to find a school with both the possibility of
> doing ATLAS/AEOS stuff for my dissertation and a curriculum that lets me
> get started on it before I die of old age.
>
> This is not an "ATLAS is going away" message; it's more a "ATLAS will not
> be administered in exactly the same way, who's got ideas?" kind
> of deal . . .
> I am certainly not abandoning the project; I feel that ATLAS provides
> real value to the community, and I am proud of the work I have done here,
> and would not like to see it go to waste.  However, the amount of time I
> have to spend on it will obviously decline enormously.  One thing that is
> obvious is that alone I will never again have the resources to get out a
> stable release, and support it in the way we have previously.
>
> It is my belief that stable ATLAS releases need to be much more solid than
> many libraries, in that blas and lapack are basic infrastructure
> that simply
> must work correctly.  Therefore, I don't worry about the more cutting edge
> developer releases, which only people in the know should play with.
> Stable releases and their support, though, will need a new
> process in order
> to continue at a decent level . . .
>
> It is my hope that the community will find atlas useful enough to give me
> a hand with this stuff.  If that doesn't materialize, that in itself is
> an interesting data point . . .
>
> Anyway, I am leaving full-time ATLAS work in November-December time frame.
> I have been working on some developments that I hope are in the right
> direction to allow for a more distributed maintainence.
>
> The first of these is finally ready.  The ATLAS developer page has been
> moved to SourceForge,
>    http://math-atlas.sourceforge.net/
>
> The entire ATLAS source tree is available for anonymous CVS access (read).
> I have posted a quick explanation of how to access it at:
>    http://math-atlas.sourceforge.net/atlas_devel.html
>
> As I say, this is just the first thing to get done.  It is mainly so that
> work between Antoine and myself is more lightweight.  However, people do
> occasionally want to submit patches or add to ATLAS, and this ought to
> make that easier (at least on me :).  Before, people made their changes
> against a released tarfile, and when I got them, I would adapt them to
> our source.  This will allow them to give me a CVS diff that I can
> evaluate and apply much more easily.  Note that we keep the ATLAS source
> in something called extract, and most may not be motivated enough to
> figure this out . . .
>
> I'm still getting a feel for what-all I can do on sourceforge.  One of the
> things I hope to get rolling is an ATLAS help mailing list to replace
> atlas@cs.utk.edu.  This is an obvious place where I think the
> community could
> help a great deal.  I would like to get a help list that others can sign
> up for (or better yet, perhaps, just browse when they have time), and some
> questions could be answered by others who have a given problem
> figured out.
>
> I hope to be able to generate an auto-reply message, telling
> people to scope
> the errata, and that the authors check mail only sporadically.
> If this were
> supplemented by having others answer some of the easier questions, I think
> support can be maintained at a decent level.  Roughly 1/2 of the answers I
> give on this list boil down to "scope the errata", "no, I mean
> really scope
> the errata", and "no, seriously, what about the errata".  It doesn't
> require vast amounts of ATLAS experience to answer these type of
> questions,
> but personal intervention does seem necessary to get people
> directed that way.
>
> I still don't know, but I'm hoping SourceForge's resources will help with
> this (if you've got some SourceForge knowledge, I'd certainly appreciate
> any shortcuts you could supply) . . .
>
> Because ATLAS runs so many places, and because everyplace it runs
> is changing
> rapidly, it can suffer bitrot quite a bit faster than many projects (the
> recent problems with gcc 3.0 show how quickly things can go downhill), so
> I think it is important I don't spend *all* my free time in raw
> support even
> if just staying the same place, much less progress, is important . . .
>
> So, in the remaining full-time months until the end of the year, my main
> goal is to get a solid stable release out before I leave, while
> investigating
> the feasability of various maintainence and development methods.
> If people
> have ideas along this line, let me know.  I feel the time to try
> this stuff
> is now, while I'm still fulltime, rather than try to find a new process
> when I can't concentrate on it . . .
>
> We have never officially announced the developer stuff that I know of, and
> we already have a small community of contributers.  It is my hope if the
> developer stuff is improved in the next few months, we can then announce
> it to the broader community and perhaps bring in more interested
> people . . .
>
> Anyway, in the meantime, the CVS is there if anyone is interested . . .
>
> Cheers,
> Clint
>