General > Developers
Slow and steady ... moving from Trac to Gitlab
polly:
Hey ...
just wanted to let you guys know that i'm done with "trac to gitlab" and "svn to git" migration.
There is already a cronJob running once a day at 8:30am CEST pulling all data over from trac and svn.
From now on, testing begins! :-)
Let me know if you found anything weird or missing tickets and notes/changelogs.
For most users i was able to map their trac usernames to gitlab users.
I tried to merge the users as much as i could. So if i found a user in trac which had the same name in the forum, but a different e-mail i went with the forum account.
If you are not sure if/which of your accounts is still there use the forgot password feature in Gitlab.
For now Gitlab is READ ONLY! ... this will be changed as soon as everybody is happy and comfy with GIT.
LinuxMCE Gitlab installation:
http://git.linuxmce.org
Gitlab Android App:
https://play.google.com/store/apps/details?id=com.bd.gitlab
Gitlab iPhone App:
https://itunes.apple.com/us/app/gitlab-control/id654747119?mt=8
Roadmap:
From now on, CronJob will update tickets and repos once a day. then we have at least 4 weeks of testing and playing. After that the devs decide when switch completely to git.
Let me know if you have any issues!
Thanks.
Cheers,
ochorocho
mkbrown69:
Sweeet! And thanks for your efforts!
At work, we switched from Git/Trac to Git/Gitlab, and it's sooo much more of a productive environment. We've got hooks from certain projects into Jenkins for building RPM's 5 minutes after a commit, and that's sweet from a packaging point of view. Jenkins really rocks as well! (BTW, there's a .deb builder plugin for Jenkins if that's of interest to you)
I have a small request of you and the core devs. Gitlab represents a real opportunity to enable more people to get involved in LinuxMCE development and testing. In the past, I didn't want to have any form of SVN access; I know enough to know I don't know enough about LMCE to event want any commit access (bull in a china shop syndrome). So, that limited me to filing tickets with diffs attached.
Gitlab changes all of that. The core devs can steward the main linuxmce project, and personal workspaces allow more novice folks like myself the opportunity to contribute through an isolated environment and merge requests. So, I would like to make the following request:
Could you folks create a wiki page with some example workflows that would enable folks like myself to contribute more, while minimizing the level of effort on the core devs to take advantage of what we do?
I'm thinking of example workflows like:
* simple bug fix for existing code
* significant bug fix for existing code or refactoring
* simple new feature (new code)
* significant new feature (majorly intrusive)
I think that giving us examples of how you want us to work would be good for us novices to learn, while making life easier for those already overcommitted core devs. Maybe even a quick page on how issues should be filed might be good for standardizing and leveraging Gitlab's capabilities...
Just thought I'd put this out there for your consideration.
Thanks again for your hard work on this! I'm sure it wasn't easy, but it will be worth it in the long run!
/Mike
polly:
Hey Mike,
thanks for writing this detailes message.
I agree, me as a semi skilled programmer likes the idea of fork/pull request.
So core devs review the code i wrote i give us a "well done" by accepting the merge request.
The website is a good place to put info about contributing to LMCE: http://www.linuxmce.org/contribute.html
Cheers,
ochorocho
polly:
No issues at all? ... can't be! ;-)
phenigma:
Haven't been testing it yet. Soon... You'll have 1000 tickets to act on when you get back ;)
J.
Navigation
[0] Message Index
[#] Next page
Go to full version