Set-Up for Mudlet Development

Post Reply
User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Set-Up for Mudlet Development

Post by SlySven »

This might seem like a newbie question but what IS the recommended process to get set up for Mudlet development?

The suggestion seems to be, (and forgive me if I seem to put things strangely as SCM software such as SVN or GIT is new to me) :
A). Set-up a publicly(?) readable development git repository (on github or gitorious), which has to be at least readable by Heiko so they can pull what is wanted into the master repository. I already have some secure cloud storage that can mirror a local directory so alternatively I might see if that can be used.

B). Get a bug tracker account on launchpad so that I can comment on (and take responsibility :lol: ) for issues. Currently though I am having trouble with that site: previously I couldn't get to the "register" page as I was getting "Invalid OpenID transaction" if I click on the link to it; now I find I can get to try and register for an OpenID but I keep getting something about using a stale browser window whenever I actually get to the point that an account should be created for me and it fails to happen - doesn't help that examining the source HTML for the page shows some worrying HTML errors... :evil:

All in all, I'm not having much success with this so far, sigh.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Help Wanted

Post by Heiko »

A) You don't need a public repo. It's enough to have a private git repo on your computer and send me your git patches by email.
B) I had a bunch of problems with lauchpad in the past, also, but we haven't found a better bug tracker. The good thing about the tracker there is that the discussion takes place by email mailing lists - and I rather work with email than websites :)
c) git howto: http://git-scm.com/book

User avatar
chris
Posts: 493
Joined: Fri Jun 17, 2011 5:39 am

Re: Help Wanted

Post by chris »

I would also recommend getting git extensions as well. I was a horrible, horrible git user until I got that :). It makes good practices easy by taking care of most of the command-line-fu for you.

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: Help Wanted

Post by demonnic »

In my experience (I manage the entire SDLC stack at my office) most developers will only really use a few commands regularly in git:

git add
git commit
git pull
git push
git merge
git log
git status
git diff

And for most of them, what it does is fairly obvious from what command it is you've run. You can cut it down even more to the ones most of them will use every day:

git pull
git push
git commit
git add(maybe)

In some ways it's better if you approach git/hg/bzr/DSCM in general without any previous SCM experience. The people I've had the biggest problems getting moved into DSCM were the ones who had a lot of experience with things like SVN, CVS, starteam, and others.

It only really gets complicated if you have people doing force pushes and ignoring warnings from git when they try to do things they don't actually understand. Or if you're doing some hunting in the repository history to figure out what introduced a bug (git bisect is magic when you can apply it).

On the plus side, every person who checks out a git repository has a fully functioning git repository which can be cloned from, merged to, etc. just as though it were a remote repository on a server somewhere.

tl;dr
git isn't that difficult, just dive in and try it. Unless/until you hit an actual snag in your scm process, it is fairly easy to keep it simple. But when you need to do complicated stuff it's there for you.

ETA: that all being said, I use git -constantly- and I'd still look up the syntax on some of the lesser used commands. Because why not be extra sure when doing something you don't do regularly?

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Help Wanted

Post by Heiko »

It's not enough to learn the most common git commands! This leads nowhere. You need to understand the basic concepts behind git.
1. Git makes branching super cheap. This is the most fundamental idea behind Git -> use a branch for every non trivial feature or patch and merge the branch when it's "ready".
2. Make sure that you understand the difference between "merge" and "rebase".
3. Make sure that the patches that you send to me are appliable -> setup a remote tracking branch of the official sourceforge.net git repo and test if your patch applies.
4. Configure your real name and an email address that you want to use for Mudlet development globally. I don't commit patches without proper name and email address.

The most important commands that I expect every developer working on Mudlet to fully understand and use are:
git branch
git checkout
git reset
git rebase
git merge
git blame
git fetch
git pull

Make sure to use the "staging area" concept of git when assembling commits and use a meaningful commit message.
Good git gui clients are:
windows: http://sourceforge.net/projects/gitextensions/
linux: http://sourceforge.net/projects/qgit/

Gui clients are helpful when staging commits and provide nice graphical representations of the branches. However, that's about it. Imho it's better to use the git command line for the rest. GitExtensions ships with a git bash command line.

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Help Wanted

Post by Heiko »

We should transfer the last couple of postings about Mudlet development into a new Mudlet development howto thread, but I don't know how to do this.

Edit: Well I just learnt how to! SlySven

User avatar
demonnic
Posts: 884
Joined: Sat Dec 05, 2009 3:19 pm

Re: Help Wanted

Post by demonnic »

Heiko is correct... I am a bit guilty of taking the approach of "first get them committing and not scared of the new tool" by default. And anyone who wants to make good use of git really should read the book Heiko linked to above. It's invaluable.

I would also add to the list of useful commands

git cherry-pick
git stash

Daagar
Posts: 89
Joined: Fri Feb 19, 2010 2:42 am

Re: Help Wanted

Post by Daagar »

If you _do_ have a SVN/CVS/whatever background, check out TortoiseGit. Since many SVN users are likely comfortable with TortoiseSVN (assuming Windows), then TortoiseGit is a much more comfortable intro cause it "looks the same". I don't claim it does everything and you can ignore the command line - just makes the transition a little less painful.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Set-Up for Mudlet Developement

Post by SlySven »

Advisory for contributors looking to submit code to the Mudlet project

Please can you ensure your contributions are licensed: GNU Public Licence Version 2.0 or later or a licence that is compatible with those terms. Currently we release the application as GPLGv2.0 from such source material but if you do not include the "or later" it will cause issues if we have to switch to a newer version of the GPL in the future[1] - we would then have to track down either you, your estate, your (former) employers, your legal representative and/or your pet cat to get the relevant party to agree to re-license your work under the newer licence or find a way to cut out your contributions and replace them with something equivalent but not derived from that code. {Well, maybe not you pet cat - unless you have shuffled off this mortal coil and left everything to them} ;)

In case this seems a bit far fetched it was found to be a concern recently and some of the existing developers were worried that we might have to lose several months of valued stuff from one developer who had not been able to agree to the "or later" bit when clearing things with the people who paid them to write software during the course of their work. Fortunately the matter was resolved in a successful manner, but please also be certain if you give us code that you can do so without compromising things like, say, your employment! :o

For source code contribution that are new files you can include the header contents that can be found in the git source repository files in ./templete/cpp or ./templete/h in the top of the new C++ class ".cpp" or header ".h" files respectively you produce, then:

For all source code contributions: update the copyright line at the top of the file as part of the above mentioned header, so that it includes the year of your contribution and your identifier/contact detail. Although this has not been done totally religiously in the past, for contributions that have been entered by the project leaders inserting patches etc. from others it should still be possible to track those others contributions if necessary - and indeed the github platform we are now using does make the task of determining the parentage of a piece of code easier if if is ever needed to be determined. Nevertheless, putting your moniker at the top of each file that you touch makes it the most simple it could be! :D

For other items without a copyright "header": that are submitted via github, e.g. icons, a one line comment in the commit message that includes something about licensing the items under the GPLv2 or later (or GPLv2+) should, IMHO, be OK - with the proviso I'm Not A Layer! :geek:

Now that I have got the formal stuff out of the way - you coders get out there and have fun... :D

[1] It is possible that we may have to change to use the version 3 GPL in the future as some new parts of the Qt libraries will require code using it (with a GPL licence) to be version 3 or later - this will not be a problem with the current Mudlet code as it includes that "or later" provision, but if any component had a version 2 ONLY licence that would be incompatible with such terms.

Post Reply