Re: [Development] Buddy group to help new contributors

[Thiago Macieira]

On Friday, 5 January 2024 12:28:04 -03 Christian Tismer-Sperling wrote:
> If the PySide group allows it, I'd be happy to port some perl
> scripts to python 

Sorry, why is Python better than Perl?

Eddy's argument is that he doesn't want to maintain Perl, but if others are, 
he doesn't have to. The question of maintenance is simply of maintenance.

The question in this thread is that of barrier of entry to developers with 
bare-bones environments. Hence my question: why would Python be better than 
Perl? Last I checked, it doesn't come with Windows either. Maybe some VS 
environments have it, but I wouldn't know.

The only scripting language we're guaranteed our users will have is CMake. Not 
even shell scripting falls into that category, because, as we've discussed the 
standard Git configuration does not put sh.exe in PATH (except for scripts that 
Git itself runs, which happens to include the Gerrit Change-Id one).

So if there are any tools that are considered "should provide"[1] to 
beginners, please port them to CMake.

[1] Gradation: "must provide", "should provide", "would be nice to provide"
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Thiago Macieira]

On Friday, 5 January 2024 12:28:04 -03 Christian Tismer-Sperling wrote:
> > If someone wants to take over and write in CMake or in C++, be my guest.
> > That's what Alexey did for the syncqt.pl script that predated even me. As
> > far as I know, that removed the dependency on Perl to compile Qt or to
> > contribute. What's left that you're seeing?
> 
> If the PySide group allows it, I'd be happy to port some perl
> scripts to python 

But what scripts need porting?

I don't see anything that is required to build Qt or contribute to the 
Project.

There are some helper but entirely optional scripts that were written in Perl, 
others in Python; some shell scripts in Zsh or requiring Bash specifically 
instead of being Bourne Shell-compatible. Because none are required, I don't 
see them as a showstopper or even a barrier to entry. Maybe an annoyance.

I have no problem with rewrites, so long as the offers to rewrite include an 
offer to maintain said scripts for a couple of years. That means I'd be wary of 
accepting an offer from someone who isn't an established Qt contributor... but 
then again, those scripts are entirely optional so their falling into bitrot 
is not a problem either.

So if anyone wants to port anything, get busy.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Christian Tismer-Sperling]

On 05.01.24 12:15, Thiago Macieira wrote:

On Friday, 5 January 2024 06:00:12 -03 Elias Steurer via Development wrote:

but let's go back to the discussion about why we need perl in the first
place and why wikis are bad 


Because we need a more powerful scripting language than shell or batch files
for many things. Many of the scripts in question were started by me and I use
Perl. I will not write in another language. Some others are so old that they
predate Python's very existence.

If someone wants to take over and write in CMake or in C++, be my guest.
That's what Alexey did for the syncqt.pl script that predated even me. As far
as I know, that removed the dependency on Perl to compile Qt or to contribute.
What's left that you're seeing?



If the PySide group allows it, I'd be happy to port some perl
scripts to python 

--
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://www.qt.io/qt-for-python
14482 Potsdam: GPG key -> 0xE7301150FB7BEE0E
phone +49 176 624 8

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Thiago Macieira]

On Friday, 5 January 2024 06:00:12 -03 Elias Steurer via Development wrote:
> but let's go back to the discussion about why we need perl in the first
> place and why wikis are bad 

Because we need a more powerful scripting language than shell or batch files 
for many things. Many of the scripts in question were started by me and I use 
Perl. I will not write in another language. Some others are so old that they 
predate Python's very existence.

If someone wants to take over and write in CMake or in C++, be my guest. 
That's what Alexey did for the syncqt.pl script that predated even me. As far 
as I know, that removed the dependency on Perl to compile Qt or to contribute. 
What's left that you're seeing?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Edward Welbourne via Development]

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
 Would it make a huge difference if we didn’t require perl (and IIRC
 we only need it for the init-repository script)?

On Thu, Jan 04, 2024 at 11:35:45AM +, Edward Welbourne via Development 
wrote:
>> Our post-commit hook also invokes sanitize-commit, which is a perl
>> script.
>>
>> Of course, it would not be beyond the wit of developers to rewrite
>> both into python; [...]

Oswald Buddenhagen (4 January 2024 15:15) wrote:
> this whole "get rid of perl for the sake of windows users" is a
> monumental red herring. because ...

