Helping with development

Post Reply
chrio
Posts: 66
Joined: Mon Aug 22, 2016 11:34 am

Helping with development

Post by chrio » Wed Sep 28, 2016 6:57 am

What's the best way to help with mudlet development? For instance if:
  • 1. I have a small bugfix of just a few lines of code.
    2. I want to add some new functionality to mudlet.
    3. I want to discuss some part that may need a change.

User avatar
Vadi
Posts: 4703
Joined: Sat Mar 14, 2009 3:13 pm

Re: Helping with development

Post by Vadi » Wed Sep 28, 2016 10:38 pm

For #1, just submit a pull request. For #2 and #3, let's talk about it on https://gitter.im/Mudlet/Mudlet :)

chrio
Posts: 66
Joined: Mon Aug 22, 2016 11:34 am

Re: Helping with development

Post by chrio » Thu Sep 29, 2016 11:54 am

Thanks! I'll create an account on gitter soon then. :)

Some follow up questions:

Should our name be added to the file copyright headers when changing existing files?
If yes, does that apply for minor changes aswell, or where is the limit?

- Fixing a bug on one line?
- Changing documentation?
- Deleting unwanted stuff? (technically, nothing original is added in this case, but content is changed).


I couldn't find any routines on how to actually do the pull request and I'm new to github. I think I have the basic idea of it, but is this the following the correct way?

1. make a fork on github and check it out locally (fork from the development version?).
2. make a branch for the change (is there a naming standard for the branches somewhere to read?)
3. Make neccessary changes, commit it. (same here, any guidelines for commit comments that I should know of?)
4. Push to github
5. Make a pull request using the new branch

Good so far or did I get something wrong/miss any steps?

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

Re: Helping with development

Post by SlySven » Thu Sep 29, 2016 8:13 pm

I think you have the general gist of it. You'll want an account on GitHub and, once you fork the Mudlet repositories to there, you'll check out the code on your local machine and push your changes back to YOUR fork of the Mudlet repositories there, and then the Pull Request is the same as saying to Vadim (or someone else with write access to the Mudlet github repository) "Hey, take a look at my fix/improvement, why not include it!" which, after possibly a bit of peer review that takes place in the PR can happen.

<aside>This is not to be confused with Pier review which is where a decision is made whether something is so unwanted so as to dump it - chained to a concrete block - off of the nearest jetty into a convenient stretch of water! :lol: </aside>

When setting up your local Git repository you will want to add the Mudlet repository as a remote to track so that you get any changes that Vadim/Heiko (theoretically) or any other Mudlet Maker makes to it. If you then do a git fetch --all it will update your local copy.

I try to update the copyright line including the year when I change a file, including deletions within a source file - obviously complete file removal gets logged by the commit that does it. Documentation is a bit less obvious, though again the wiki will track who makes changes.

Note that when you modify the source code (or at least the C++ stuff) you must be able to release your changes under the GNU Public Licence 2.1 (or at a subsequent user's wish, later version's terms) that we keep that under - some of the Qt libraries now require a GPL 3.0 I believe for binaries but the source is kept at 2.1 for maximum flexibility. This might seem a minor point but one of our former contributors did cause us some concerns a couple of years back when their Employer's Employment Conditions impacted on things (as they needed formal permission to contribute to other work and our project counted as that and the permissions they got and used was for 2.1 ONLY for a time until it got straightened out :shock:)

User avatar
Vadi
Posts: 4703
Joined: Sat Mar 14, 2009 3:13 pm

Re: Helping with development

Post by Vadi » Thu Sep 29, 2016 10:42 pm

Yep, all spot on.

Right now, we'd like to get 3.0 out the door, so bugfixing is preferred over new features.

chrio
Posts: 66
Joined: Mon Aug 22, 2016 11:34 am

Re: Helping with development

Post by chrio » Fri Sep 30, 2016 9:21 am

SlySven wrote:When setting up your local Git repository you will want to add the Mudlet repository as a remote to track so that you get any changes that Vadim/Heiko (theoretically) or any other Mudlet Maker makes to it. If you then do a git fetch --all it will update your local copy.
Ah I see, I was curious on how to get changes from the original into the fork.

For anyone else wondering how to do this, I ran this from the shell in my local repo (more info on on github):

Code: Select all

git remote add upstream https://github.com/Mudlet/Mudlet.git

chrio
Posts: 66
Joined: Mon Aug 22, 2016 11:34 am

Re: Helping with development

Post by chrio » Sun Oct 02, 2016 4:21 pm

I could use some background on the different branches, seeing that "development" is the default branch, but two more forks are active: release_30 and readme-update.

User avatar
Vadi
Posts: 4703
Joined: Sat Mar 14, 2009 3:13 pm

Re: Helping with development

Post by Vadi » Mon Oct 03, 2016 12:28 am

release_30 is for bugfixes only, it is what 3.0 final will be. development is for the same bugfixes but also new features are allowed.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 102 guests