PseudoPoll: should every [RC] be pushed immediately?

[o11c]

In line with the tmwAthena Development Board guidelines, this is not a forum Poll, but a manual one.
Note, however, that Artists may have some input as well.

In this discussion, any use of the word "content" means "anything that is not art, but depends on it". This means scripts and stuff, worked on under the approval of the Board. (otherwise, there's no reason to expect it will get in game)

Background:
With the move to use Trello, it is quite clear how works move across the tag chain:

• content developer -> [REQ], when
• artist -> [CPT], if an artist thinks something would be useful
• [REQ] -> [CPT] or [REQ] -> [WIP], by an artist willing to work on it
• [CPT] -> [WIP], by an artist willing to work on it, which should have come from [REQ] or have some other form of acceptance by content developers.
• [WIP] -> [FND], when the artist feels it is finished (does this include XML?)
• [FND] -> [RC], when the artist community agrees it is finished

(This should get added to the Guidelines page on the wiki ... which still mentions Mantis...)

However, what is not clear is when graphics take the atomic step of getting added to git and archived on Trello.

Some people suggest that is properly placed in the [RC] category get added to git immediately. Others disagree. There are shades - are tilesets different from items different from mobs different from NPCs?

To support is to say that things should be pushed to git immediately. Under this strategy, people creating content look in the git repository.
This has the disadvantage of requiring players to download graphics that are not yet used. Also, content developers will not see things that are still in progress, nearing completion.
This has been done in the past, leading to many items in git that are not released, often because really complete.

To oppose is to use the [RC] category on Trello as the place for content developers to retrieve art. The git repository is kept small, containing only what is needed.
In the past, if graphics were not pushed to git, they would likely be lost in the forums. But, with Trello, we have a place for things not to get lost.

I mentioned several other issues in passing, but please, keep discussion in this thread to the subject of moving [RC] to [GIT].

---

I oppose.

[Freeyorp101]

I oppose.

Trello is acting much like mantis once did, as a way to track states of projects and subprojects. Including them in the repository provides no additional use, and also means yet another state needs to be kept track of: being included in the repository without being used.

In addition, sending them to the repository immediately means that they will be included in the next client data update, regardless of whether it is used or not. This also increases the chances of ghost data, either via later updates to fit the project it is included with, by structural reorganization, or any other process.

Finally, it's never a bad idea to play nice with people's data. Even more so, considering we've had a few mobile clients pop up recently.


---Freeyorp

[Kandiman]

I oppose.

Mostly for the same reasons stated above, but also for the fact that once data (particularly graphics) are added to git, the likelihood of changes or improvements to them decrease drastically. The system I see developing in Trello looks quite stable (so far) and well organized, which will avoid any work being lost to the depths of forum hell, but still allow for minor adjustments, if required, before being committed.

[Alige]

I support.

My reason is that the trello website will soon become a mess unless we push what we have in RC. When we add new images that we don't use, the players do indeed need to download them but that is nothing, an image is pretty small. Furthermore, the more we have in the database, the more we can test, the more ideas we can get. Having something we would want to try, that is in [RC], would be quite annoying.

Regards.

[o11c]

an image is pretty small.

Currently, the client-data repository has (uncompressed) 12 344 294 bytes in 777 .png files, 1 061 563 bytes in 61 .ogg files, 1 087 328 bytes in 395 .xml files, 1 765 455 bytes in 160 .tmx files, and 25 195 bytes in 13 other files, for a total of 16 283 835 bytes in 1406 files.
When these are put in a .zip, the compression of .png and .ogg will be negligible, the compression of .tmx will be poor (because we're still using gzip-compressed maps instead of CSV), and the compression of .xml will be good.
Obviously .png is the largest contributor. Although an individual .png is small, making it a policy to push unused .png files will soon make client-data a mess.

Furthermore, the more we have in the database, the more we can test, the more ideas we can get. Having something we would want to try, that is in [RC], would be quite annoying.

This could be solve by mandating the attachment, to the [RC] card, of a .patch.gz file for client-data and a snippet that can be added to item_db2.txt or mob_db2.txt

[Jenalya]

I oppose.

I agree with the reason already stated against pushing things immediatly. What I like to add is that having a larger database in the git repository (more entries in the db's) makes it harder to work with and things getting forgotten inside the repository because they just get overseen within all the stuff might be likely as well.

On the other side there is the danger of the RC list becoming very big and therefore hard to look through. I wonder if it'd make sense to have several RC lists ordered by type of graphic (tileset, npc, mob, item)?
If this isn't feasible and the RC list(s) on trello become too messy, this might need a reconsideration.

About the issue of testing the graphics, I think graphics in the RC list should have their xml attached and a snippet that can be added to the dbs, as o11c said.

[Alige]

Instead of pushing everything that is in [RC], meaning that these graphics are finished, we could maybe push them in the tmw art repo. I was thinking of creating a Main Folder called Finished Graphics in which you would have everything sorted out. Anything not finished should of course not be pushed in the mainline or in this repository. When something gets pushed to the mainline, we can then delete it from the tmw art repo.

Each last folder should contain the xml, the spritesheet, the icon and a small txt file that says who the original author is and maybe who fixed/finished this art. By "last" I mean the folder that is after the category. In the first example, the "last" folder is "Assassin Cap".

Types of art:

• Equipment
• Food
• Generic
• Monsters
• NPCs
• Particle Effects
• Skills
• Tilesets
• Use

Equiment types:

• Ammo
• Charms
• Chest
• Feet
• Hands
• Head
• Legs
• Rings
• Shield
• Weapon

Examples:

• Tmw Art / Finished Graphics / Equipment / Head / Assassin Cap / assassin_cap.txt
• Tmw Art / Finished Graphics / Generic / Plush Mouboo / plush-mouboo.png
• Tmw Art / Finished Graphics / Head / Herb Crown / herb-crown.xml

I think that this is the best solution to avoid losing things and making Trello a complete mess.

Hope this helps,
Ali-G

[alastrim]

I oppose

You guys already covered most of the reasons why I think it is not a good idea right now. Basically, I still think the RC card is a good place to retrieve art and pushing things to GIT immediately would make things (specially the database) confusing.

[Wombat]

I support

These problems are negligible and inflated. Much of our 2010 art was based on stuff already added to the repo rather than just pulling from art that hasn't been added yet. The ease of availability made much of this possible.

Keeping art as [RC] on trello without moving it will bog down and get a bit crowded, as the speed of work completion arrives.

However, a reasonable compromise is to move to tmw-art repo as Ali-G suggested, which would act in much the same way with ease of availability when content is ready for art additions and then be added and tested during this period.

[i]

I have no opinion. yet... and AFAIK my vote means nothing on this board :P

However, a long time ago we got separate git repository called tmw-art. Maybe additional git repository with similar file structure (as in client) could serve as quarantine for all those finished files, but yet not released in game world. In case of releasing them, we simply move files between repositories.

The idea is very similar to Ali's, but in this case we would have the exact directory and file structure as in working client. Maybe we could use the git branching system for doing this? And then there is no need for separate repo. Users usually download only MASTER branch.

[o11c]

Some practical problems with the "separate git repository" idea (though I don't oppose it, per se):

• if it's not a clone, we lose the benefit of free pushes and pulls (learn to use git-new-workdir!)
• if it is a clone, there will be millions of merge commits and the only way to add it to main client-data will be git-cherry-pick, which is not as friendly as git am. It will also become very difficult to change stuff (both technically and psychologically) once it's in the repo. The alternative to millions of merge commits is millions of rebase/squash commits, which is to be avoided at all costs in a git repository, but is free if it's merely an attached .patch.
• trello is an easier place for a content developer to browse art. In particular, you haven't considered my point about "things that are still in progress, nearing completion" that are wanted.
• there are also fragments that need to go in server-data, and there is no feasible way to add these.