Just to be clear here, while maybe Volker's reason for suggesting we
ditch perl might have been about windows users, *my* reason for wanting
to ditch perl is that I do not enjoy maintaining perl scripts.

Eddy.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Elias Steurer via Development]

Hi Konrad,

That would be indeed easier. The wiki explicitly states to use 
:


>/A Perl version which does not need a registration and also provides a 
zip file instead an installer is StrawberryPerl 
. /


but let's go back to the discussion about why we need perl in the first 
place and why wikis are bad 


Cheers ,

Eli

On 1/5/2024 9:42 AM, Konrad Rosenbaum wrote:

Hi,

On 05/01/2024 08:21, Elias Steurer via Development wrote:


> git for windows comes with perl

Is this new? Because my installation does not have it. I just 
checked, and the folder my env path points to only contains git.exe, 
git-gui.exe, and no Perl.



This is not new - it has (to my knowledge) always been there.

If you check the Git installation folder you'll find a .../usr 
directory and a .../usr/bin inside - that one contains Perl as well as 
hundreds of other Unix utilities. If you add this to your PATH 
variable you will have access to all of them.


Git on Windows replicates a bit of the Unix hierarchy in its 
installation folder. But it only exposes a small subset to the Windows 
command line through the .../bin or .../cmd folders.




    Konrad

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Konrad Rosenbaum]

Hi,

On 05/01/2024 08:21, Elias Steurer via Development wrote:


> git for windows comes with perl

Is this new? Because my installation does not have it. I just checked, 
and the folder my env path points to only contains git.exe, 
git-gui.exe, and no Perl.



This is not new - it has (to my knowledge) always been there.

If you check the Git installation folder you'll find a .../usr directory 
and a .../usr/bin inside - that one contains Perl as well as hundreds of 
other Unix utilities. If you add this to your PATH variable you will 
have access to all of them.


Git on Windows replicates a bit of the Unix hierarchy in its 
installation folder. But it only exposes a small subset to the Windows 
command line through the .../bin or .../cmd folders.




    Konrad



OpenPGP_0xBE96A6EE776FE5D0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Elias Steurer via Development]

> git for windows comes with perl

Is this new? Because my installation does not have it. I just checked, 
and the folder my env path points to only contains git.exe, git-gui.exe, 
and no Perl. I don't share your positive experience with Perl on 
Windows; see my earlier posts in this thread for details. Ideally, we 
would not replace the Perl script with a Python script, but rather 
remove the script entirely by moving to another code platform that does 
not need these hooks to make contributing easy.


For all other readers, I can recommend the lengthy discussion from the 
great people at Blender who had to deal with the discontinuation of 
Phabricator:


 * 
https://devtalk.blender.org/t/developer-blender-org-call-for-comments-and-participation/23451/8
 * 
https://devtalk.blender.org/t/developer-blender-org-call-for-comments-and-participation/23451/34
 * https://code.blender.org/2022/07/gitea-diaries-part-1/

Cheers ,

Eli

On 1/4/2024 3:15 PM, Oswald Buddenhagen via Development wrote:
On Thu, Jan 04, 2024 at 11:35:45AM +, Edward Welbourne via 
Development wrote:

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):

Would it make a huge difference if we didn’t require perl (and IIRC
we only need it for the init-repository script)?


Our post-commit hook also invokes sanitize-commit, which is a perl
script.

Of course, it would not be beyond the wit of developers to rewrite both
into python; [...]

this whole "get rid of perl for the sake of windows users" is a 
monumental red herring. because literally everyone already has perl 
with all required modules installed the moment they have cloned qt the 
way we instruct them to: git for windows comes with perl, because 
significant parts of git are written in perl.
putting ...\Git\usr\bin into the shell's PATH is not the recommended 
installation mode of GfW, but having instructions to do so in a qt 
build environment seems rather reasonable to me.
and any git-something in PATH that gets run as `git something` (yes, 
this just works) has perl in its PATH, which makes launching perl 
scripts from qt5/qtrepotools//bin a breeze.-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Oswald Buddenhagen via Development]

On Thu, Jan 04, 2024 at 11:35:45AM +, Edward Welbourne via Development 
wrote:

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):

Would it make a huge difference if we didn’t require perl (and IIRC
we only need it for the init-repository script)?


