Tim,
On 2004 May 31, , at 01.03, Tim Jenness wrote:
> Pre-empting the discussion, I don't think it's an issue since most
> things
> can migrate from the current installation locations to a new
> "standardised" location without affecting other things. This is easy
> once
> everything works in CVS. [although we did agree that we should not be
> installing shared libraries into share]
True enough. I think we should still have a brief chat about this, to
confirm it really is as straightforward as that, but no more than that.
See below.
>> Anything else? Is that a reasonable division?
>
> The install target needs to install versioning information somewhere so
> that the starversion command will continue to work. Currently
> starversion
> mainly looks in the datestamp files but there is no equivalent at the
> moment.
The manifest file which is installed by the `install-manifest' target
currently includes a <version> element which contains the version
declared in the configure.ac. Is that sufficient?
DavidG: how's about this for the CVS part of the programmers' meeting
agenda?
1. Brief summary of status [Norman, 5m]
2. Arrangements for the CVS-week [Norman, 5m]
3. Outstanding CVS issues. See message
<http://www.jiscmail.ac.uk/cgi-bin/webadmin?
A2=ind0404&L=stardev&T=0&F=&S=&P=245>. Some of these issues (6: yes,
8: standing action?, 13: fixed?) have already been resolved, and the
thread after that contained some opinions. Issue 4 probably doesn't
have to be decided now, since, as Tim points out, such a change can be
made centrally later. Issue 10 (uninstaller) might be usefully
discussed here, but might be deemed purely technical, and thus
postponable to the CVS-week. Any objections? Anything else? (see
also the `agenda' for the CVS-week). [<10m, unless we do discover
problems that should be discussed here rather than in the CVS-week].
4. Packaging of components for separate distribution. What should we
aim for? When should we do it? If the answer is `Debian + RPM
packages, during the CVS-week' then that's easy. Or do we just do it
when we next get the chance? There's probably no need for any
technical discussion, just the decision about what packaging goals
should be on the CVS-week agenda. [10m??]
[~ 30m to here]
5. Tagging and branching. See the CvsTagging page for proposals, and
the thread starting with
<http://www.jiscmail.ac.uk/cgi-bin/webadmin?
A2=ind0404&L=stardev&T=0&F=&S=&P=15983> for some disagreements. Is it
worth while aiming to resolve this at this meeting? [30-60m, probably]
[and this has to be scheduled in a morning session so that Tim can join
in from Hawai'i.]
...and this for the `agenda' for the CVS-week (partly from the `CVS
discussion topics' message of last week):
1. CVS issues: 9: AST/Fortran link queries
2. Uninstaller tool necessary (issue 10)?
3. Testing (issues 11 & 12): should regression tests run before or
after installation?; do we need a separate installation test?
4. Do we need separate `install' and `install-manifest' targets.
5. Building documentation by default? When?
6. Distribution and packaging: technical issues not resolved at the
programmers' meeting.
7. What `codeline ownership' features are desirable?
8. [DLG's message:] Aim: get everything into CVS and set up new build
system ( checkout, configure, make) - working on various flavours of
Unix plus MacOS-X (and Cygwin/Windows if possible in the time
available). Note that the "essential" apps must build and work but
other low priority apps may fall by the wayside at this stage -
although even for these the code will be in the CVS repository.
That's turning into quite a lot of discussion at the CVS-week, rather
than the coding frenzy anticipated. Is this inevitable, or has this
division of policy vs. coding got out of hand? There seems to be a
danger that the CVS-week could turn into an extension of the
programmers' meeting, which is undesirable.
See you,
Norman
--
------------------------------------------------------------------------
---
Norman Gray
http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK
[log in to unmask]
|