Closed d78ui98 closed 6 years ago
Try to follow this git commit message guidelines by Linus - these are just guidelines.
A good commit message looks like this:
Header line: explaining the commit in one line
Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc etc.
The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
74 characters or so. That way "git log" will show things
nicely even when it's indented.
Reported-by: whoever-reported-it
Signed-off-by: Your Name <youremail@yourhost.com>
where that header line really should be meaningful, and really should be
just one line. That header line is what is shown by tools like gitk and
shortlog, and should summarize the change in one readable line of text,
independently of the longer explanation.
I think you can push changes at once. No need to make separate commit for each change. Instead make bunch of relative changes and explain in commit.
This would be the best thing. I would also say commit some changes after testing them (by running vagrant up
and checking that they do what they are supposed to do). You can also commit if there is some problem that you cannot fix yourself and you expect some help from the others to fix it.
Try to follow this git commit message guidelines by Linus - these are just guidelines.
Since we are making the changes on a branch, when we merge it we can squash all the commits in one, if needed. So, we can use this detailed commit format when we merge the branch, even if the intermediate commits do not have detailed messages.
Since we are making the changes on a branch, when we merge it we can squash all the commits in one
Yes, I am going to that. I am following your instructions from here at point 7 :)
I am following your instructions from here at point 7 :)
But still it is a good idea to test your changes locally, before committing and pushing them, if this is possible. There may be some cases when this is difficult though, so feel free to do what you think is best..
@d78ui98 I think that you should commit your changes at the end of each day, even if they are not yet consistent or well tested. This is useful so that we can see your progress.
Okay I will do that.
adding xenial
and bionic
box was a good idea. Vagrantfile ran smoothly in fact it was even faster than trusty
. I was thinking to adding all the 3 Vagrantfiles seperately in different folders. This would allow fexiblity to users to choose which box to run. Let me know if I should do that.
Vagrantfile is basically ruby code. You can try to change box dynamically instead maintaining different files - if at all needed to have different Ubuntu flavors.
I was thinking to adding all the 3 Vagrantfiles seperately in different folders. This would allow fexiblity to users to choose which box to run.
I think that you should use only the latest stable version. For Ubuntu this is bionic
. If everything works fine with bionic, forget about the rest.
Then, for creating a Debian version, I suggest that we use different git branches. This means that we will have a branch called bionic
with the corresponding Vagrantfiles, shell scripts, etc. and another branch called buster
(or stretch
) with the corresponding Debian version and scripts. Something similar to this repo: https://github.com/EasyGnuPG/ggpg-ds
Another solution could be to create different github repositories, like ltsp-bionic
and ltsp-buster
.
Vagrantfile is basically ruby code. You can try to change box dynamically instead maintaining different files - if at all needed to have different Ubuntu flavors.
This would be OK if the provisioning bash scripts were the same. But this may not be the case, especially when switching from ubuntu to debian. So it may be better to keep different versions of the Vagrantfile and bash scripts.
@dashohoxha @akash0x53 please suggest any other improvements that I should make.
@d78ui98 have you tested it? Does it work? If yes, we can merge it and do any improvements after that. One thing that is missing is that you have not installed ltsp-manager. But you can do it after merging this branch.
Yes I have tested it multiple times. It works great.
One thing that is missing is that you have not installed ltsp-manager. But you can do it after merging this branch.
Sure I will install ltsp-manager after its merged.
I merged it and moved it to the branch bionic
. This is the branch where you should work from now on.
I also created the branch buster
for the Debian version.
Installing LTSP on Ubuntu 18.04 using vagrant
fixes #5 #9