Svn arrangement: Documentation and graphics
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
Svn arrangement: Documentation and graphics
/me thinks we should move docs and graphics out of the current modules and into their own.
Umm, why? You mean armagetronad/sounds, armagetronad/textures and armagetronad/src/doc, right? I think everything that goes into the tarball should be part of the armagetronad module, and if possible, arranged exactly the way it is in the unpacked tarball. Which reminds me, sortresources.py could now use "svn mv" to actually move the resources to their right place in the repository.
If you just don't want the daily, expensive updates of our multi-GB graphics, svn switch them to a tag.
If you just don't want the daily, expensive updates of our multi-GB graphics, svn switch them to a tag.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
There is no armagetronad/doc, and the banners are only in the windows build modules (where they're required), so I don't know what you're taling about there
armagetronad/tron.ico and and armagetronad/textures/kgn-logo.png are unused now. They can go, but not into a separate module. They can be deleted.
armagetronad/tron.ico and and armagetronad/textures/kgn-logo.png are unused now. They can go, but not into a separate module. They can be deleted.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
src/doc, whatever...z-man wrote:There is no armagetronad/doc,
They can be copied there, unless they're specific to the build...z-man wrote:and the banners are only in the windows build modules (where they're required), so I don't know what you're taling about there
I was specifically thinking of build/codeblocks/icons, but there's no reason eg tron.ico should be deleted instead of going to a module specifically for non-game images. Along with other general art we use on webpages and such.z-man wrote:armagetronad/tron.ico and and armagetronad/textures/kgn-logo.png are unused now. They can go, but not into a separate module. They can be deleted.
I would say src/doc is an essential part of the distribution. Granted, the way it's compiled is not optimal, but nevertheless, it's essential.
And tron.ico isn't used any more at all (I think). Joda made new icons for Windows in build_codeblocks. Therefore, delete.
Images for the websites are a totally different topic I don't care much where they're stored, but a SCM not optimized for binaries seems the wrong place.
And tron.ico isn't used any more at all (I think). Joda made new icons for Windows in build_codeblocks. Therefore, delete.
Images for the websites are a totally different topic I don't care much where they're stored, but a SCM not optimized for binaries seems the wrong place.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
Part of the distribution, sure-- but not part of the game itself.z-man wrote:I would say src/doc is an essential part of the distribution. Granted, the way it's compiled is not optimal, but nevertheless, it's essential.
Not used by the game installers, you mean. Who knows if some Joe Player likes to use that classic icon?z-man wrote:And tron.ico isn't used any more at all (I think). Joda made new icons for Windows in build_codeblocks. Therefore, delete.
I'm thinking of just a graphics place to throw anything that might be useful in general purpose areas, even if it isn't currently. Probably outside the game release hiearchy.
Makes it simple to have everything in one place, and allows someone to keep a checkout of all graphics.z-man wrote:Images for the websites are a totally different topic I don't care much where they're stored, but a SCM not optimized for binaries seems the wrong place.
I'm going to collect all loose windows resources that might be used in winlibs...
joda's plan:
winlibs/common/res/icons/*.ico
winlibs/common/res/banner.svg
winlibs/common/res/banner.bmp
winlibs/common/armagetronad.nsi
winlibs/common/armagetronad_dedicated.nsi
winlibs/common/makedist.bat
winlibs/common/python.bat
winlibs/common/status.bat
The module "winlibs" might be renamed to "winbase" to reflect that it does not only contain libraries IMHO.
But I'll help to add or write a tutorial on basic hud elemets and rules for netplay, also documentation and wiki should really be synchronized.
How about translating the help to all languages, at least the non development related help (if we have any). Perhaps some players can help out in adding some content. a general FAQ of the most common problems should be included (e.g. how can I restore 0.2.7.1 camera glancing?).
I'll talk to wrtl about that later, he had some idea about using the wiki to generate documentation.
joda's plan:
winlibs/common/res/icons/*.ico
winlibs/common/res/banner.svg
winlibs/common/res/banner.bmp
winlibs/common/armagetronad.nsi
winlibs/common/armagetronad_dedicated.nsi
winlibs/common/makedist.bat
winlibs/common/python.bat
winlibs/common/status.bat
The module "winlibs" might be renamed to "winbase" to reflect that it does not only contain libraries IMHO.
But I'll help to add or write a tutorial on basic hud elemets and rules for netplay, also documentation and wiki should really be synchronized.
How about translating the help to all languages, at least the non development related help (if we have any). Perhaps some players can help out in adding some content. a general FAQ of the most common problems should be included (e.g. how can I restore 0.2.7.1 camera glancing?).
I'll talk to wrtl about that later, he had some idea about using the wiki to generate documentation.
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Anyone object to thinking about putting all this stuff in the armagetronad module? I have a strong preference for putting everything needed to build a distribution into the core module, which would be most of armagetronad_build. And then the source distribution gets built from that and includes pretty much everything so that someone who gets a source distribution can build any of the packages we support, if they have the tools installed to do so.
Luke and Lucifer: my position is quite well defined. Exactly that which goes into the tarball belongs into the main armagetron module.
So, tron.ico is out, the docs are in.
The Windows build files are a corner case. They go into the zip source distribution right now, so it can be argued they also belong into the tarball. I don't mind, as long as they don't pollute the main directory there with tons of files. If they go into the VisualC subfolder where they once were (or rather, a codeblocks subfolder), it's fine by me, because by any argument that says they should stay outside, we'd also have to ban the Makefiles and the OSX project stuff.
But not everything belongs there. I hold that the "build" module needs to be separate. If you remember the discussion back then, that module contains spec files for debian, redhat and autopacke. It is common procedure to not include them into the tarball, because the real debian folks, making a real debian package with a different specfile, would get into trouble. Likewise for autopackage and redhat and of course, the aabeta upload script and the freshmeat announcement make target.
build_eclipse is actually a meta-build tool. It clearly belongs out of the main module.
Joda: I think the logical thing to do, then, would be to move the code blocks build files all neatly into a subfolder in the armagetronad module and leave winlibs as winlibs. But that's another point I don't really mind, as long as you don't make winlibs part of the main AA module Do what's easiest to work with for you and K later.
So, tron.ico is out, the docs are in.
The Windows build files are a corner case. They go into the zip source distribution right now, so it can be argued they also belong into the tarball. I don't mind, as long as they don't pollute the main directory there with tons of files. If they go into the VisualC subfolder where they once were (or rather, a codeblocks subfolder), it's fine by me, because by any argument that says they should stay outside, we'd also have to ban the Makefiles and the OSX project stuff.
But not everything belongs there. I hold that the "build" module needs to be separate. If you remember the discussion back then, that module contains spec files for debian, redhat and autopacke. It is common procedure to not include them into the tarball, because the real debian folks, making a real debian package with a different specfile, would get into trouble. Likewise for autopackage and redhat and of course, the aabeta upload script and the freshmeat announcement make target.
build_eclipse is actually a meta-build tool. It clearly belongs out of the main module.
Joda: I think the logical thing to do, then, would be to move the code blocks build files all neatly into a subfolder in the armagetronad module and leave winlibs as winlibs. But that's another point I don't really mind, as long as you don't make winlibs part of the main AA module Do what's easiest to work with for you and K later.
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
So in other words, you'd like the source releases to be the entire <branch> directory, not just <branch>/armagetronad ?Lucifer wrote:Anyone object to thinking about putting all this stuff in the armagetronad module? I have a strong preference for putting everything needed to build a distribution into the core module, which would be most of armagetronad_build. And then the source distribution gets built from that and includes pretty much everything so that someone who gets a source distribution can build any of the packages we support, if they have the tools installed to do so.
Releasing winlibs with all source releases would get annoying, though...
-
- Dr Z Level
- Posts: 2246
- Joined: Sun Mar 20, 2005 4:03 pm
- Location: IM: [email protected]
Why not have a separate src tarball for docs?z-man wrote:Luke and Lucifer: my position is quite well defined. Exactly that which goes into the tarball belongs into the main armagetron module.
I would argue that some random Debian person shouldn't be doing a separate package and should just include one we build...z-man wrote:If you remember the discussion back then, that module contains spec files for debian, redhat and autopacke. It is common procedure to not include them into the tarball, because the real debian folks, making a real debian package with a different specfile, would get into trouble.
Would your argument with the random Debian guy go as well as that with the Gentoo guy? BTW, how is it going? Debian has every right to make a .deb package that fully fits their needs. Ours will, for example, install into /usr/local (well, our RPM does). No, package specs don't belong into the tarball. Another reason: if one package spec is buggy, you don't want to make a new tarball. You just fix the spec and build the buggy package again with a bumpled build count.
About the docs: because it's silly. You separate your docs and your main program if the docs are an unbearable download burden. That's not the case here.
About the docs: because it's silly. You separate your docs and your main program if the docs are an unbearable download burden. That's not the case here.