Recent

Author Topic: New topic to Mantis  (Read 663 times)

Andrey Sobol

  • New Member
  • *
  • Posts: 48
New topic to Mantis
« on: January 18, 2021, 02:46:21 pm »
Hello,

I suggest for Lazarus and fpc in the Mantis project rubricator  to create a branch "Documentaion Updates" or so. Every time I wonder where to put the files with documentation. This is a special kind of patch that does not apply to development.

asdf1337

  • Jr. Member
  • **
  • Posts: 56
Re: New topic to Mantis
« Reply #1 on: January 18, 2021, 03:10:37 pm »
better put the docu to github so one can directly edit it and send a merge request :D
could also be rolled out directly from a CI process ;)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9090
  • FPC developer.
Re: New topic to Mantis
« Reply #2 on: January 18, 2021, 03:31:39 pm »
We are currently using mantis and SVN. Please keep it on topic.

As for Andrey's question, does it really help to split everything out in umpteen categories? fpc category documentation or lazarus category documentation should be ok?

p.s. Github is a different (US) jurisdiction, so simply not acceptable.
« Last Edit: January 18, 2021, 03:34:53 pm by marcov »

Andrey Sobol

  • New Member
  • *
  • Posts: 48
Re: New topic to Mantis
« Reply #3 on: January 18, 2021, 04:22:52 pm »

As for Andrey's question, does it really help to split everything out in umpteen categories? fpc category documentation or lazarus category documentation should be ok?
I don`t know how is organezed that process. If that do different mantainers then should be the different topics, I think.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6906
  • Debugger - SynEdit - and more
    • wiki
Re: New topic to Mantis
« Reply #4 on: January 18, 2021, 04:56:16 pm »
Couple of things....

I am doubtful it would help much.
On the Lazarus Project on mantis we have 2 sub-projects: Patches and Packages.
We also have those 2 categories, inside the main Lazarus project.

Looking at reports with patches => some are in the sub project / some in the category / some are sorted according to what they patch: lcl, ide, ....
So basically the mantis sub-projects do nothing.

I personally (as developer) always just look at the main project(s), as it shows everything. I never used the sub project as filter for anything.
I do not know if other developers do. But I also have not seen any activity by any developer to move issues into sub projects.

The only moving between projects is, if Fpc issues are in Lazarus or vice versa.



So the only reason to create either one/two new top level, or one/two new sub-projects would be if those who maintain docs / apply patches, would ask for it.
But even then: If it was a sub-project most other devels would expect to see doc related issues, and would not notice if it was not in the sub project => wrongly filed issues would not be moved => meaning those looking for doc-patches still have to scan the main project, because issues get placed there too.



Further more, at least for Lazarus - I do not know if FPC has any internal rules that say otherwise - any developer could [1] apply a doc patch, if they though it fit to do so.
Mind you, talking about the English main doc. Translations are handled per language by people who know the language (or sometimes a native speaker in cooperation with a developer)

[1] "could" => i.e. has the technical ability and the right to act on it.
This is the same for docs, as for any other part. If I saw a patch for the cocoa widgetset, I "could" apply it. However very unlikely that I will. I am vastly unfamiliar with cocoa, and I know that others in the team have good knowledge on the topic.
 
« Last Edit: January 18, 2021, 05:57:10 pm by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6906
  • Debugger - SynEdit - and more
    • wiki
Re: New topic to Mantis
« Reply #5 on: January 18, 2021, 05:04:46 pm »
Other than what I wrote in my previous post, I am well aware that many patches are left unattended for way longer than they should.
That applies to docs in the same way as it does to other parts of the project.

And yes, this is a tremendously bad thing. Any patch left unattended may be a future contributor lost. Not to mention an easy to fix issue that is not fixed.
Just to say, not every patch can be applied right away. There may be questions or issue that need clarification. But every patch should get a response...

Yet, unfortunately I do not have the answer on how to solve this. Neither for docs, nor for other patches.

So, ideas are welcome. Even if I might be sceptical of some of them.
« Last Edit: January 18, 2021, 05:12:10 pm by Martin_fr »

Andrey Sobol

  • New Member
  • *
  • Posts: 48
Re: New topic to Mantis
« Reply #6 on: January 18, 2021, 05:20:09 pm »
I don`t know what to say yet. I see  a huge  bureaucratic wall.  Only conversations, and then patches hang and are not applied. And over time it gets boring.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6906
  • Debugger - SynEdit - and more
    • wiki
