Jabber bundle - Githubissues

senny / cabbage

get the maximum out of emacs

http://senny.github.com/cabbage/

156 stars 21 forks source link

Jabber bundle #127

Closed jone closed 12 years ago

jone commented 12 years ago

Added:

emacs-jabber to vendor as submodule
Jabber bundle with C-p j binding for starting jabber in a separate perspective.

@senny any objections to adding an additional submodule?

senny commented 12 years ago

@tonini informed me, that we have a History.txt. I think we should either start adding stuff to the file or get rid of it. @jone what do you think?

jone commented 12 years ago

Well, the plan was to diff this file when running the upgrade script - but that is not yet done. I think it is only useful when maintained consequently. If we are only updating it sporadically it is more confusing. We also have the git log - and since we are "deploying" with git we always have the log - which makes a history file less necessary.

The question is: is the git log too detailed for normal users? Would we have a benefit when we have a filtered and generalized history file? If we are using it we should also display it when running the upgrade script (but we could also display the git log there).

tonini commented 12 years ago

What do you guys think about a versioned e-max? The history file would also be a bit more informative with version numbers and also makes more sense to use.

@jone Yes, I think the git log is too detailed for the normal user. I mean, you guys did a great job with e-max, put all these emacs complexity together to a easy to use bundle, so let's make it more suitable for ppl which starting with emacs. I know git have nothing to do with emacs, but it's about serve all informations/changes about e-max quick and ease... :)

jone commented 12 years ago

Versioning We have the strategy that master is stable and the update.sh script updates to the latest master, not to a tag. Although we could tag e-max I'd see it more as an additional information rather than real versioning. I would not change the update script to updating to tags since this would only hold back changes. So I don't really see the benefit in case of e-max.

Changelog We can write a changelog, I'm not strictly against it but if we do we have to do it seriously. But I'd change the structure of the changelog and not group it by features / bugs but in a historical order - but we could "tag" the changelog entries (e.g. prefix with BUGFIX or something). We should also update the update script as described in #112.

I think we should move the discussions to #112 since it is off topic for this pull request.

@senny thoughts?

senny commented 12 years ago

Versioning Not necessary in my opinion. I think milestones is a good idea to work for a specific goal but semantic versioning would do more harm than good.

Changelog I'm not a big fan of manually written Changelongs. They are mostly flawed and not accurate and you have to resort to a source-control log instead. I would appreciate though if the update script has some output to what has changed. I'm fine with either a git-log --first-parent or some kind of tagging in the commit messages like feature: abcd and then have a filtered view.

@jone merging this pull-request without History changes.