Our post-commit hook also invokes sanitize-commit, which is a perl
script.

Of course, it would not be beyond the wit of developers to rewrite both
into python; [...]

this whole "get rid of perl for the sake of windows users" is a 
monumental red herring. because literally everyone already has perl with 
all required modules installed the moment they have cloned qt the way we 
instruct them to: git for windows comes with perl, because significant 
parts of git are written in perl.
putting ...\Git\usr\bin into the shell's PATH is not the recommended 
installation mode of GfW, but having instructions to do so in a qt build 
environment seems rather reasonable to me.
and any git-something in PATH that gets run as `git something` (yes, 
this just works) has perl in its PATH, which makes launching perl 
scripts from qt5/qtrepotools//bin a breeze. 


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Philippe]

> This is a common problem with wikis.

Lightning Talk: Wikis Are Bad - Roger Orr - ACCU 2023
https://youtu.be/WKpB4gUS9fM?si=XHb1nBMWyZOJgjJG

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Edward Welbourne via Development]

Volker Hilsheimer (8 December 2023 23:55) wrote (inter alia):
>>> Would it make a huge difference if we didn’t require perl (and IIRC
>>> we only need it for the init-repository script)?

Our post-commit hook also invokes sanitize-commit, which is a perl
script.

Of course, it would not be beyond the wit of developers to rewrite both
into python; and doing so might well be an opportunity to study each
closely and think about what we really want from these scripts and how
to do it better.  But we'd have to set aside some suitable developer's
time to do all of that.

Elias Steurer (9 December 2023 15:21) wrote (among diverse good points):
>> In the current state the wiki is a mix of outdated and redundant
>> information.

This is a common problem with wikis.
(See also Mike's comment, below, about "written by software engineers".)

It is easy to write a page that says things that are true at the time of
writing.  It takes some extra effort to actually make that page
discoverable - link it from the right other places, add it to the right
categories, make sure it'll match search terms those who need the
information are going to actually ask about.  As ever with writing, it's
important also to think about what you're so used to taking for granted
that you might not realise the reader needs help with; and to link
relevant parts of the page to where the reader can find more material.

And that's just creating a good page.  Then there's the era of bit-rot:
eventually the page shall be out of date, but how can the reader whose
search has taken them to it discover that ?  I fear the Qt wiki has more
dead pages (that don't know they're dead) than usable live ones.

A wiki lives or dies like a garden, by having enough gardeners giving it
enough of their time to keep it vibrant.

Mike Trahearn (10 December 2023 00:11) wrote (inter alia):
> The entry learning curve is definitely very hard and tricky to set up
> and the wiki looks like it was written by software engineers (that's
> not a good thing). That would be my first point of change.

I distinctly remember, eight and a bit years back, that there was a lot
to sort out and it wasn't easy to find all the details I needed in the
jumble of out-dated pages - and that was with an office-mate who already
knew the ropes to help me out when I hit problems.

> It took me an entire week to get one commit over the line which in
> comparison to what I'm used to is unacceptably slow.

I managed to fix my first bug within my first week - and my boss was
astonished; so yes, I think everyone in the project knows the overhead
is a significant issue.  The problem is devising a process that deals
with all the complexities of this huge [*] project in good ways that we
can make work efficiently for regular high-throughput contributors while
also being learnable for beginners.  That's a tricky problem, so don't
expect an easy answer any time soon; but, yes, we do need to listen to
feedback, particularly from newcomers.

[*] Qt is huge in several ways: the amount built on it, the number of
folk involved in it, the diversity of ways it's used, the range of
platforms on which it works and, of course, the vast amount of code.

One thing I do with new recruits is encourage them to make a note of any
problems they hit, so that we can come back later to sort them out.
There are surely other ways to get feedback from newcomers.
If we don't know about a problem, it's hard to fix,

Eddy.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Mike Trahearn via Development]

Pedro had already reached out to me on my experience with this for myself and I 
gave some helpful feedback at that time. Many folk have since here echoed those 
points.

Reading the comments thus made, I would council those responsible for listening 
to the feedback to do so without comment until a broad picture of the issues 
and inertial dampers for newcomers can be fully appreciated.

There may be some easy wins and there may be some hard lessons to learn. Let's 
don't be afraid or resistant of those. They could just turn into the big wins 
in the end.

