Distribution requirements

[scunz]

General distribution tasks

• [ ] Setup a download page.

  Source distribution

• [ ] Build a script that assembles all MacGitver submodules and creates both a .tar.gz and a .zip (with LF and CR/LF line endings respective) out of that. Let's call that archive the MacGitver-All-archive.
• [ ] Setup a build instructions page, esp. designed for that MacGitver-all archive.
• [ ] Setup a general dependency page.
• [ ] Optional: Generate building instructions for HomeBrew
• [ ] Optional: Generate eBuilds and a MacGitver-Overlay for Gentoo, Funtoo et al.

  Binary distribution for Windows

• [ ] What Windows versions can we sanely support?
• [ ] Is the cmake generated NSIS sufficient?

  Binary distribution for Mac OS X

• [ ] Distribute a disc-image (.dmg) or just an App-Bundle (.App)?
• [ ] Should we support Mac-Ports?

  Binary distribution for Linux

• [ ] Check, if this a desire at all?
• [ ] If it is, on what should we settle: RPM? debian-packages?
• [ ] What distributions should we support?

  Feedback channels

• [ ] What kind of feedback channels do we need?
• [ ] Are GH Issues a good fit for us? All those GH-Guys keep telling, the more simple Issue tracking is, the more efficient it becomes. One of their arguments is, if you need something that cannot be done with GH-Issues, you're probably doing something wrong. However, since we've just tried to setup GH-Issues with cross referencing submodules and stuff, I'm actually not very fond of using GH-Issues. GH Issues is probably a good thing, when you're doing a simple library or a web page; actually anything with low dependencies. But for anything integrated and/or complex, it gets boring rather soonish. I really would appreciate a plain, old, ugly, unhackable and hard to maintain Bugzilla database. Say about that NetScape step-child what you want, but it's still functional and ever was. It has support for several products and they can be split into categories. Issues relation ships can be reflected, because each Bug in Bugzilla can form a DAG of its dependencies.
• [x] For sure, an important feedback Channel would be a mailing list.

  Notes:

• Qt5 is generally not ready to build upon. Guess that will not happen before a Qt 5.2 release.
  • Qt 5.1 should reintroduce platform specific extensions. Allowing us to use system provided 'HICONS' as QIcon classes again.
  • Font rendering on Qt5 for Linux is still broken. There seem to be no current plans to fix that.
  • No native integration into KDE; this requires KDE to be a Qt5 based application, which will still take some time.
• For later MacGitver Versions, provide so called -dev packages to allow user creation of custom plug-ins.
• This probably requires separating libGitWrap and libHeaven into a more modular build system (esp. the possibility to compile and install these separately. The combined build must [in a longer term] become a simple convenience that we provide).
• For MacGitver v0.1, do not provide a such a public API at all.

[antis81]

Concerning the feedback channel: Actually I tend to stay at GH, as I really like it. But, if we really decide to move I strongly recommend using Jira or Redmine. Both supersede Bugzilla by far in usability and maintainability. Both provide Projects (= Products) and Components/Subprojects. Linking and moving issues between projects just works. I just migrated a Bugzilla instance to Jira and it became a peace of cake - not only the migration itself. The complete infrastructure remains intact including every duplicate, reference, component, .... So for the users it behaves like Bugzilla - just in very, very cool. For our purpose, I would rather use Redmine though, as it is highly customizable and fits well for OSS projects. I have used all three (plus another one but I don't want to bloat the list :)) and in short: Bugzilla :-1:, Redmine :+1:, Jira :+1:.

I'm ok with mailing lists also. Maybe we should provide them first?

[scunz]

I did not know redmine before, but this looks really good. I like GH, too. Just that it is not exactly very feature-rich.

I will install a redmine instance; not sure where, might be local. Think this will solve few of my requirements, though for mgv we can as well go ahead with gh.

[scunz]

I was stuck for half an hour at a station today. I used that time to SSH into macgitver.org and installed ruby+rake+rails+redmine. Testing it is next on my ToDo list.

[scunz]

I'm ok with mailing lists also. Maybe we should provide them first?

Done :shaved_ice:

Subscribe: dev-subscribe(at)macgitver.org Unsubscribe: dev-unsubscribe(at)macgitver.org Post: dev(at)macgitver.org

[scunz]

I've also been setting up Mailinglists for gitwrap and heaven (gitwrap@ and heaven@). While doing that I fixed a problem with -subscribe and -unsubscribe that caused ezmlm not to respond to those addresses.