Hi everyone! Thanks for joining the meeting hello Let's start our meeting Our first topic is the status of the migration from GForge to GitLab the migration covers 4 sets of artifacts: 1) Code repositories, 2) Issues, 3) Web sites, 4) Releases the migration from SVN to Git works rather well as far as I understand KPTN, martinus__: no specific issue in the process, is that right? Hi everybody slauriere: we still miss some features like target version slauriere, there is one issue about back references to commit is git issues and indexation of commits in issues KPTN, I was writing a report to you and Xavier about this KPTN: what do you mean by target version ? bilbo-the-hobbit, FixVersion in JIRA, milestones in gitlab yes this is implemented, that's what I was writing great Now the remaining problem is reference to commits from issues ie, when an issue is mentioned in a commit message the gitlab issue is not updated with that back reference There is two way we can handle that (with dev power of course) martinus__: let me see in our own gitlab this is weird as we do a push of code after issues are opened in gitlab --> dangagliar (d9ac09b4@gateway/web/freenode/ip.217.172.9.180) has joined #ow2-tc bilbo-the-hobbit, already done that Bonjour! hi dangagliar! good to have you here! I apologise for being late martinus__: we are using protected branches and merge bilbo-the-hobbit, you took commit references from your forge, as it was already associated to issues KPTN, I agree this is weird martinus__: let me see new ones :) bilbo-the-hobbit, interesting ones are older ones ;) bilbo-the-hobbit, already took a look , you have the references in the issue description so it's handled I speak about gitlab.fusiondirectory.org martinus__, KPTN: what do you find weird? the fact that GitLab does not create automatically the back references from issues to commits? yes slauriere, yes, as the code push hapened AFTER the issues was registered ok, right That's a question we could submit to the GitLab community I guess KPTN, the changes for LEMONLDAP to # in commit messages where done at which time ? before or after the push ? Do we manage to have those back references in some cases? slauriere, we have those, for new commits martinus__: before slauriere, already done that I first pull code from SVN, then rewrite message commits, then push on new repo ok thanks martinus__ https://forum.gitlab.com/t/issues-repo-migration-link-issues-to-related-commits-after-issues-repo-import/10910/2 so it's only the initial push that raises issues if I understand correctly martinus__: did you look at the contributed code we made for the remdine -> gitlab conversion, lots of stuff have been done by the gitlab api bilbo-the-hobbit, you don't have that issue like I said, because redmine had commit<>issues references in redmine we don't have those references in JIRA since we have stopped Fisheye Maybe the JIRA api expose commit references once Fisheye is online for any given issue that could be a solution any help appreciated of course :) bilbo-the-hobbit, back references in your gitlab instance are added to the description body bilbo-the-hobbit, I mean for issues that you have imported bilbo-the-hobbit, but real gitlab commit reference are like comments it tells me that it has been handled the hard way, starting from Redmine api/database I can be wrong of course another way could be to parse ALL commits messages in the repo and alter every issue description , adding the commit hash link indeed, all commits from all branches Get back to me after the meeting if you have ideas please, I want to have a word about project members in gitlab I rewrote the code in ours script , so not any issue reporter is made a project member in gitlab instead , I take the roles membership from JIRA and them member of the gitlab GROUP to equivalent access level and -add- them That's all for me for gitlab ok I'll be busy after the meeting but we'll manage to be in touch so regarding the references to commits the conclusion is that we have to investigate further and to possibly consider parsing all commit messages slauriere, if we decide to dive into this , in the priority permits etc indeed, good question: do we have to dive into this? how important is the need to have references from issues to commits? is it a nice to have or a mandatory feature? I have to add that as we are working on gitlab migration, gitlab release a lot of new versions of the software, increasing the delta version with our instance. We run gitlab 9.2.2, this is 10+ currently updates that we can afford to apply until we have finished => can't martinus__: we are using 9.5.4 ok martinus__ martinus__, why can't we update while we work on the migration? slauriere, abvious : because the database and/or api may change how long the migration should be? I agree that we have to migrate and then update ok dangagliar, I don't know exactly, we have to look into the projects in gforge and jira and have a guess I think this could be a good starting point, to plan next steps What do we decide with the references from issues to commits? Is it a blocker issue, or can we live without those references for past commits? KPTN, ? slauriere, which other projects are in that use case ? In my opinion it shouldn't be a blocking point in GForge as far as I know, only ASM was using the issue tracker slauriere, I'm speaking about projects that are using JIRA for issues slauriere, and for which the repo is going to be moved in gitlab That's what we need to know this is not blocking martinus__: my question is why we don't move every repo to gitlab ? that was not the idea ? bilbo-the-hobbit, the decision is not clear to me please advise ;) martinus__, we have AuthzForce and SAT4J which use JIRA martinus__: having work xith gitlab for the past two month for migration and now daily, i see no point using something else :) authz uses gitlab already for sources martinus__: great forge, lots of nice fonctionalities and the ci / cd is rocking so much easy that jenkins bilbo-the-hobbit, the question is not about using something else, the question is do we need to keep older (older!) project in a SCM at OW2 martinus__: just migrate them bilbo-the-hobbit, that's your opinion anybody ? ok, not blocking for KPTN and dangagliar, thanks agree ? martinus__: we migrate even our archived porject into gitlab so martinus__ we need to validate with the AuthzForce and SAT4J teams that it's not blocking either, right? martinus__: yes my opinion i don't want to manage 2 instance one with old stuf and one with new stuff bilbo-the-hobbit, but we can just archive the repo as static tar.gz for very old projects "why we don't move every repo to gitlab?" - we are moving every repo aren't we err. ok :) time is flying conclusion of this item: we check with AuthzForce and SAT4J that the issue is not blocking and we proceed next item: project web sites Our proposal would be to use GitLab pages for that any objection? that would mean having a dedicated domain like ow2.io and project sites would live at e.g. joram.ow2.io bilbo-the-hobbit, are you using GitLab pages? slauriere: non but i'am in favor of it ok great dangagliar, do you use gitlab pages ? or did you anyone, it's an obvious option anyway I mean martinus__: i think all the fonctionalities of gitlab should be used there is no need to deploy and maintain other tools if gitlab have it I'm in favor to gitlab pages, but I know it means a lot of migration stuff for existing websites martinus__: no, at the moment, but we will use them martinus__: yes i understand that, but to be better sometime we have to move :) i kind of forced to migration to gitlab on our side :) I will take care about the spagoworld family so we decide to use GitLab pages, taking into account there will be important migration work ahead bilbo-the-hobbit, look, I never said that I didn't want to move, I just mentioned that it's a certain amount of work that someone(s) have to do slauriere, yes ok martinus__, thanks We covered 1) repositories, 2) issues, 3) web sites The last item to migrate is the file release management system which is the migration process on gitlab pages? put more simply: is it a manual work? dangagliar, TBD dangagliar, it starts at reading the docs ok, martinus__ , let's discuss it, in order to provide guilines to all project leaders ok ok, indeed dangagliar, martinus__ further investigation needed then, and maybe a dedicated meeting to define the process I will start to read the docs :-) slauriere, I agree great for the FRS, we have mentioned the SFTP solution , based on posix group from LDAP martinus__, this sounds good to me the project manager connects and got a list of projects folders he have permission to write i nthe folder owner by the project's group I propose to set some tasks on the tracker in order to speed up our activities should we have a dedicated project in Gitlab, as we had in Jira? We are using this approach also in STAMP project dangagliar: yes a dedicated projet in gitlab dangagliar: we have an infra group in the gitlab of fusiondirectory for exemple for those issues martinus__: and we use lots of templates for issues to qualify them great bilbo-the-hobbit bilbo-the-hobbit: this is very interesting dangagliar, right, good idea, let's create a dedicated project I have this approach in Jira, our corporate instance has been configured in a very detailed way to track activities and issues shall we have a tc project in the ow2 group? https://gitlab.ow2.org/ow2/ would that be ok with you all? --> JParpaillon_____ (~jean@176.164.62.228) has joined #ow2-tc dangagliar: https://gitlab.fusiondirectory.org/fusiondirectory/fd/tree/1.3-dev/.gitlab four our actual template so you got an idea this being said I don't think templates are required to achieve our work for TC slauriere: yes a project tc we just need to track down things martinus__, regarding the new FRS based on SFTP, do you have an estimate of the needed workload? I'm ok slauriere martinus__: template are usefull so people always fill the same information needed .. for me they are esential <-- JeanParpaillon has quit (Ping timeout: 260 seconds) we have 5 minutes left, bilbo-the-hobbit, yes I understand but active TC members can be counted of hands fingers ;) ok, we can start using the default template, and if we realise to store additional info, we can consider to set upo a template Next item: UForge bilbo-the-hobbit, thanks for the reference, very interesting --> JeanParpaillon (~jean@176.164.62.228) has joined #ow2-tc https://www.usharesoft.com/products slauriere: uforge for me is not useable we have a free license bilbo-the-hobbit, thanks for the feedback, why is that? slauriere, I have some items to mention about the FRS but we don't have time for it. I'll detail them on gitlab slauriere: slow, buggy, make my pc crawl <-- JParpaillon has quit (Ping timeout: 240 seconds) ok bilbo-the-hobbit slauriere: if its for application delivery we can use the docker integration of gitlab bilbo-the-hobbit, if it were working efficiently, would it be of interest? or would Docker delivery be enough? slauriere: we will surely do that to publish our demo live directly from gitlab in the future UForge brings the multi-cloud delivery is this multi-cloud aspect interesting to you? you can alter vm images content directly from the UI (packages, files...) slauriere: i don't think its usefull for ow2 , we need simple and straightforwad process with little work bilbo-the-hobbit, so the features provided by UForge are not meaningful to you, even if they were working efficiently? martinus__: i would never do that its a big no no for me, i don't want human interaction at this point, i want my pipeline to deliver trought continuous integration slauriere: yes bilbo-the-hobbit, yes they are not meaningful? I have to say I have no idea who are the customers of uforge, what are their use case slauriere: yes not meaningful, i think we need to give tools to make project work and keep it simple ok thanks very quickly: voting system: any recommendation of tools supporting votes for electing the board? at the moment I have no recommendation slauriere, I realise that question would be more easy to answer with a doc that specify OW2 ,needs ok dangagliar thanks martinus__: I agree indeed martinus__, we'll create an issue in our new issue tracker Google Summer of Code: OW2 will represent the projects, we'll let you know about the calendar etc. FOSDEM: who will be there? bilbo-the-hobbit I guess? slauriere: yes there is one that emerged from liquid democracy but don't remember the name right now, will post to the list thanks KPTN, do you plan to attend the next FOSDEM? slauriere: of course i will be at fosdem slauriere: yes I think ok cool last item: Market Readiness Levels we're trying to create a model for assessing the maturity of OSS projects, an evolution of OMM any input on this matter is welcome I have to run bye slauriere thank you all very much for attending the meeting! talk to you later! bye bye slauriere talk you sooon!