search

brata-hsdc / brata.masterserver

Behind-the-scenes coordination and support for the HSDC
Apache License 2.0
1 stars 0 forks source link

Simplify and Enhance MS Design #4

Closed ellerychan closed 8 years ago

ellerychan commented 9 years ago

Continuation of Simplify and Enhance MS Design brata-hsdc/brata#74 Part 3 only:

Simplify the MS design and operation as follows:

Use a Python-based framework such as Django. Using Python would have made it easier for more people to help, and using Django would provide much of the infrastructure needed to make a REST-style, MySQL-backed, web application.

jawaad-ahmad commented 9 years ago

This is a pretty largely-scoped issue; perhaps it should be broken down.

ellerychan commented 9 years ago

Or broken up. Go for it.

jawaad-ahmad commented 9 years ago

Created:

Part 3 will continue here.

ellerychan commented 9 years ago

I just pushed some initial code for this. I'm starting to build the database schema. I really could use some Jaron input.

I made a schema diagram. I put the .graphml file in the transition folder. I should somehow attach a web-viewable version of it to the wiki. @jawaad-ahmad in particular, but anyone who knows can answer: What is the best way to keep these two views of the same document organized and synchronized. When I save the .graphml file I can also save a .png or .svg or .pdf version.

ellerychan commented 9 years ago

Also, I abandoned the issue_74_start_django_project branch and started a new one called start_django_project_issue4. I am going to delete issue_74_start_django_project.

jawaad-ahmad commented 9 years ago

Should we settle on a naming convention for issue branches, or does it not matter in Git? I was thinking of something simple like issue74 and that's it.

Should we open pull requests to review documents such as your .graphml file in the transition folder?

Regarding keeping them in-sync, should the contributor manually run ImageMagick's convert to save as the desired format(s)? Should we add a commit hook into the repository to run convert automatically? Does this mean everyone needs to have ImageMagick installed to do this?

For any generated files, I would recommend some sort of generated subfolder in which to place any generated artifacts. This can apply to any generated source files as well.

My personal preference is to avoid committing generated files in general where possible and instead incorporate the generation into the build process. Generated files can still be output to the generated subfolder or some other location.

Sometimes that's not possible or convenient, so in those cases I would be OK committing generated artifacts to the repo.

I understand we can link using [text](absolute-or-relative-path). I've started using this to refer to wiki pages from issues. To link to our Process page, I put in a link to [Process](../wiki/Process) here because we're in the same repo. If I was entering this link into an issue in the brata repo, I would enter [Process](../../brata.masterserver/wiki/Process).

If no one has any objections from wiki pages to source repository files, maybe we can keep the generated .svg file local to its source and then link into the source repo from the wiki page. Maybe something like [Image](../path/to/file.svg)?

ellerychan commented 9 years ago

Should the contributor manually run ImageMagick's convert to save as the desired format(s)?

I don't think that will work for .graphml files. But it is easy to export from yEd into an image format. I suppose that possibly yEd has a command line way to do that, but I don't think so.

If no one has any objections from wiki pages to source repository files, maybe we can keep the generated .svg file local to its source and then link into the source repo from the wiki page. Maybe something like Image?

I ran into two problems:

  1. I don't know how to construct the relative path between different repos. I tried a couple of times but ended up putting an absolute path to get from the brata repo to the brata.masterserver repo.
  2. I couldn't get the .svg to display in the wiki page, so I ended up making a .png, just so I could move on.

If you figure out how to do either of those, I'd like to know, and you might add them to the Process page.

jawaad-ahmad commented 9 years ago

I gave it a try too. No luck.

I started a Wiki section on the Process page.

ellerychan commented 9 years ago

Should we settle on a naming convention for issue branches, or does it not matter in Git? I was thinking of something simple like issue74 and that's it.

Git enforces no convention. I would prefer to have at least a clue in the branch name indicating its purpose, so I don't have to go chase down the issue to figure out what it is for. Typically the branch name would describe the feature being implemented. Seems good to include the issue number at the end. Not worth making extra rules about it, IMHO.

jawaad-ahmad commented 8 years ago

Anything left to do for this, or can we mark this as resolved?

ellerychan commented 8 years ago

Superseded by many more specific Issues, so this one can be closed.