Newcomers do come with new and sometimes challenging ideas. And sometimes they 
are not so experienced. It takes discernment to respond appropriately.

Be nice and listen first. This is no time for closed minds and being 
patronising. This just pushes the good minds Qt really needs away.

These guys' suggestions may not match the well-established mediocratic 
heavyweight process that Qt contribution is, but that just might mean they 
bring a fresh perspective which might be worth looking at.

For me at least I agree with a lot of what has been said so far and as someone 
experienced in code review processes in very large-scale projects, I do find 
the Qt approach helpful in that you get to engage with exactly the right people 
during the review and that helps you gain a lot of insight and also get to know 
the experts a little more - I think that's one of the biggest benefits.

The entry learning curve is definitely very hard and tricky to set up and the 
wiki looks like it was written by software engineers (that's not a good thing). 
That would be my first point of change.

Once it works though you can see many of the benefits of the git hooks and the 
checks therein.

It took me an entire week to get one commit over the line which in comparison 
to what I'm used to is unacceptably slow.

In summary, there's a lot to like and a lot to learn and a lot to change. And 
listen first, don't bite.
Just looking out for the little guy!

Mike
Confidentiality Notice: This message (including attachments) is a private 
communication solely for use of the intended recipient(s). If you are not the 
intended recipient(s) or believe you received this message in error, notify the 
sender immediately and then delete this message. Any other use, retention, 
dissemination or copying is prohibited and may be a violation of law, including 
the Electronic Communication Privacy Act of 1986.   
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Buddy group to help new contributors

[Ilya Fedin]

On Fri, 8 Dec 2023 15:33:04 +0100
Elias Steurer via Development  wrote:

> Hi Volker,
> 
> Thanks for the update on the Qt Contributors Summit. It's great to
> hear about the initiatives to make the contribution process smoother, 
> especially for newcomers.
> 
> However, while setting up a Gerrit group for hand-holding new 
> contributors is a step in the right direction, I believe we might be 
> missing a crucial point. The core issue isn't just about guiding new 
> contributors through the existing process; it's about the inherent 
> complexity and user-unfriendliness of the current workflow.
> 
>  From installing a plethora of tools to dealing with the confusing
> repo cloning process, Perl dependencies and Perl path issues 
> ,
> the barriers to entry are high. Then, there's the challenge of 
> navigating the Gerrit setup, which is far from straightforward. The 
> documentation is inconsistent and sometimes contradictory, adding to
> the confusion. And that's before even getting into the complexities
> of submitting patches and managing code reviews. If you want I can
> send you my personal notes, that I have written down recently while
> setting up Qt locally for the first time in years. Most of it is
> about my frustration why a solved problem, like contributing to an
> open source project, is so unnecessary complicated.
> 
> In essence, the current workflow is daunting, even with a support
> group. I suggest we consider moving towards a more streamlined and
> "sane" workflow. Simplifying the entire contribution process from the
> ground up will make Qt more accessible to everyone. Once a more
> intuitive and welcoming workflow is establish, guiding new
> contributors will be much more effective. *After all, the best
> hand-holding is the one you don't need because the path is clear and
> easy to follow. *
> 
> It might be worth considering a migration to GitLab, which has been a 
> successful move for other open-source projects like KDE and Arch.
> Given that Qt already uses an internal GitLab instance, this could be
> a good platform for future collaboration. Alternatively, adopting
> Gitea, as used by the Blender Foundation, could also be a viable
> option if Gitlab licensing is a no-go.
> 
> I strongly believe the focus should be on overhauling the workflow 
> first. Everything else, including smoother onboarding of new 
> contributors, will naturally follow.
> 
> There was also an discussion about this recently on Reddit. 
> 
> 
> Best,
> 
> Eli
> 
> On 12/5/2023 9:57 AM, Volker Hilsheimer via Development wrote:
> > At the Qt Contributors Summit in Berlin last week, we discussed
> > various ideas around improving the contribution experience, esp for
> > new people.
> >
> > One action that came out of that was setting up a gerrit group of
> > people that are able and willing to hand-hold new contributors
> > through the process. This includes setting up your local
> > development environment, gerrit configuration and workflow, and
> > finding out what to work on from e.g. Jira. The basic idea is that
> > we establish a (gerrit, probably) group with buddies; we can
> > already identify “first gerrit reviews" for a new user, and then we
> > can proactively reach out with a welcome message, and add the group
> > of buddies as a reviewer.
> >
> > A few people raised their hand at the event, but I don’t think
> > anyone took down the names, and I was busy juggling microphones.
> > And either way, this is of course open to anyone! So please reply
> > to this, either to all or privately to me, if you want to be part
> > of that group.
> >
> > Cheers,
> > Volker
> >  

I believe the bug reporting rules make things even more harder. I have
a lot of crash traces received via breakpad I can't report upstream as
they crash deep inside Qt and I have no idea how to make an example for
that. I also have a lot of end user reports I can't reproduce myself
(maybe hardware-specific, idk) and therefore make a minimal
reproducible example. Those users don't know Qt to make a minimal
reproducible example as well what blocks them to report upstream as
well but they usually can reproduce issues on other real world Qt
applications. Sometimes they can't reproduce with other applications
(perhaps edges of Qt that are not so widely used) but the issues feel
low-level enough to think it's Qt for sure (e.g. clipboard, font
rendering or text input problems).

