Volunteering Facilitator: Bernard Sfez / Tiki Specialist
Who
Who plans to attend? (please vote for preferred times below)
People Confirmed
People Interested
When
Sunday, March 22nd, 2020 at 13:00:00 UTC time (click to check time zone in your location)
The time is now:
Time in your timezone (when this page was last reloaded): Wednesday 17 July 2024 21:30:05 UTC
Votes
Votes
The time will be set by the participants vote:
Where
What
See Roundtable Meetings for a detailed description.
Topics
First hour, quick news
- Tiki 21 status
- Demo of the new plugin List Execute in action: clone item
- https://gitlab.com/tikiwiki/tiki/-/commit/ea6f50574b0dc8e19fc5a5dd979686a0c10d872f (main)
- https://gitlab.com/tikiwiki/tiki/-/commit/bec107dd655c236dc31abfc12c3a9bfddb2d4a13 (auto select fix)
- https://gitlab.com/tikiwiki/tiki/-/commit/43e10f9d51baae9a4174e254973dd4ad8ab2e987 (checkbox fix)
- Quickly review the evolution of bug reporting in the last years. Some charts and tables made by several criteria:
- Nice, but very slow, let's look at facets too!
- Bug tracker improvements
- We now have conditional Tracker Field Rules - might they help?
- Priority field is the wrong way up, a higher number means lower priority - also, incomplete ones show as
0 (top priority)
put your topic (max. 5-10 minutes) into the list above
Second hour, longer topics
- Git commit/merge request/fork improve/updated guidelines
After the Tiki 21 release experience and due to a certain numbers of discussions (devlist and gitlab) we need to adjust and improve our guidelines on Git and Tiki.
Also we switched from SVN to Git so we need to be sure all people are good with that and will be able to participate
Related discussions in the mailin list (https://tiki.org/tiki-view_forum.php?forumId=26)
Tiki-devel: Semi-automatic merging also Re: Tikiwiki-cvs/svn SF.net SVN: tikiwiki:75741 trunk
Fabio on 4/03/2020:
Well, I vote for each developer applying his fixes in each branch. This is one of tasks Git makes easy. But I can help you. I misbehave on that because I know my fixes would be magically ported from one branch to another.
Brendon on 10/03/2020:
Ok, so its a clear consensus that automated back ports of fixes into LTS is a bad idea.
So the question is. Do we abandon our automated porting? Do we continue to forward port, or do we back-port within development versions? Or a combination there of.
Tiki-devel: Create your fork
Fabio wrote on 4/03/2020:
Forks are nice. Using forks we can eat spaghetti, potatoes, olives and also, we can develop Tiki!
I know that should be straightforward creating branches in main repository,but that makes a little mess on subgit bridge and SourceForge branches folder.
So, if you don't mind creating branches in a fork, it would be awesome.
You don't even need a separate folder for your fork. Use the Tiki folder you already have.
Let's say I'm creating Tiki mustache. But cloned from main repository and the mustache will take some time to make it beautiful. I need a branch.
1) Create a fork (my fork is git at gitlab.com:fabiomontefuscolo/tiki.git)
2) Add your fork as a remote to your local repository
>> git remote add fabio git at gitlab.com:fabiomontefuscolo/tiki.git
3) Create the branch you need
>> git checkout -b cowboy-mustache
4) Work, make commits .. if your branch lasts for more than one day ... update it getting changes from origin (the main repository). Let's say I branched from master, I get updates from master.
if you already pushed cowboy-mustache in the past:
>> git fetch origin
>> git merge origin/master
OR
if your branch is just a local branch
>> git fetch origin
>> git rebase origin/master
5) Save it to your forked repo
>> git push -u fabio cowboy-mustache
6) Mustache is ready, send it to main repository
If you want to open a MergeRequest, do it in Gitlab pannel
OR
If you want to send it directly to main git repository
>> git checkout master
>> git merge cowboy-mustache
>> git push origin master
-
Tiki-devel: Minor releases
Fabio wrote on 4/03/2020:
Hi people!
I would like to understand about minor releases cycle. It is not clear to me when we release the minor releases, but surely, it is less frequent than I would like.
If there is no rule to create a minor release, why don't we make it weekly or bi-weekly, so we can have updated packages for download with all vendor_bundled installed?
Honestly, I don't like the approach of downloading Tiki in the server and building it there. On server I am not the admin, I have argue a lot with the administrator to install build tools to have an updated TikiWiki software.
Thank you!
-
Clarification needed about Tiki GIT usage
bsfez wrote on 5/03/2020:
- Light fixes, translation, doc and commit by VIP coder => merged to the repo directly
- More complex fixes or commit done by newbee or requiring approval before being merged => create a merge request, wait for approval
- For feature that require experimental branch => use a fork branch
Fabio:
I suggest MR authors poke someone in the community to review the changes, to avoid MR stuck forever. The reason is simple: each member in the community has knowledge in different parts in Tiki. I don't feel confident to review requests related to Tracker calculations for example. So, asking directly some would be better.
You might ask, how to search for the correct person? ... I also suggest reading logs of files you are changing to find out who is the author of past changes. These authors might be a good person to review it.
-
- ...
put your topic (max. 15 minutes) into the list above
Recording
Follow-Up
put your follow up action(s) when you're done into the list above
Chat log
Pages related to this one
One page links to Roundtable Meeting 2020 03
;){kind=link}
;){kind=link}