On Feb 17, 2007, at 10:14 AM, Patrick R. Michaud via RT wrote:
Just working on bug-day tickets (especially since I'm the release-
manager this month :-)...
On Wed Jan 31 13:37:54 2007, [EMAIL PROTECTED] wrote:
The primary purpose of a MANIFEST in the repository is to tell you
which files out of the repository should be included in the
distribution.
Yes, but our MANIFEST is just a list of everything in the repository
(modulo a single directory that we started skipping in r12600).
MANIFEST.skip could be simply generated from the svn:ignore keyword
before the distribution tarball is created.
Perhaps I'm just confused, but these two statements seem to be a
little at odds with each other, unless we say that MANIFEST.SKIP is
generated from "svn:ignore and other sources".
If I'm understanding correctly:
- MANIFEST indicates which files are to be in the distribution.
- svn:ignore indicates which files in a build tree are to be
ignored as part of "svn status" and other svn commands.
- MANIFEST.SKIP indicates the files in the repository (build tree?)
that are not part of the distribution -- i.e., not part of MANIFEST.
Since, as Allison says, there could be files in the repository
(i.e., svn:ignore *not* set) that are not part of the distribution,
MANIFEST.SKIP must contain more than just files with the svn:ignore
keyword.
Also, isn't it possible that MANIFEST could eventually include
(generated) files that belong in the distribution but aren't
in the repository? If yes, then the repository cannot be the
canonical list of files going into the distribution.
Yup. Makes sense. So "die" is too strong, but "fixed" isn't.
For the moment, disabling configure's manicheck by default would be a
good start. This isn't something we need every developer wasting
their time on given how we're using it right now; more of something
that should be handled by the release manager.
(How many times has the build been broken by a missing MANIFEST update?)
----
I would like to get rid of MANIFEST.SKIP, however, and I think
we may not be using our tool (svn) to its full advantage.
Brainstorming a bit ... isn't it possible for us to define
our own svn properties? (I'm not all that familiar with this
part of svn.) If yes, then can we just have a
"distribution:[yes|no]" svn property that indicates files to be
part of the distribution?
"coming soon" to svn, not available yet.
Then MANIFEST can be generated automatically when a release
is generated -- files with "distribution:yes" plus any
additional (generated) files that aren't part of the repository.
We can also have a test that checks that every file in the
repository has either "distribution:yes" or "distribution:no"
(and svn can probably do a lot of the work here).
Or, perhaps a little fancier, in that we have a property
"distribution:[parrot|main|doc|perl6|APL|TCL]", that can be
used to construct different distributions from a common
repository.
Or, if we don't want to use svn properties, perhaps simply
a master REPOSITORY.MANIFEST file that lists all of the files
found in the repository and the distribution disposition
of each (skip, release, parrot, whatever).
Ultimately I think we have to wrap our collective heads around
the idea that "repository" != "release", and that the MANIFEST
file is really tied to releases and not the repository. And
that MANIFEST.SKIP was intended to make it easier to manage
and test MANIFEST, but that we may now have better ways to
do this.
Either that, or let's leave things as they are and close this
ticket. (I did say I was doing this for bug day. :-)
Thoughts? I may have more to add to this discussion after
going through the release process this week. And my apologies
if I've muddied the waters by commenting on things from incomplete
knowledge.
Pm
--
Will "Coke" Coleda
[EMAIL PROTECTED]