Once upon a time I tried to upstream a patch I made to fix a crash from
a crash trace but I've got a resistance from reviewers requiring me to
create a bug report (which I can't do due to the minimal reproducible
example rule as I had no idea how to make one for the trace in
question). This made me feel disappointed and I perhaps won't send such
fixes upstream 

Re: [Development] Buddy group to help new contributors

[Elias Steurer via Development]

Hi Volker and other interested readers,

I do agree with most of what you said. It is unrealistic to switch out 
the current platform tomorrow. This would be a multi year process.



   Wiki

In the current state the wiki is a mix of outdated and redundant 
information. We had a great success with mkdocs (or readthedocs) as a 
replacement for our internal mediawiki. The search of these wikis is so 
much better. In addition it is easy to start a quick MR/PR and fix the 
docs. IMHO as a programmer a simple git repo that I can build locally 
with one command, is easier to work with.



   Getting Qt running (on Windows)

Removing perl entirely would be nice. Python is a requirement anyway, so 
it would be easy to rewrite the script with python3. This my experience 
with perl on Windows setting up Qt:


1. Started by searching online for relevant documentation and deciding
   to use docs over wiki entries.
2. Identified the necessary tools for the project: CMake, Ninja, Git,
   Python, and MSVC 2022. Already had these installed.
3. Decided to skip setting environment variables, preferring to use an
   IDE for compilation.
4. Noticed that Qt didn't have a |CMakePresets.json| file, so created
   one based on the 'screenplay' project.
5. Examined options on the Qt Building Guide and realized the need to
   install Perl, especially for contributing to Qt version 6.6.
6. Cloned the Qt repository using |git clone
   https://code.qt.io/qt/qt5.git qt6| and renamed the local folder to
   |qt6|.
7. Ran |perl init-repository| to initialize the repository.
8. Encountered issues with Perl paths and cmake configuration in Visual
   Studio Code.
9. Experienced errors with cmake and Perl's |ld.exe|, which led to
   frustration with Perl.
10. Found an issue on GitHub related to the problem.
11. Decided to remove Perl from the PATH and restart VSCode to resolve
   the issue.
12. Encountered a new problem with Perl 5.38 not working due to locale
   issues.
13. Resolved the issue by downgrading to an older version of Perl (5.32.1).
14. Realized the need to set the |--codereview-username| for Qt
   contributions. So delete the Qt source folder and start again.

This took like more than an hour of troubleshooting.

Now setting up gerrit:

1. Tweaked SSH config as per instructions on the Qt wiki.
 * Encountered confusion with Windows path conventions and the
   absence of a default |.ssh/config| file. Used 7-zip GUI to
   bypass filename restrictions.
2. Generated an SSH key pair for authentication.
 * Faced issues with the command's file path syntax being
   Unix-specific. Adjusted for Windows and successfully generated
   the key.
3. Copied the public SSH key to the clipboard and added it to the Qt
   project's Gerrit SSH Keys settings.
 * Successfully verified SSH connection to the Qt project's Gerrit
   server.
4. Attempted to use recommended Git settings.
 * Reluctant to enable |core.autocrlf| globally due to potential
   conflicts with other projects.
5. Obtained the source code for the desired Qt project and made changes
   to the code and committed them locally.
