Support isn't dropped. It is just called long term support now. This doesn't change anything with OMV 3. It still takes time and we are working on it.
thanks for update
Support isn't dropped. It is just called long term support now. This doesn't change anything with OMV 3. It still takes time and we are working on it.
thanks for update
And just so everyone knows, it is mostly just me slowing the process down. Volker and HK have lots of their work done.
implying Volker is lazy
Nobody besides you has said that. I said that it needs too much effort to get something into the project. And nobody like useless effort for nothing.
I don't mind if you should use svn or git - both working great. But the main problem is the hoster, really nobody is using SF these days for the obvious reasons - it is a plain file hoster filled with an outdated ui and no features.
The "whole" OSS world is at github where you can easily push some fixes to some project. It is not due git it is that great, it is because of the hub. At gh you can create an fix and push him to the upstream project under a minute without knowing anything. This is much more attractive to possible contributors even if they are not that skilled.
I don't say that you have to close the project if you don't move gh (..) I just propose an easy improvement. There is no benefit of using an platform where nobody is active.
devs are lazy.
So stupid. Anyone doing work on this project does not deserve to see a comment like this. How else can this be construed other than in the negative?
BTW- I am not debating the merits of Github. Just saying you have bad manners.
So stupid. Anyone doing work on this project does not deserve to see a comment like this. How else can this be construed other than in the negative?
BTW- I am not debating the merits of Github. Just saying you have bad manners.
Calm down, he has no ill intent.
He's just making a broad statement that developers are lazy, and that is for the most part true. I'm lazy and most developers are most likely lazy (doing as much work as possible with as little effort as possible). What he really mean is that most developers are too lazy to even want to get on Sourceforge or create patches. The barrier to entry is to high for it to be worth it if you compare it to Github and pull requests. Combine that with an CLA you have to sign to even contribute and you've scared away most developers.
@HK-47 Volker is the antithesis to lazy. The bug tracker seems to be his preferred method for any contributions. No one ever thinks that he wants control over his code. If you are injecting code that is of any length you might miss something that could cause problems. The code in the plugins can bring down the web gui but imagine looking through thousands of commits by other people for problems in the core. With the amount of work he does I am saying that people should respect him. I never liked the CLA because of anonymity.
As you hopefully have seen I am playing with github. I tried to import the SVN but the UI import fails, so I have to do it manually. Sadly svn2git also fails without knowing the exact reason. So at it seems so far the branches are not imported as I want to see it. I try some other solutions the next days.
Due the fact that I still can use my favorite SVN client with github there is nothing against github anymore.
Here is how I (with help from HK ) import svn into github and then update it hourly with a cron job:
apt-get install git-svn
# initial import to local repo
git svn clone svn://svn.code.sf.net/p/openmediavault/code/
# create github repo
# add to repo
git add *
git status
git commit -m "add readme"
git remote add origin https://github.com/ryecoaaron/openmediavault-svn-mirror.git
git push -u origin master
Alles anzeigen
We have migrated some svn repositories to git recently and it is not that strightforward if you want to get the branches right.
(Git uses branch tags, svn uses folder for branches, tags and trunk).
The current structure in github just does not look right. (Folder branches and trunk).
subgit will come to the rescue.
Anyone interested in me giving it a try?
The SVN repository has been migrated to GIT, see http://scm.openmediavault.org.
Sehr schön.
Are you going to add tags as well to enable downloading of releases?
The current structure in github just does not look right. (Folder branches and trunk).
It looks right to me especially when you are just mirroring all the versions on github. I wasn't trying to put svn branches into git branches. I just wanted a quick fast mirror to view code.
Sehr schön.
Are you going to add tags as well to enable downloading of releases?
I don't know it at the moment. I think the Debian repositories should be enough.
I agree. There is no real reason to download a source release of a non-binary package from github. The deb has the source in it and the repo delivers it without extra work. I guess the tag would be easy but so would looking at the commit messages. OMV isn't really the type of app you want an old release from source either.
The SVN repository has been migrated to GIT, see http://scm.openmediavault.org.
Is ok to submit bugs now at github issues ?
Hmm, would be the best, so fixes can be directly linked and we have one service less that can make problems, e.g. connection problems because of down times of the hoster and we have https.
On the other side it is much better to be independent from a service, so a switch of the SCM service like now would not mean the loss of the bugtracker information. And as far as i see the issue tracker from GitHub is not really great, Mantis is much much better.
On the other side it is much better to be independent from a service, so a switch of the SCM service like now would not mean the loss of the bugtracker information. And as far as i see the issue tracker from GitHub is not really great, Mantis is much much better.
Here's some things to consider.
Setting up an .gitignore file.
I think this is too much magic.
Setting up guidelines for issues (to make it a bit more like Mantis), and possibly set up your own labels and milestones
Mantis will be the bugtracker because it is much better than the GitHub solution.
Filter out/remove the deb/sources directory. It's 95 MB in size. Surely there must be some better solution than storing external sources in the repo?
Consider splitting all sub-projects in deb/ into their own repository. The download size is quite large (though it was that with SVN too). I have to clone with the depth argument currently to make it feasible.
No, the current repository structure is ideal for my requirements. My private repo contains much more dirs beside deb/. Everything else makes it more complicated to sync my private with the public repo.
Hello,
OMV3 is currently using php 5.6, but can we upgrade it to php 7?
Any issue?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!