a nicer overview page about kwarc.github.io HOT 9 CLOSED

That definitely looks like a nice landing page :) Gives me extra incentive to start moving my repos to KWARC one by one.

from kwarc.github.io.

One thing that I notice - some of the projects have a KWARC Trac, but are also using GitHub issues. That's definitely a bit confusing. I was hoping that as we move onto GitHub we might also phase out the Tracs at KWARC, is that the intention in Bremen as well?

from kwarc.github.io.

I'm not sure how it is for the other projects but for JOBAD the idea is to
use the TRAC for planning and Github for user-based bug reports.

On Thursday, August 22, 2013, Deyan Ginev wrote:

That definitely looks like a nice landing page :) Gives me extra incentive
to start moving my repos to KWARC one by one.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-23100027
.

from kwarc.github.io.

Sounds like a simple distinction between "bug" and "enhancement" tickets to me.

Putting my KWARC admin hat on, not having to maintain the Trac installations ourselves would be a very good step forward for reducing the clutter on our machines. Michael had mentioned something about the Trac roadmaps being better, i.e. being able to explicitly set tickets as depending on each other.

But you can get far with a good labeling scheme and switching to smaller milestones instead of large milestones with a lot of blocking tickets.

Then again my GitHub kool aid levels are quite high nowadays, so there is definitely bias in my opinion.

from kwarc.github.io.

So you are suggesting getting rid of (some) TRACs?

I have started looking into the issue tracker more, and it is more
powerful than I first understood, and the only feature that seems
missing are the issue dependencies. Maybe that is something we can live
without.

So that leaves the problem of how to migrate the tickets from the TRAC
to github. For that I saw some scripts.

But what to do with the TRAC wikis (some of them actually use them).

And we have a couple of private/non-public TRACs, what to do with them?

Michael

On 22.8.13 19:57, Deyan Ginev wrote:

Sounds like a simple distinction between "bug" and "enhancement"
tickets to me.

Putting my KWARC admin hat on, not having to maintain the Trac
installations ourselves would be a very good step forward for reducing
the clutter on our machines. Michael had mentioned something about the
Trac roadmaps being better, i.e. being able to explicitly set tickets
as depending on each other.

But you can get far with a good labeling scheme
http://www.stateofcode.com/2013/06/using-github-issues-effectively/
and switching to smaller milestones instead of large milestones with a
lot of blocking tickets.

Then again my GitHub kool aid levels are quite high nowadays, so there
is definitely bias in my opinion.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Prof. Dr. Michael Kohlhase, Office: Research 1, Room 168
Professor of Computer Science Campus Ring 1,
Jacobs University Bremen D-28759 Bremen, Germany
tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase

[email protected] http://kwarc.info/kohlhase

from kwarc.github.io.

For migrating tickets,
http://stackoverflow.com/questions/6671584/how-to-export-trac-to-github-issuesshould
be helpful.

Also, github has a wiki feature, so we could do some things there. However
I'm not sure how well it is integrated with the issue tracker. For static
things, we can always use Github pages like I'm using
for the JOBAD doc.

Wiki editing can be restricted somehow (I think), however github also
offers completely private repositories, although they are only included in
their paid plan.

On Sunday, August 25, 2013, Michael Kohlhase wrote:

So you are suggesting getting rid of (some) TRACs?

I have started looking into the issue tracker more, and it is more
powerful than I first understood, and the only feature that seems
missing are the issue dependencies. Maybe that is something we can live
without.

So that leaves the problem of how to migrate the tickets from the TRAC
to github. For that I saw some scripts.

But what to do with the TRAC wikis (some of them actually use them).

And we have a couple of private/non-public TRACs, what to do with them?

Michael

On 22.8.13 19:57, Deyan Ginev wrote:

Sounds like a simple distinction between "bug" and "enhancement"
tickets to me.

Putting my KWARC admin hat on, not having to maintain the Trac
installations ourselves would be a very good step forward for reducing
the clutter on our machines. Michael had mentioned something about the
Trac roadmaps being better, i.e. being able to explicitly set tickets
as depending on each other.

But you can get far with a good labeling scheme
http://www.stateofcode.com/2013/06/using-github-issues-effectively/
and switching to smaller milestones instead of large milestones with a
lot of blocking tickets.

Then again my GitHub kool aid levels are quite high nowadays, so there
is definitely bias in my opinion.

—
Reply to this email directly or view it on GitHub
<#1 (comment)
.

---

Prof. Dr. Michael Kohlhase, Office: Research 1, Room 168
Professor of Computer Science Campus Ring 1,
Jacobs University Bremen D-28759 Bremen, Germany
tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase
[email protected] <javascript:_e({}, 'cvml',

'[email protected]');> http://kwarc.info/kohlhase

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-23222081
.

from kwarc.github.io.

Here's an interesting option for working with Github pages: http://jekyllrb.com/docs/home/

Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through Markdown (or Textile) and Liquid converters, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server. Jekyll also happens to be the engine behind GitHub Pages, which means you can use Jekyll to host your project’s page, blog, or website from GitHub’s servers for free.

A succinct overview of what it can do is here: http://jekyllrb.com/docs/structure/

from kwarc.github.io.

Dear all,

I have also been looking at gollum (a git-based wiki), which can
directly work on a git repository. But I am having problems running it
locally.

Michael
On 25.8.13 15:35, Joe Corneli wrote:

Here's an interesting option for working with Github pages:
http://jekyllrb.com/docs/home/

Jekyll is a simple, blog-aware, static site generator. It takes a
template directory containing raw text files in various formats,
runs it through Markdown (or Textile) and Liquid converters, and
spits out a complete, ready-to-publish static website suitable for
serving with your favorite web server. Jekyll also happens to be
the engine behind GitHub Pages, which means you can use Jekyll to
host your project’s page, blog, or website from GitHub’s servers
for free.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Prof. Dr. Michael Kohlhase, Office: Research 1, Room 168
Professor of Computer Science Campus Ring 1,
Jacobs University Bremen D-28759 Bremen, Germany
tel/fax: +49 421 200-3140/-493140 skype: m.kohlhase

[email protected] http://kwarc.info/kohlhase

from kwarc.github.io.

Right, my suggestion above was that we move all projects that carry an implementation under the same name to Github, together with the Trac and Wiki components.

In terms of private (=hidden) Tracs at Jacobs, it would definitely be cheaper to host them ourselves, as the price tag for hosting private repositories on GitHub is about 70 euro/year, which probably isn't worthwhile for us.

And if we're discussing things we are keeping on our own servers, I would put my conservative hat on and suggest we don't touch our working systems, as e.g. the KWARC Trac is quite operational at the moment and doesn't need any admin time dedicated to it. Switching over to a new engine that we host ourselves doesn't have any significant benefits that I can see. In truth, if we're using a Drupal installation for the KWARC website, a lot of the static content in the Trac can be migrated as Drupal pages that require permissions of say "PhD and up".

from kwarc.github.io.