6. Tried pushing changes using Gerrit.
 * Initially used the wrong repository, leading to a "no new
   changes" error. Realized the need to push to a submodule
   specific to the changes (|qtdeclarative|).
7. Successfully pushed changes to the |qtdeclarative| submodule on Gerrit.
 * Encountered uncertainty about the next steps, particularly
   regarding the review process and seeking attention for the
   changes on various platforms.

So this took  me about 1 hour of googleing. Keep in mind if you know 
this setup for 10 years you will not have this issue for newcomers it is 
hell. With git/hub/lab/ea it is fork->clone->push->create mr.


This could all be fixed in two steps:


 1. The git submodule system Qt uses.

A mono repo would be best. If there is an argue about repo clone size, 
lets just use git clone --depth 1. In the end the wiki tells you to 
clone all the modules anyway, so whats the point?



 2. Lets use CMakePresets.json

So the workflow is to load/unload sub repos and then check in the main 
CMakeLists.txt if the CMakeLists.txt file in the sub dir exists. If we 
find the submodule then we build it. This could be way better handled 
with a CMakePresets.json. o3de, formerly known as Amazon lumberyard, 
(formerly known as CryEngine) uses them quite extensively for every 
platform . 
Then in combination with user presets, one could create a preset for 
every main Qt module like do you want to build qml gui stuff? Here is a 
preset that enables all needed modules. This way you would not have to 
load/unload modules all the time. You can inherit from other presets to 
enable test etc.



   Other contributing tools

I checked about comment on commit and found some open issues on the 
Gitlab issue tracker. This is weird 

Re: [Development] Buddy group to help new contributors

[Volker Hilsheimer via Development]

Hi Elias,

Thanks for taking the time to share your input to this! See comments inline.

> On 8 Dec 2023, at 15:33, Elias Steurer via Development 
>  wrote:
> 
> Hi Volker,
> Thanks for the update on the Qt Contributors Summit. It's great to hear about 
> the initiatives to make the contribution process smoother, especially for 
> newcomers.
> However, while setting up a Gerrit group for hand-holding new contributors is 
> a step in the right direction, I believe we might be missing a crucial point. 
> The core issue isn't just about guiding new contributors through the existing 
> process; it's about the inherent complexity and user-unfriendliness of the 
> current workflow.


On the positive side, these things are not mutually exclusive: we can improve 
the process and the documentation while providing a better welcome-experience 
and support for new people that want to contribute, but struggle with what we 
have. In fact, I’d claim that hand-holding people through some personal contact 
is always going to be a good idea, even if Qt would be a simple code base that 
anyone could build, write tests for, and make fixes in without having to learn 
anything new.


> From installing a plethora of tools to dealing with the confusing repo 
> cloning process, Perl dependencies and Perl path issues,  the barriers to 
> entry are high.


Yes, setting up a local development environment that can build Qt is not 
trivial, esp if you want to build all submodules, and want to work on Windows 
on the one hand, but on the other hand want to use something other than the 
native compiler and SDK for that platform ;) And if you want to make sure that 
your code compiles and that tests pass with your modifications just on the main 
desktop platforms, then you’ll be busy setting things up for a while.

There is certainly room for improvement, but I think the complexity is a bit in 
the nature of the beast as well (that beast being not just Qt, but C++, several 
development platforms, even more cross-compile targets etc).
Can we make that fundamentally easier? Should that be our goal and what we 
spend our time on? Would it make a huge difference if we didn’t require perl 
(and IIRC we only need it for the init-repository script)? You need cmake, 
ninja, and your compiler and platform-specific SDK (which is mostly trivial on 
Windows and macOS; on Linux it’s a bit of a piece-meal). But none of that 
strikes me as particular esoteric stuff. Well, unless you want to build 
webengine, or check all the SQL-driver boxes.

Anyway, if you can make specific suggestions on how we can improve the build 
system of Qt and reduce dependencies to tools or libraries, then please do so.