Re: New topic to Mantis
« Reply #7 on: January 18, 2021, 06:06:15 pm »
I don`t know what to say yet. I see  a huge  bureaucratic wall.  Only conversations, and then patches hang and are not applied. And over time it gets boring.
Fully agreed, except that I think adding more sub-projects means adding more bureaucracy.

The problem is we are not a company, with employees working 9 to 5. So we can't just say, Fridays are patch days, everyone works on patches...

Reality is, each developer contributes whatever time he can (and likes) to afford. That is out of everyone's spare time. In this time each team member is free to choose what they want to work on.
- Of course there are some things that are off limits, like rewriting the entire IDE into c code.
- And of course there are communication, and helping each other.
- And usually also a willingness to prioritize time, if someone contributes... except this one is a bit more complex
...

So in my own example, I became a contributor because I wanted to enhance the Editor. And later I got interested in the debugger too. Those are the things I chose to work on. (Somehow - and to the day I am not sure how it happened - I also ended up with building the Windows releases)
So if I spent time, I prioritize those.
If I see a patch for those 2 topics I try to make time, but
- sometimes I am busy and that takes some weeks before I can do much about it.
- sometimes I miss something
- sometimes there is no straight forward answer, it may not be possible to apply it as it is. Or I do not have the means to test it right away (eg arm debugging / I have no setup to test those)

But then lots of patches are outside those 2 areas. Ideally I could give them the same priority. But that does not always happen.
And sometimes those patches relate to code, that I am not very familiar with, so I am hoping someone else will take it.
Some patches may apply to something were every team member thinks: someone else => problem.

Anyway this describes the general dynamics. The current situation.
This is the starting point.
The question is => how to solve this?


As for the OT => documentation.

I can only speak about the Lazarus part, and even there within limits.
From the svn commit log, it looks like quite a few team members have committed changes to docs, but not sure who does do which extend.

The practical thing is:
- To find open issues (i.e. pending patches on mantis) => that is something you could do (assuming there are pending patches, but without that, a new sub-project would not be needed neither).
- Validate them. Are they still applicable. Older issue may have been solved in a different way.
- Then try to get in contact with a team member and find out if it was overlooked, or why it was not picked up. That is a bit more work. Since to start with there is no rule by which to determine who that team member would be.

Anyway, if you have one (or a list of) issue(s) to enquire about, the best place is to go to the mail list. Not all team members read the forum on a regular base.
Post a mail with a subject like "Who knows about LCL TFooBar help?". Give it a bump (repost) after 4 to 5 days, if it did not get a reply the first time).

I can not guarantee how far that will get you. But it should have reasonable chances to get you some response.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3977
  • I like bugs.
Re: New topic to Mantis
« Reply #8 on: January 19, 2021, 01:28:30 pm »
Hello

It seems I have applied a big portion of documentation patches, and of other patches, too.
It is not a collective decision. I just hated to see patches being ignored. Applying or otherwise acknowledging a patch is essential in a collaborative project.

I suggest for Lazarus and fpc in the Mantis project rubricator  to create a branch "Documentaion Updates" or so. Every time I wonder where to put the files with documentation. This is a special kind of patch that does not apply to development.
In my workflow it would not help. My bug tracker view typically shows all sub-projects under Lazarus project. I check them all regardless of category. A good summary header line is important then.


I don`t know what to say yet. I see  a huge  bureaucratic wall.  Only conversations, and then patches hang and are not applied. And over time it gets boring.
I remember most documentation patches are applied without questions.
Code patches on the other hand must be tested and their functionality understood. Sometimes people disagree and there is discussion.
Which patches hang and are not applied? If it happens for weeks or months, please write a comment in the report to raise it in the history list.
Few days delay is normal in a volunteer project. I may not look at bug tracker for few days for various reasons.
Lately I was profiling / debugging / optimizing Lazarus IDE and did not mix patches there.
Now I have other tasks including shoveling snow. I guess you have similar activities in Nizhny Novgorod. :)
I see you made a documentation patch 2 days ago. I will look at it later today. A 2 days delay is OK and normal. I have seen patches waiting much longer in some other big FOSS SW projects.

Currently I can dedicate time for Lazarus project. What if something else comes up, or if I get bored with the project? Who will apply documentation patches then?
I don't know. Yes, it should be organized better.
Some developers refuse to apply patches that they don't fully understand. The problem is that this project has code that no core-developer knows well. A patch for those areas would be then ignored for eternity. Not good.
I sometimes apply patches after a brief check, without understanding all details. Sometimes it backfires and creates a regression. However a revision control allows to revert such a commit easily. No big problem. After all a vast majority of patches are good.


better put the docu to github so one can directly edit it and send a merge request :D
could also be rolled out directly from a CI process ;)
Github would not improve the process anyhow. Accepting a merge request also requires checking the validity of the changes.
The technical task of applying a patch is not a problem with our current tools.
Actually our process is very flexible now. There are many Git mirrors of FPC and Lazarus code. You can already develop using Git. Then just create a patch with "git format-patch ..." and upload it to bug tracker.
I personally have a Git repo here and commit through git-svn link. I can apply Git-formatted patches using "patch -p1 ..." or "git apply ...". Both work equally well.
I don't understand all the hype around Github. I feel uncomfortable using it, maybe because I am not used to it. One must fight with a hash ID of any new computer in use. I don't see how it could improve our development process anyhow.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

 

TinyPortal © 2005-2018