Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Github as primary source repository for SourceMage?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: David Kowis <dkowis AT shlrm.org>
  • Cc: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Github as primary source repository for SourceMage?
  • Date: Thu, 18 Sep 2014 12:46:52 -0300

On Thu, Sep 18, 2014 at 11:16 AM, David Kowis <dkowis AT shlrm.org> wrote:
> On 09/17/2014 09:55 PM, Ismael Luceno wrote:
>> The way PRs are formatted by Github is plain wrong. But then, we do
>> have our own usage problems, like the insurmountable amount of merge
>> commits, or the lack of uniformity in commit messages.
>
> Can you be a little more specific about how the pull requests are
> formatted wrong? It just gives you a unified diff presentation (and now
> also does side-by-side)

First, on commit logs for PRs, it uses variable-sized fonts (on commit
messages too), so people have no idea how long it is, and this
invariably makes it look horrible. Worse, some people write it in a
single line, and GitHub doesn't even try to fix that (though the
proper way to deal with it is making the user aware of the problem).

Second, it makes verbatim content a pain because you have no clue how
it will look.

Third, it tries to be smart the wrong way, like transforming useful
information into silly images!! or linking anything prefixed by "#" to
a PR or issue ID. Same happens with plain commit IDs too but that's
rarely a problem, I think it doesn't try with shorter strings, but
might just have been that they didn't coincide.

There are probably a dozen of other issues that didn't come to my mind
right now, but you get the idea...

>>> * Pull requests for our wiki will be stupid easy (also no spam!)
>>> * Issue tracking is robust and capable without being overcomplicated
>>
>> I never liked the way it is handled, queries are very limited, it's
>> overall far less powerful. I would prefer using another service for
>> that.
>
> As an example: https://github.com/cucumber/cucumber-jvm/issues has a
> reasonably robust search mechanism in the filters bin. I'm usually able
> to find whatever I'm looking for. Additionally the labels make it
> reasonably easy to group, and if we go with milestones you can group
> things that gate a release (maybe more useful for cauldron and sorcery
> than grimoire, but whatev) I think that meets most of what we need out
> of a "I've got a problem" tracking thing along with noting when the
> resolution happened.
>
> What's missing that you need?

Issues can have a single owner, no CCs (indirectly through watchers I
guess), no history, mutable (e.g. you can edit other's comments),
limited resolution states, no way to define a flow within the system,
and no way to do specialized views based on queries that can be saved.

<...>
>> I would go for it as long as we don't use something github-specific,
>> and mainly because even if we can take the data away anytime, I
>> dislike the tools for the most part, they tried so hard to make it
>> work for the average joe that they broke them for people like me!
>>
>
> Got any non-self hosted alternatives? Got any self-hosted alternatives
> that are super easy to maintain? Git integration would be nice, so that
> issues can be closed via a commit message (that's a nice to have, but
> it's super convenient when you start using it)

IMO, issues should be completely isolated unless they are actually
part of the repository, because you can't go and change the history
every time your issue tracker changes.

> Personally I'd prefer a non-self-hosted solution, because that's one
> less thing to maintain if we don't need to.

Don't know any, but I would go for Roundup, I have no problem
maintaining it from time to time.




Archive powered by MHonArc 2.6.24.

Top of Page