> Then, there's the challenge of navigating the Gerrit setup, which is far from 
> straightforward. The documentation is inconsistent and sometimes 
> contradictory, adding to the confusion. And that's before even getting into 
> the complexities of submitting patches and managing code reviews. If you want 
> I can send you my personal notes, that I have written down recently while 
> setting up Qt locally for the first time in years. Most of it is about my 
> frustration why a solved problem, like contributing to an open source 
> project, is so unnecessary complicated.
> In essence, the current workflow is daunting, even with a support group. I 
> suggest we consider moving towards a more streamlined and "sane" workflow. 
> Simplifying the entire contribution process from the ground up will make Qt 
> more accessible to everyone. Once a more intuitive and welcoming workflow is 
> establish, guiding new contributors will be much more effective. After all, 
> the best hand-holding is the one you don't need because the path is clear and 
> easy to follow. 


If step one has to be that we simplify the entire contribution process from the 
ground up, then this will get us exactly nowhere any time soon. This is not 
only because there is a variety of differences in the Qt project contributor 
community about what we should optimize for. Many of us consider gerrit’s code 
review user experience vastly superior to github’s or gitlabs; many of us 
believe that the history of a patch is a critical piece of data that is easily 
lost, or hard to find, in the github/lab workflow. I don’t know if it’s 
possible by now to comment on the commit message in github/lib/ea (it wasn’t 
last time I checked), but not being able to do so would be a total showstopper 
for me personally, and I don’t understand how projects that care about their 
git history can function if reviewers cannot give structured feedback to the 
most important part of any change, esp to new people.

So building consensus of what “simplification” means in practice is going to 
take a while.

But even if by Christmas we all agreed that we should move things to 
github/lab/ea, it will take a significant investment of time and money to 
actually make that move. There exists a significant amount of tooling, 

Re: [Development] Buddy group to help new contributors

[Elias Steurer via Development]

Hi Volker,

Thanks for the update on the Qt Contributors Summit. It's great to hear 
about the initiatives to make the contribution process smoother, 
especially for newcomers.


However, while setting up a Gerrit group for hand-holding new 
contributors is a step in the right direction, I believe we might be 
missing a crucial point. The core issue isn't just about guiding new 
contributors through the existing process; it's about the inherent 
complexity and user-unfriendliness of the current workflow.


From installing a plethora of tools to dealing with the confusing repo 
cloning process, Perl dependencies and Perl path issues 
,  
the barriers to entry are high. Then, there's the challenge of 
navigating the Gerrit setup, which is far from straightforward. The 
documentation is inconsistent and sometimes contradictory, adding to the 
confusion. And that's before even getting into the complexities of 
submitting patches and managing code reviews. If you want I can send you 
my personal notes, that I have written down recently while setting up Qt 
locally for the first time in years. Most of it is about my frustration 
why a solved problem, like contributing to an open source project, is so 
unnecessary complicated.


In essence, the current workflow is daunting, even with a support group. 
I suggest we consider moving towards a more streamlined and "sane" 
workflow. Simplifying the entire contribution process from the ground up 
will make Qt more accessible to everyone. Once a more intuitive and 
welcoming workflow is establish, guiding new contributors will be much 
more effective. *After all, the best hand-holding is the one you don't 
need because the path is clear and easy to follow. *


It might be worth considering a migration to GitLab, which has been a 
successful move for other open-source projects like KDE and Arch. Given 
that Qt already uses an internal GitLab instance, this could be a good 
platform for future collaboration. Alternatively, adopting Gitea, as 
used by the Blender Foundation, could also be a viable option if Gitlab 
licensing is a no-go.


I strongly believe the focus should be on overhauling the workflow 
first. Everything else, including smoother onboarding of new 
contributors, will naturally follow.


There was also an discussion about this recently on Reddit. 



Best,

Eli

On 12/5/2023 9:57 AM, Volker Hilsheimer via Development wrote:

At the Qt Contributors Summit in Berlin last week, we discussed various ideas 
around improving the contribution experience, esp for new people.

One action that came out of that was setting up a gerrit group of people that are 
able and willing to hand-hold new contributors through the process. This includes 
setting up your local development environment, gerrit configuration and workflow, 
and finding out what to work on from e.g. Jira. The basic idea is that we establish 
a (gerrit, probably) group with buddies; we can already identify “first gerrit 
reviews" for a new user, and then we can proactively reach out with a welcome 
message, and add the group of buddies as a reviewer.

A few people raised their hand at the event, but I don’t think anyone took down 
the names, and I was busy juggling microphones. And either way, this is of 
course open to anyone! So please reply to this, either to all or privately to 
me, if you want to be part of that group.

Cheers,
Volker
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development