Version control, trac

[Nnidyu]

Hello,

Since FET is open source, I'd like to suggest using some kind of version control (maybe GIT?) and Trac. I think it would encourage users who know C++ and Qt to send patches and will simplify development for Liviu Lalescu.

[Liviu Lalescu]

Thank you for suggestion, but:

There are many reasons why I would like not to do that:

Firstly, I have never used such systems and they might prove disastrous for a beginner like me.

Then, I don't know how these systems work. I don't want to give rights to unknown persons, because they might make mistakes. The sources of FET are so fragile, because only one digit change in the generation algorithm might be fatal, but remain unnoticed for a very long time (forever?).

Also, I don't have time to learn these tools, I prefer to keep learning algorithms and new programming techniques.

Also, for the near future, I don't see very important changes to FET.

I just hope a good team will start a timetabling software based on FET and I will provide the allocation algorithm and help to integrate it. I just want to be a programmer on my part (algorithm of generation), not the leader of a complex program. I don't have organizational skills.

[Nnidyu]

Thanks for the answer.

I understand your point. However, I think it would help FET to become more user-friendly (yes, I think it's the biggest problem with FET). Some time ago I thought about creating the timetabling software but it's a lot of work and I don't really have much time for it.

BTW, have you seen this: http://gstpl.wikispaces.com/Timetabling+Software+Survey ?

And many thanks for hard work on FET.

[Liviu Lalescu]

Yes, I have seen that link, in fact I gave to the author the facts about FET.

My hope is that a good team will begin to develop an interface for the FET engine. I am willing to help to integrate the engine. But I cannot work on the interface or learn version control or to make FET friendlier. I have no time, experience or pleasure to work in this field. I want to learn new algorithms - in fact I am now reading an algorithms book. The algorithm is a very important part of FET and needs much work. Also, I need to take care of particular requests on FET.

[JanLo]

Hello,

it's 8 years later now. Have you reconsidered your decision not using any version control (and a public platform about that)? It may give your software new pace as it makes it easier for every interested developer to fork it, work on it and contribute the changes back to you.

It's not about giving up control or give someone else the right to make changes without your knowledge. In fact it makes it more transparent for you and everyone else to see what exactly has changed (and why). There is also a lot of easy to understand documentation and tutorials around describing the different VC systems. Also the various platforms make collaboration a lot easier.

With github for example you have a fork and pull-request system, where people can fork your code with one click, make changes in their own repository and contribute it back via a pull-request. This gives you an entry in the bug tracker where you can easily review all the changes and discuss it with the contributor. When you think, the change is ready to be merged into your official codebase, you can do this either locally via git with one click within the web frontend of github.

Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.

Thanks, Jan

[Volker Dirr]

Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.

even my pupils are clever enough to download and extract a file. but no one of my pupils is clever enough to use a version control system. so this is in fact a point against version control.

[Volker Dirr]

hmm... i fear you see "help developing" much too optimistic.
we even got request from guys that work at universities that teach only computer science and coding.
even a few of that guys ask us to compile the source since they don't understand how to compile.
if we now also force to learn a version control system, then we will even lose some developers. (in worst case even me, since i am also not good in that.)

seeing changes is very easy even without a version control system. you only need to use a comparison tool like kdiff, ...
very easy to use. very comfortable to see the changes.

[JanLo]

Another benefit is the public accessible code without the need to download and unpack. This, along with the integrated bugtracker may help your users to give you more exact hints about possible bugs. It may also encourage to contribute.

even my pupils are clever enough to download and extract a file. but no one of my pupils is clever enough to use a version control system. so this is in fact a point against version control.

My point here was, that you can search the code and point (link) to locations in it. I did not say, that a VCS should replace release tarballs. You can always have them, it's no problem with that. A VCS will just be a separate and more transparent way to distribute the code. You can even set release tags within the VCS to show the state that represents the code in a certain release. With this its easy to get a diff of the changes to spot regressions if one experienced one.

It would also not prevent someone to just download a tarball, make changes and send it (as a whole or as patch) back to upstream. In fact this is close to the way he linux kernel uses git as VCS: you send your commits to the VCS as set of patches to the subsystem maintainer who integrate them. You don't have to force anyone to use a VCS when you provide a public repository. You just give the opportunity to use it to people who are used to collaborate this way (software developers ). I mean, you can try it. It will not change your software in any way - but I think it gives you the possibility for easier collaboration - at least with some people.

I would also think that your pupils will be clever enough to use a VCS if someone shows them the benefit. And if the work on the software should give them an insight in today's software development techniques it would be a huge benefit to show them how collaboration in this field works today .

[Volker Dirr]

my pupils are not coders :-)
that are "normal" pupils. on a "middle" school. Max age is around 16 years. They don't learn coding at my school. "Just" Mathe, German, English, History, Sport, ... but not coding.
Even they never code, that guys are clever enough to download and extract.

So you see my point?!

I understand the advantages you tell me, but you forgot the disadvantages. You can do all that stuff only if ...:
- ... you know how to do it
- ... you do it (i saw several projects on github that didn't add extra information. so in fact some of your advantages are only true if you add that information. that mean more work.)

[Volker Dirr]

By the way:
You can see also some disadvantages on Github.
Just check the FET source on github. You can already find it there.
You can already see the disadvantages there:
a) it doesn't pull new developers. the number of contributors stays at 1. (so the guy who uploaded it).
b) the addition information doesn't help. i can't see in single time where it is a "useful" information.
c) it looks like uploading is pretty much work, since they do it very rarly (i know myself that you need to press only a single button or write a single line. but as you can see: real life is different: there are no up to date uploads. looks like that is too much work.)

maybe you can upload there always and tag additional information? (since i don't have time to do that work)

[JanLo]

my pupils are not coders :-)
that are "normal" pupils. on a "middle" school. Max age is around 16 years. They don't learn coding at my school. "Just" Mathe, German, English, History, Sport, ... but not coding.
Even they never code, that guys are clever enough to download and extract.

So you see my point?!

I totally got it - and even if I think that they do not learn to code is a sad fact with the school system - it's not an issue for a VCS. They can easily continue to download, extract and do whatever they want with the tarballs. (But besides that I would also say, that C++ is not a good language to learn how to code in the first place )

I understand the advantages you tell me, but you forgot the disadvantages. You can do all that stuff only if ...:
- ... you know how to do it
- ... you do it (i saw several projects on github that didn't add extra information. so in fact some of your advantages are only true if you add that information. that mean more work.)

You just give the opportunity to people who are regular software developers to use it. You don't have to use it for your own at all. You can just stick with your release tarballs, commit the state of the release at one big commit and put it somewhere public. With that your release process will be extended by just one "git commit" and one "git push" - and if you wont remember the commands you could easily use a UI for git. Nothing changes except that you're offering another way to access the code .

For me it would just be more convenient to have a official git source to clone from. If not I will just make a repository for my own purposes, import your latest release and maybe send patches of changes back. In fact the debian maintainers had already done this: https://anonscm.debian.org/cgit/collab-maint/fet.git

I have not looked at github at all because I looked at the official site for a source link. That's the problem with github repos that are created by people who miss official sources: they create them for their needs, get their work done and then orphan it. When you have a maintained "official" repo you can clone from it and everyone searching for it can easily see where it original came from. And as said, there are even a bunch of graphical interfaces for git if you cannot remember the commandline.

[Volker Dirr]

sorry, but i don't have time to upload and learn that. so what do you suggest who should do that work? will you always upload? i haven't got time to care about that.

[JanLo]

sorry, but i don't have time to upload and learn that. so what do you suggest who should do that work? will you always upload? i haven't got time to care about that.

It's no problem for me to do that but that will not solve the problem. My main point was, that you should refer to a official source on your website, because when I search on github, I get at least two repositories containing FET in some state in history. I'll never know whick is the right one.  You could even refer to the debian VCS of FET.  Just a source where people can easily base their work on and can be sure that this is the latest available version.

[Volker Dirr]

like i said: i haven't got time for that. i am around 10 years in this project now and in fact there wasn't more then around 10 lines of code contribution by other guys in all that years. So too much work to do that just for average 1 line of code per year.
but in fact Liviu is the guy in charge. He decides. I am not sure if he will do that work for such less benefit.
maybe it will be easier if you start sending patches. if we can see that there is someone coding good stuff, Liviu might rethink.

[Liviu Lalescu]

Thank you for your suggestion, Jan,

I am sorry, but I am still not prepared for this. You have good reasons, but I also have mine.

- I need to learn the system - there are possible critical mistakes;

- I prefer to keep the independence from other sites (I don't know if I can install GIT on my lalescu.ro);

- Sometimes I prefer to implement myself the suggestions, because other users are not that familiar with the FET code. If I have to take other programmers' code and analyze it, it may mean more work and very error prone.

- There are many possible improvements in the GUI part. Many users will come with suggestions and code. On one hand, I cannot implement all suggestions, on the other hand I need to check thoroughly the code, and this might take longer than actually me writing the code. So, best would be for some persons to start a new FET GUI and add the engine, and if this GUI proves good, to slowly make it an official alternative to the present GUI.

Also, please see KDiff3 - it can compare whole directories. It is really nice.