Team Collaboration Considerations

Team Collaboration Considerations

[Jerry D]

Hi all,

Some of you may recall way back when I established the gfortran IRC 
channel to facilitate collaboration on gfortran development.

I have had some discussions with a few people about advancing to newer 
technology.  One thing I have learned is that the gcc C++ team has 
adopted the Mattermost platform.  I have also used Slack and Teams.  
There are many others. The gcc IRC channel is still active. The gfortran 
IRC channel exists but is less used.

I would like suggest that gfortranners adopt one of these platforms. The 
advantages are:

 1.   We can post chat questions back and forth via mobile devices
    without having toopen and scan our emails
 2. We can share examples and files easily.
 3. Screen shot are easily exchanged.
 4. Integration with platforms such as Github.

Pros and Cons of some of the choices.  I have only looked at the Free 
options

 1. Slack has adopted some limitations on being able to go back and look
    at older posts.  Functionally it is quite good and integrates well
    with github.
 2. I looked at Element and Fractal which use the Matrix protocols. 
    Very open source, not so mature yet.
 3. Mattermost looks pretty good and was easy to set up.  The free
    version is a bit better than Slacks. GCC C++ uses it.

If we can get a concensus I would happy to get something set up .  I am 
leaning to Mattermost.  The mobile phone app is easy and the web browser 
works fine.

I do think in the long run, doing this will help everyone greatly.

Any thoughts from all?

Regards,

Jerry

Re: Team Collaboration Considerations

[Benson Muite]

On 12/4/22 06:52, Jerry D via Fortran wrote:

> 3. Mattermost looks pretty good and was easy to set up.  The free
>     version is a bit better than Slacks. GCC C++ uses it.
This server application runs well. The desktop application is a little 
resource heavy, however there is also a Qt based desktop application:
https://github.com/nuclear868/mattermost-qt

It is possible to bridge Mattermost and IRC:
https://github.com/42wim/matterbridge
https://github.com/42wim/matterircd

> 

Re: Team Collaboration Considerations

[Jerry D]

Other than Benson, I have received no sign of any interest from gfortran 
developers to adopt a teaming/collaboration platform.  I am a bit 
disappointed. Maybe my intent was misunderstood.  I am not suggesting 
replacing the email approval process but there are many other features 
of these platforms, in particular, communication efficiency that would 
be very helpful.

I know many software developers who use these tools regularly. Honestly 
I do not know why gcc.gnu.org does not adopt one of these as a whole. 
Perhaps it is simply resistance to change.

I will keep the Mattermost workspace.  If anyone want to join send me 
your email and I will send you an invite.

Well, as always, best regards,

Jerry

On 12/4/22 6:16 AM, Benson Muite wrote:
> On 12/4/22 06:52, Jerry D via Fortran wrote:
>
>> 3. Mattermost looks pretty good and was easy to set up.  The free
>>     version is a bit better than Slacks. GCC C++ uses it.
> This server application runs well. The desktop application is a little 
> resource heavy, however there is also a Qt based desktop application:
> https://github.com/nuclear868/mattermost-qt
>
> It is possible to bridge Mattermost and IRC:
> https://github.com/42wim/matterbridge
> https://github.com/42wim/matterircd
>
>>
>

Re: Team Collaboration Considerations

[Benson Muite]

On 12/8/22 04:54, Jerry D wrote:
> Other than Benson, I have received no sign of any interest from gfortran 
> developers to adopt a teaming/collaboration platform.  I am a bit 
> disappointed. Maybe my intent was misunderstood.  I am not suggesting 
> replacing the email approval process but there are many other features 
> of these platforms, in particular, communication efficiency that would 
> be very helpful.
There is a discourse site https://fortran-lang.discourse.group that 
caters to Fortran in general.

> 
> I know many software developers who use these tools regularly. Honestly 
> I do not know why gcc.gnu.org does not adopt one of these as a whole. 
> Perhaps it is simply resistance to change.

Maybe it is helpful to bridge Mattermost and IRC? Interoperability is 
good and minimizes the cost of having multiple clients running.  The 
chat applications are great for enabling focus, for example adding git 
commit notifications in a separate channel.

https://quassel-irc.org seems like it may also be helpful.
> 
> I will keep the Mattermost workspace.  If anyone want to join send me 
> your email and I will send you an invite.
> 
> Well, as always, best regards,
> 
> Jerry
> 
> On 12/4/22 6:16 AM, Benson Muite wrote:
>> On 12/4/22 06:52, Jerry D via Fortran wrote:
>>
>>> 3. Mattermost looks pretty good and was easy to set up.  The free
>>>     version is a bit better than Slacks. GCC C++ uses it.
>> This server application runs well. The desktop application is a little 
>> resource heavy, however there is also a Qt based desktop application:
>> https://github.com/nuclear868/mattermost-qt
>>
>> It is possible to bridge Mattermost and IRC:
>> https://github.com/42wim/matterbridge
>> https://github.com/42wim/matterircd
>>
>>>
>>
> 

Re: Team Collaboration Considerations

[Steve Kargl]

On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
> Other than Benson, I have received no sign of any interest from gfortran
> developers to adopt a teaming/collaboration platform.  I am a bit
> disappointed. Maybe my intent was misunderstood.  I am not suggesting
> replacing the email approval process but there are many other features of
> these platforms, in particular, communication efficiency that would be very
> helpful.
> 
> I know many software developers who use these tools regularly. Honestly I do
> not know why gcc.gnu.org does not adopt one of these as a whole. Perhaps it
> is simply resistance to change.
> 
> I will keep the Mattermost workspace.  If anyone want to join send me your
> email and I will send you an invite.
> 
> Well, as always, best regards,
>
 
Jerry,

I think you're seeing the effects of the move to git and an aging
base of contributors.  Harald is almost single-handily dealing with
bug reports.  Mikeal has recently been reviewing Harald's patches,
and offers some good advice on improvements.  Occasionally, Thomas
and I offer up patches, but this occurs in a rather sparse manner.
In fact, if I fix a bug, the patch is attached to the bugzilla report
where it sits until Harald stumbles across it or it bit rots.
 
I don't know how to attract new contributors.  I've invited more
than one person who's pointed out a issue with gfortran to join
the developers.  This is typically met with "I don't know C",
"I don't know compiler design", "I don't have time"r, ...

-- 
Steve

Re: Team Collaboration Considerations

[Tobias Burnus]

Hi,

On 08.12.22 17:27, Steve Kargl via Fortran wrote:
> On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
>> Other than Benson, I have received no sign of any interest from gfortran
>> developers to adopt a teaming/collaboration platform.  I am a bit
>> disappointed. Maybe my intent was misunderstood.  I am not suggesting
>> replacing the email approval process but there are many other features of
>> these platforms, in particular, communication efficiency that would be very
>> helpful.

I personally do not have a strong preference for any. But every
additional communication channel costs time time (setting up, tracking
discussions etc.) and it is not really clear what's the benefits vs.
costs ratio.

I don't mind adding yet another channel to watch, but I cannot guarantee
that I will be able to actively follow it. If it is not high volume and
I get some notification that something has changed by email, it might
work – or if it is interesting/often enough used, I might log in from
time to time – but otherwise it will simply get ignored. Not due to not
being interested but due to having too much else on to do.

>> I will keep the Mattermost workspace.  If anyone want to join send me your
>> email and I will send you an invite.
Let's try it – please send an invite.

> I think you're seeing the effects of the move to git and an aging
> base of contributors.

I don't think that moving to 'git' really causes the problem – nor the
move to C++, given that is is not really visible in most code. I think
the main problem is that most things do work and attracting a new
contributor is always difficult. Google Summer of Code was one
successful way, but attracting contributors is not trivial.

This year, two were interested working on gfortran but at the end it did
not work out – despite me spending quite some time to guide them to get
started.

> Occasionally, Thomas
> and I offer up patches, but this occurs in a rather sparse manner.
> In fact, if I fix a bug, the patch is attached to the bugzilla report
> where it sits until Harald stumbles across it or it bit rots.
> ...
> "I don't have time"

I think we have three areas: bug fixes (where Harald does an awesome
job), cleanup/restructuring of some bad design, and new features (mainly
but not only F2018). The problem with the second item is that it takes
quite some work for little visible benefit; we do some bits here and
there for bug fixes (or for TS29113) but nothing larger. Likewise for
F2018, some low-hanging fruits are easily done, but some larger
development work is really due.

I still intend to do more on the gfortran side, but I am rather busy on
the OpenMP side (code, specification meetings including filing issues
and creating spec patches) and things like working on gfortran competes
with fixing other GCC issues (a pragma, documentation, long-standing
other Bugzilla bugs), fixing issues in external testsuites/libraries,
GSoC mentoring, internal mentoring etc. I still hope that I will do more
non-OpenMP gfortran work but it does not look as if I will do a lot any
time soon.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

RE: Team Collaboration Considerations

[Holcomb, Katherine A (kah3f)]

I was thinking I might try to contribute when I retire, though that may be in a year or two.  But it's been a very long time since I dove into a large software project and it's intimidating.  I do know C (really C++, I haven't used plain C for a long time).   I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular. 

Is there some kind of "getting started" guide?

Katherine Holcomb 
UVA Research Computing  https://www.rc.virginia.edu 
kah3f@virginia.edu    434-982-5948 

-----Original Message-----
From: Fortran <fortran-bounces+kholcomb=virginia.edu@gcc.gnu.org> On Behalf Of Steve Kargl via Fortran
Sent: Thursday, December 8, 2022 11:27 AM
To: Jerry D via Fortran <fortran@gcc.gnu.org>
Cc: Benson Muite <benson_muite@emailplus.org>
Subject: Re: Team Collaboration Considerations

On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
> Other than Benson, I have received no sign of any interest from 
> gfortran developers to adopt a teaming/collaboration platform.  I am a 
> bit disappointed. Maybe my intent was misunderstood.  I am not 
> suggesting replacing the email approval process but there are many 
> other features of these platforms, in particular, communication 
> efficiency that would be very helpful.
> 
> I know many software developers who use these tools regularly. 
> Honestly I do not know why gcc.gnu.org does not adopt one of these as 
> a whole. Perhaps it is simply resistance to change.
> 
> I will keep the Mattermost workspace.  If anyone want to join send me 
> your email and I will send you an invite.
> 
> Well, as always, best regards,
>
 
Jerry,

I think you're seeing the effects of the move to git and an aging base of contributors.  Harald is almost single-handily dealing with bug reports.  Mikeal has recently been reviewing Harald's patches, and offers some good advice on improvements.  Occasionally, Thomas and I offer up patches, but this occurs in a rather sparse manner.
In fact, if I fix a bug, the patch is attached to the bugzilla report where it sits until Harald stumbles across it or it bit rots.
 
I don't know how to attract new contributors.  I've invited more than one person who's pointed out a issue with gfortran to join the developers.  This is typically met with "I don't know C", "I don't know compiler design", "I don't have time"r, ...

--
Steve

Re: Team Collaboration Considerations

[Toon Moene]

On 12/8/22 20:14, Holcomb, Katherine A (kah3f) via Fortran wrote:

> I was thinking I might try to contribute when I retire, though that may be in a year or two.  But it's been a very long time since I dove into a large software project and it's intimidating.  I do know C (really C++, I haven't used plain C for a long time).   I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular.
> 
> Is there some kind of "getting started" guide?

Thanks, Katherine, for your thoughts on this side of support (i.e., 
fixing compiler bugs, and how to get people interested in contributing).

Based on that, I thought of another approach, namely: interesting 
*users* of gfortran to provide us with useful information on their 
experiences with it (lest we only look at the depressing list of PRs).

Would it help if we created a fortran-help@gcc.gnu.org list (a loose 
parallel of gcc-help@gcc.gnu.org) for *questions* from our user base ?

I just have to look at the questions I get at work from my colleagues:

1. I get this message while compiling XYZ weather forecasting model
    (HELP, what does it mean ?). How do I solve it ? Do I need ABC
    (mega-corporation chip manufacturing's) fortran compiler ?

2. gfortran gives me a "internal compiler error", but this code
    compiled perfectly just a year ago (an ICE is never a user's
    problem). How can I work around it ?

3. Is this (source code provided) code conformant ? gfortran
    complains about it, but XYZ compiler just compiles it fine.

etc.

This might not result in many new contributors, but it shows to the 
broader GCC development community what gfortran is used for, and how 
*we* deal with their questions and problems (and, thus, how important 
this part of the GNU Compiler *Collection* is).

Oh, BTW, I retire in nine months, which would give me loads of time to 
deal with such a mailing list.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Team Collaboration Considerations

[Paul Richard Thomas]

[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]

Hi Jerry and everybody else,

I am with Tobias on this. Between work, gfortran, RSPCA, club and
neighbourhood activities I am "channelled" up to the eyeballs. Adding
another wouldn't make any great odds but I couldn't pay much more attention
to it than many of the others - sorry!

At the present, I am spending more time than I really have on finishing the
finalization patch(es). Hopefully it will see the light of day very soon.
After that, I have to fix the mess that I made of PDTs. Neither of these
feature very high on the scale of the user survey that Steve Lionel ran
but, at least, we could come close to F2003 compliance. It would help
enormously, if somebody would sit down and figure out in detail where the
F2008/2018 gaps are. I am about to vote on the F2023 DAS so if anybody has
any thoughts on that, I would like to hear them. I hate conditional
arguments but the rest looks OK and, I suspect, is relatively easily
implemented.

One really helpful collaborative activity would be to update the gfortran
wiki. For a good long while that, together with the gfortran list, did
serve as our collaborative focus.

Regards

Paul


On Fri, 9 Dec 2022 at 19:36, Toon Moene <toon@moene.org> wrote:

> On 12/8/22 20:14, Holcomb, Katherine A (kah3f) via Fortran wrote:
>
> > I was thinking I might try to contribute when I retire, though that may
> be in a year or two.  But it's been a very long time since I dove into a
> large software project and it's intimidating.  I do know C (really C++, I
> haven't used plain C for a long time).   I am one of those "aging" types
> but I am familiar at least superficially with newer tools because I must
> use them for work, specifically git and Slack (Mattermost seems to be an
> open-source Slack alternative) -- we make heavy use of Slack in particular.
> >
> > Is there some kind of "getting started" guide?
>
> Thanks, Katherine, for your thoughts on this side of support (i.e.,
> fixing compiler bugs, and how to get people interested in contributing).
>
> Based on that, I thought of another approach, namely: interesting
> *users* of gfortran to provide us with useful information on their
> experiences with it (lest we only look at the depressing list of PRs).
>
> Would it help if we created a fortran-help@gcc.gnu.org list (a loose
> parallel of gcc-help@gcc.gnu.org) for *questions* from our user base ?
>
> I just have to look at the questions I get at work from my colleagues:
>
> 1. I get this message while compiling XYZ weather forecasting model
>     (HELP, what does it mean ?). How do I solve it ? Do I need ABC
>     (mega-corporation chip manufacturing's) fortran compiler ?
>
> 2. gfortran gives me a "internal compiler error", but this code
>     compiled perfectly just a year ago (an ICE is never a user's
>     problem). How can I work around it ?
>
> 3. Is this (source code provided) code conformant ? gfortran
>     complains about it, but XYZ compiler just compiles it fine.
>
> etc.
>
> This might not result in many new contributors, but it shows to the
> broader GCC development community what gfortran is used for, and how
> *we* deal with their questions and problems (and, thus, how important
> this part of the GNU Compiler *Collection* is).
>
> Oh, BTW, I retire in nine months, which would give me loads of time to
> deal with such a mailing list.
>
> Kind regards,
>
> --
> Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

Re: Team Collaboration Considerations

[Toon Moene]

On 12/9/22 22:56, Paul Richard Thomas wrote:

> One really helpful collaborative activity would be to update the 
> gfortran wiki. For a good long while that, together with the gfortran 
> list, did serve as our collaborative focus.

Another thing I might have tons of time for beyond 20230827.

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Team Collaboration Considerations

[Jerry D]

On 12/8/22 9:25 AM, Tobias Burnus wrote:
> Hi,
>
> On 08.12.22 17:27, Steve Kargl via Fortran wrote:
>> On Wed, Dec 07, 2022 at 05:54:40PM -0800, Jerry D via Fortran wrote:
>>> Other than Benson, I have received no sign of any interest from 
>>> gfortran
>>> developers to adopt a teaming/collaboration platform.  I am a bit
>>> disappointed. Maybe my intent was misunderstood.  I am not suggesting
>>> replacing the email approval process but there are many other 
>>> features of
>>> these platforms, in particular, communication efficiency that would 
>>> be very
>>> helpful.
>
> I personally do not have a strong preference for any. But every
> additional communication channel costs time time (setting up, tracking
> discussions etc.) and it is not really clear what's the benefits vs.
> costs ratio.
For myself, a clear benefit is at a glance on my phone I can know if 
there is activity and i can reply on the fly while I am at work or 
whereever, or reply later as i choose without having to scan my emails
>
> I don't mind adding yet another channel to watch, but I cannot guarantee
> that I will be able to actively follow it. If it is not high volume and
> I get some notification that something has changed by email, it might
> work – or if it is interesting/often enough used, I might log in from
> time to time – but otherwise it will simply get ignored. Not due to not
> being interested but due to having too much else on to do.
>
Understood, we all have this issue.
>>> I will keep the Mattermost workspace. If anyone want to join send me 
>>> your
>>> email and I will send you an invite.
> Let's try it – please send an invite.
I wiil start sending invites. I am learning this thing myself.  I will 
also post to Fortran Discourse occasionally to see if anyone new may be 
interested in getting invited as well.  I have in mind the possibilities 
of this being a mentoring tool for any newer persons and a 'give me 
hint' place for the long timers trying to remember where this or that 
was in the code etc.

>
>> I think you're seeing the effects of the move to git and an aging
>> base of contributors.
>
> I don't think that moving to 'git' really causes the problem – nor the
> move to C++, given that is is not really visible in most code. I think
> the main problem is that most things do work and attracting a new
> contributor is always difficult. Google Summer of Code was one
> successful way, but attracting contributors is not trivial.

Yes, I do not see git as the main issue. I use it often at work.  I also 
use C, C++, C#, Python, and some others on occasion.  The only trick is 
jumping between the various eye candy features. Code is code, but then i 
am sort of a generalist which is why sometime i get stuck in details. LOL
>
> This year, two were interested working on gfortran but at the end it did
> not work out – despite me spending quite some time to guide them to get
> started.

If you can send me contact information on people.  Maybe I can invite 
them to the Mattermost. (Up to you of course)

>
>> Occasionally, Thomas
>> and I offer up patches, but this occurs in a rather sparse manner.
>> In fact, if I fix a bug, the patch is attached to the bugzilla report
>> where it sits until Harald stumbles across it or it bit rots.
>> ...
>> "I don't have time"
>
Totally understand this issue.
> I think we have three areas: bug fixes (where Harald does an awesome
> job), cleanup/restructuring of some bad design, and new features (mainly
> but not only F2018). The problem with the second item is that it takes
> quite some work for little visible benefit; we do some bits here and
> there for bug fixes (or for TS29113) but nothing larger. Likewise for
> F2018, some low-hanging fruits are easily done, but some larger
> development work is really due.
>
> I still intend to do more on the gfortran side, but I am rather busy on
> the OpenMP side (code, specification meetings including filing issues
> and creating spec patches) and things like working on gfortran competes
> with fixing other GCC issues (a pragma, documentation, long-standing
> other Bugzilla bugs), fixing issues in external testsuites/libraries,
> GSoC mentoring, internal mentoring etc. I still hope that I will do more
> non-OpenMP gfortran work but it does not look as if I will do a lot any
> time soon.
>
> Tobias
>

Your contributions have always been very appreciated.

Jerry

Re: Team Collaboration Considerations

[Jerry D]

On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
> I was thinking I might try to contribute when I retire, though that may be in a year or two.  But it's been a very long time since I dove into a large software project and it's intimidating.  I do know C (really C++, I haven't used plain C for a long time).   I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular.
> 
> Is there some kind of "getting started" guide?
> 
> Katherine Holcomb
> UVA Research Computing  https://www.rc.virginia.edu
> kah3f@virginia.edu    434-982-5948
> 

In your case I would recommend just pick a bug and start exploring it 
with gdb and valgrind.  There is no need to learn the whole project.  If 
you want, we could pick one for you as a starter.  I will send you an 
invite to the Mattermost so you can watch as we organize it.  One 
thought we had is to use "boards" for categories of bugs and use it as a 
way to triage the list of bugs (ideas evolving)

I dont think you need to wait for retirement. Nothing wrong with 
dabbling hear and there as time permits.

Re: Team Collaboration Considerations

[Steve Kargl]

On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote:
> On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
> > I was thinking I might try to contribute when I retire, though that may be in a year or two.  But it's been a very long time since I dove into a large software project and it's intimidating.  I do know C (really C++, I haven't used plain C for a long time).   I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular.
> > 
> > Is there some kind of "getting started" guide?
> > 
> > Katherine Holcomb
> > UVA Research Computing  https://www.rc.virginia.edu
> > kah3f@virginia.edu    434-982-5948
> > 
> 
> In your case I would recommend just pick a bug and start exploring it with
> gdb and valgrind.  There is no need to learn the whole project.  If you
> want, we could pick one for you as a starter.  I will send you an invite to
> the Mattermost so you can watch as we organize it.  One thought we had is to
> use "boards" for categories of bugs and use it as a way to triage the list
> of bugs (ideas evolving)
> 

Katherine's name appears in the copyright notice in intrinsic.h
and intrinsic.c.  The overall design has not changed from when
g95 was imported to become gfortran.  There are a few new intrinsics
coming with F2023.  Perhaps, this might be a point of entry (pun
intended) for returning to gfortran hacking.

Katherine, your return will be most welcomed.

-- 
Steve

Re: Team Collaboration Considerations

[Thomas Koenig]

Hi Katherine,

> Is there some kind of "getting started" guide?

There's https://gcc.gnu.org/wiki/GFortranHacking which has some
pointers.  It could also use a bit of an update (file names are now
.cc instead of .c :-)

Best regards

	Thomas

RE: Team Collaboration Considerations

[Holcomb, Katherine A (kah3f)]

My main contribution to the early (*really* early, I started with g95) intrinsics implementation was a lot of cutting-and-pasting and typing.  I just replicated functions fairly mindlessly and made appropriate substitutions.  But I hope at least that my copyright assignment paperwork is still in force.

Katherine Holcomb 
UVA Research Computing  https://www.rc.virginia.edu 
kah3f@virginia.edu    434-982-5948 

-----Original Message-----
From: Fortran <fortran-bounces+kholcomb=virginia.edu@gcc.gnu.org> On Behalf Of Steve Kargl via Fortran
Sent: Saturday, December 10, 2022 4:09 PM
To: Jerry D <jvdelisle2@gmail.com>
Cc: Holcomb, Katherine A (kah3f) <kah3f@virginia.edu>; Jerry D via Fortran <fortran@gcc.gnu.org>; Benson Muite <benson_muite@emailplus.org>; Harald Anlauf <anlauf@gmx.de>
Subject: Re: Team Collaboration Considerations

On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote:
> On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote:
> > I was thinking I might try to contribute when I retire, though that may be in a year or two.  But it's been a very long time since I dove into a large software project and it's intimidating.  I do know C (really C++, I haven't used plain C for a long time).   I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular.
> > 
> > Is there some kind of "getting started" guide?
> > 
> > Katherine Holcomb
> > UVA Research Computing  https://www.rc.virginia.edu 
> > kah3f@virginia.edu    434-982-5948
> > 
> 
> In your case I would recommend just pick a bug and start exploring it 
> with gdb and valgrind.  There is no need to learn the whole project.  
> If you want, we could pick one for you as a starter.  I will send you 
> an invite to the Mattermost so you can watch as we organize it.  One 
> thought we had is to use "boards" for categories of bugs and use it as 
> a way to triage the list of bugs (ideas evolving)
> 

Katherine's name appears in the copyright notice in intrinsic.h and intrinsic.c.  The overall design has not changed from when
g95 was imported to become gfortran.  There are a few new intrinsics coming with F2023.  Perhaps, this might be a point of entry (pun
intended) for returning to gfortran hacking.

Katherine, your return will be most welcomed.

--
Steve

Re: Team Collaboration Considerations

[Janne Blomqvist]

On Sun, Dec 4, 2022 at 5:53 AM Jerry D via Fortran <fortran@gcc.gnu.org> wrote:
>  1. Slack has adopted some limitations on being able to go back and look
>     at older posts.  Functionally it is quite good and integrates well
>     with github.
>  2. I looked at Element and Fractal which use the Matrix protocols.
>     Very open source, not so mature yet.
>  3. Mattermost looks pretty good and was easy to set up.  The free
>     version is a bit better than Slacks. GCC C++ uses it.
>
> If we can get a concensus I would happy to get something set up .  I am
> leaning to Mattermost.  The mobile phone app is easy and the web browser
> works fine.
>
> I do think in the long run, doing this will help everyone greatly.
>
> Any thoughts from all?

Hi,

I haven't commented earlier as I haven't been active in GFortran
development for a couple of years (new job, kids, etc. etc.). So don't
take my opinions too seriously.

But in general, yes, I do think IRC is showing its age in an
increasingly multi-device and mobile world. From a Free Software
perspective, adopting a closed platform like Slack is perhaps not
ideal, if alternatives exist. And I believe the free (as in beer)
version of Slack has some significant limitations compared to the
licensed one. Matrix is perhaps the one with the most future
potential, but maybe it's not really there yet. While I haven't used
Mattermost myself, I've heard good things about it. And as long as
it's not used as some sort of permanent record of things instead of
the mailing list, I guess it's relatively easy to switch to another
platform in the future. Just to be sure, this is some hosted version,
and not something which Jerry must maintain himself on some server in
a dusty corner?

As for the perennial question of how to attract new contributors,
yeah, it's hard. I'm happy to see that Harald has gotten off to a
flying start, amazing! I also do note with some satisfaction that
there's some good efforts to make modern Fortran attractive for
developers, and not just something you use because the codebase you
work on was started 4 decades ago. Gtk-Fortran was an early example of
this which showed that modern Fortran could be useful outside the core
numerics domain. I'm also thinking of the https://fortran-lang.org
site and associated efforts like the 'stdlib', a more fleshed out
'standard' library (https://stdlib.fortran-lang.org/ ), and the
package manager FPM (https://fpm.fortran-lang.org ). Keeping in touch
with these people, and suggesting that people help that effort if they
aren't comfortable with hacking on the compiler outright, could be a
way of growing the open source Fortran programmer base, which could
eventually grow into contributors to the compiler itself? In
particular if they want to use some newfangled Fortran feature that
doesn't work in GFortran; scratching your own itch is always a good
motivator!

-- 
Janne Blomqvist

Re: Team Collaboration Considerations

[Jerry D]

On 12/13/22 12:10 AM, Janne Blomqvist wrote:
--- snip --
>> Any thoughts from all?
> 
> Hi,
> 
> I haven't commented earlier as I haven't been active in GFortran
> development for a couple of years (new job, kids, etc. etc.). So don't
> take my opinions too seriously.
> 
> But in general, yes, I do think IRC is showing its age in an
> increasingly multi-device and mobile world. From a Free Software
> perspective, adopting a closed platform like Slack is perhaps not
> ideal, if alternatives exist. And I believe the free (as in beer)
> version of Slack has some significant limitations compared to the
> licensed one. Matrix is perhaps the one with the most future
> potential, but maybe it's not really there yet. While I haven't used
> Mattermost myself, I've heard good things about it. And as long as
> it's not used as some sort of permanent record of things instead of
> the mailing list, I guess it's relatively easy to switch to another
> platform in the future. Just to be sure, this is some hosted version,
> and not something which Jerry must maintain himself on some server in
> a dusty corner?
> 
> As for the perennial question of how to attract new contributors,
> yeah, it's hard. I'm happy to see that Harald has gotten off to a
> flying start, amazing! I also do note with some satisfaction that
> there's some good efforts to make modern Fortran attractive for
> developers, and not just something you use because the codebase you
> work on was started 4 decades ago. Gtk-Fortran was an early example of
> this which showed that modern Fortran could be useful outside the core
> numerics domain. I'm also thinking of the https://fortran-lang.org
> site and associated efforts like the 'stdlib', a more fleshed out
> 'standard' library (https://stdlib.fortran-lang.org/ ), and the
> package manager FPM (https://fpm.fortran-lang.org ). Keeping in touch
> with these people, and suggesting that people help that effort if they
> aren't comfortable with hacking on the compiler outright, could be a
> way of growing the open source Fortran programmer base, which could
> eventually grow into contributors to the compiler itself? In
> particular if they want to use some newfangled Fortran feature that
> doesn't work in GFortran; scratching your own itch is always a good
> motivator!
> 

Hi Janne, great to hear from you and thanks for mentioning the efforts 
of others.

Best regards,

Jerry

Re: Team Collaboration Considerations

[NightStrike]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Tue, Dec 13, 2022, 03:10 Janne Blomqvist via Fortran <fortran@gcc.gnu.org>
wrote:

> But in general, yes, I do think IRC is showing its age in an
> increasingly multi-device and mobile world.
>

Tools like irccloud help here. I guess that doesn't qualify as open source
though.

>

Re: Team Collaboration Considerations

[Benson Muite]

On 12/26/22 13:19, NightStrike via Fortran wrote:
> On Tue, Dec 13, 2022, 03:10 Janne Blomqvist via Fortran <fortran@gcc.gnu.org>
> wrote:
> 
>> But in general, yes, I do think IRC is showing its age in an
>> increasingly multi-device and mobile world.
>>
> 
> Tools like irccloud help here. I guess that doesn't qualify as open source
> though.
> 
>>
Might a GSOC project examining community health be something that could
produce useful recommendations on improving developer efficiency and
getting new contributors?  The project can also produce a monitoring
system that fits the GCC workflow. A chat tool is helpful (Rust uses
Zulip https://gcc-rust.zulipchat.com), but it seems understanding how
the project develops and keeping track of relevant information are
greater obstacles.

The GCC workflows is quite different from other open source projects
being primarily email based and not using a bug tracker.  Email does
work well, and has been adapted in Sourcehut, but they have had to
introduce a tutorial:
https://git-send-email.io/

Re: Team Collaboration Considerations

[NightStrike]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran <fortran@gcc.gnu.org>
wrote:

> The GCC workflows is quite different from other open source projects
> being primarily email based and not using a bug tracker.
>

There's a bug tracker. I think you mean there isn't a patch tracker (or at
least not a system where you submit patches to a thing vs emailing them to
a list and hoping someone replies).

>

Re: Team Collaboration Considerations

[Toon Moene]

On 1/19/23 13:28, NightStrike via Fortran wrote:

> On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran <fortran@gcc.gnu.org>
> wrote:
> 
>> The GCC workflows is quite different from other open source projects
>> being primarily email based and not using a bug tracker.
>>
> 
> There's a bug tracker. I think you mean there isn't a patch tracker (or at
> least not a system where you submit patches to a thing vs emailing them to
> a list and hoping someone replies).
Well, you can put patches into Bugzilla ...

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: Team Collaboration Considerations

[NightStrike]

On Thu, Jan 19, 2023 at 7:46 AM Toon Moene <toon@moene.org> wrote:
>
> On 1/19/23 13:28, NightStrike via Fortran wrote:
>
> > On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran <fortran@gcc.gnu.org>
> > wrote:
> >
> >> The GCC workflows is quite different from other open source projects
> >> being primarily email based and not using a bug tracker.
> >>
> >
> > There's a bug tracker. I think you mean there isn't a patch tracker (or at
> > least not a system where you submit patches to a thing vs emailing them to
> > a list and hoping someone replies).
> Well, you can put patches into Bugzilla ...

You can, and people naturally do this, and I think it's great, but
there's usually a response from someone saying "post that to the
mailing list instead".

Re: Team Collaboration Considerations

[Bernhard Reutner-Fischer]

On 19 January 2023 13:52:55 CET, NightStrike via Fortran <fortran@gcc.gnu.org> wrote:

>You can, and people naturally do this, and I think it's great, but
>there's usually a response from someone saying "post that to the
>mailing list instead".

The mailing list has a 20-30 year history with reasoning about what currently is in the tree. I do think it is valuable to reason about patches publically for others to see. And I'm aware that this might not be regarded fancy nowadays by everyone.

But that does not mean that using other means to collaborate should not be used by some. Be it comp.lang.fortran, a webchat.oftc, or other means, that's all fine of course.

patches currently are handled differently, but I don't think that is a problem isn't it.
Just post final patches to the list as long as that is regarded the way to do final review and document approval.

cheers,

Re: Team Collaboration Considerations

[NightStrike]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
wrote:

> On 19 January 2023 13:52:55 CET, NightStrike via Fortran <
> fortran@gcc.gnu.org> wrote:
>
> >You can, and people naturally do this, and I think it's great, but
> >there's usually a response from someone saying "post that to the
> >mailing list instead".
>
> The mailing list has a 20-30 year history with reasoning about what
> currently is in the tree. I do think it is valuable to reason about patches
> publically for others to see. And I'm aware that this might not be regarded
> fancy nowadays by everyone.
>
> But that does not mean that using other means to collaborate should not be
> used by some. Be it comp.lang.fortran, a webchat.oftc, or other means,
> that's all fine of course.
>
> patches currently are handled differently, but I don't think that is a
> problem isn't it.
> Just post final patches to the list as long as that is regarded the way to
> do final review and document approval.
>
> cheers,
>

The problem is that patch tracking is unsustainable. You could go the other
way and have a patch tracker automatically echo messages to the mailing
list.

>

Re: Team Collaboration Considerations

[Bernhard Reutner-Fischer]

On 19 January 2023 20:03:38 CET, NightStrike <nightstrike@gmail.com> wrote:

>The problem is that patch tracking is unsustainable. You could go the other
>way and have a patch tracker automatically echo messages to the mailing
>list.

Currently it's the other way round. Patchwork collects the patches sent to the list. Everybody is free to administrate her patches in Patchwork iff that is desired.

Or do the same but through bugzilla.

I am aware that all this might not be the way you envision things to work, of course.

Re: Team Collaboration Considerations

[Benson Muite]

On 1/19/23 22:03, NightStrike wrote:
> 
> 
> On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer
> <rep.dot.nop@gmail.com <mailto:rep.dot.nop@gmail.com>> wrote:
> 
>     On 19 January 2023 13:52:55 CET, NightStrike via Fortran
>     <fortran@gcc.gnu.org <mailto:fortran@gcc.gnu.org>> wrote:
> 
>     >You can, and people naturally do this, and I think it's great, but
>     >there's usually a response from someone saying "post that to the
>     >mailing list instead".
> 
>     The mailing list has a 20-30 year history with reasoning about what
>     currently is in the tree. I do think it is valuable to reason about
>     patches publically for others to see. And I'm aware that this might
>     not be regarded fancy nowadays by everyone.
> 
>     But that does not mean that using other means to collaborate should
>     not be used by some. Be it comp.lang.fortran, a webchat.oftc, or
>     other means, that's all fine of course.
> 
>     patches currently are handled differently, but I don't think that is
>     a problem isn't it.
>     Just post final patches to the list as long as that is regarded the
>     way to do final review and document approval.
> 
>     cheers,
> 
> 
> The problem is that patch tracking is unsustainable. You could go the
> other way and have a patch tracker automatically echo messages to the
> mailing list.
> 
Review is done voluntarily and by email.  The process has flexibility to
increase productivity but it may make it harder to get involved.  Email
threads and metadata make it possible to track patches. It is expected,
but not enforced, that posts to the mailing list follow convention.
Until a comment on a patch is posted, it is unclear if it will be
reviewed.  Build results are tracked separately and builds done when
needed.  An  open review process is good. Do all patches get timely
reviews?  Can this process be improved?

An analysis of a developer community:
https://carlschwan.eu/2021/04/29/health-of-the-kde-community/

Some tools:
https://chaoss.github.io/grimoirelab/
https://framagit.org/ervin/ComDaAn
https://github.com/gotec/git2net

Will try some of these to analyze GCC, though something new maybe needed
since the workflow is quite different.

Re: Team Collaboration Considerations

[Jerry D]

On 1/19/23 10:21 PM, Benson Muite via Fortran wrote:
> On 1/19/23 22:03, NightStrike wrote:
>>
>>
>> On Thu, Jan 19, 2023, 13:33 Bernhard Reutner-Fischer
>> <rep.dot.nop@gmail.com <mailto:rep.dot.nop@gmail.com>> wrote:
>>
>>      On 19 January 2023 13:52:55 CET, NightStrike via Fortran
>>      <fortran@gcc.gnu.org <mailto:fortran@gcc.gnu.org>> wrote:
>>
>>      >You can, and people naturally do this, and I think it's great, but
>>      >there's usually a response from someone saying "post that to the
>>      >mailing list instead".
>>
>>      The mailing list has a 20-30 year history with reasoning about what
>>      currently is in the tree. I do think it is valuable to reason about
>>      patches publically for others to see. And I'm aware that this might
>>      not be regarded fancy nowadays by everyone.
>>
>>      But that does not mean that using other means to collaborate should
>>      not be used by some. Be it comp.lang.fortran, a webchat.oftc, or
>>      other means, that's all fine of course.
>>
>>      patches currently are handled differently, but I don't think that is
>>      a problem isn't it.
>>      Just post final patches to the list as long as that is regarded the
>>      way to do final review and document approval.
>>
>>      cheers,
>>
>>
>> The problem is that patch tracking is unsustainable. You could go the
>> other way and have a patch tracker automatically echo messages to the
>> mailing list.
>>
> Review is done voluntarily and by email.  The process has flexibility to
> increase productivity but it may make it harder to get involved.  Email
> threads and metadata make it possible to track patches. It is expected,
> but not enforced, that posts to the mailing list follow convention.
> Until a comment on a patch is posted, it is unclear if it will be
> reviewed.  Build results are tracked separately and builds done when
> needed.  An  open review process is good. Do all patches get timely
> reviews?  Can this process be improved?
> 
> An analysis of a developer community:
> https://carlschwan.eu/2021/04/29/health-of-the-kde-community/
> 
> Some tools:
> https://chaoss.github.io/grimoirelab/
> https://framagit.org/ervin/ComDaAn
> https://github.com/gotec/git2net
> 
> Will try some of these to analyze GCC, though something new maybe needed
> since the workflow is quite different.

What I am envisioning as a workflow is to retain posting to the gfortran 
list for approvals to commit. At this stage patches are refined and 
tested already by the developer and therefore have the most value for 
the public and people wanting to learn.

Mattermost would be used for internal discussions and collaboration. 
People can post questions and examples back and forth quickly by phone, 
or web browser or desktop app interfaces. This can be done in real-time 
much better than email. Email certainly is a necessary component as a 
formal review process.

Regarding patches and such. Mattermost supports "boards" which are 
actually modeled after Kanban, a very well established methodolgy. See 
https://en.wikipedia.org/wiki/Kanban.

It allows one to see at a glance where things are at.  Individuals can 
chat with each other privately and we can also set up specific channels.

For example, I have set up for the gfortran workspace the following 
channels:

	Finalization
	Gfortran Development
	Gfortran Front End
	Gfortran Help
	Gtk-Fortran Development
	Gtk-Fortran Help
	Native Gfortran Coarrays
	Town Square - for anythin

There is nothing sacred about these, they are simply things I thought of 
during initial setup. Thes can evolve as developers determine and learn 
this tool. The point is, the channels are focus points.

I have a board where I am tracking bugs we know have patches submitted 
in bugzilla that need to get tested and committed.  So, this tool does 
not replace bugzilla either. It is a tool for us to visualize where we 
are, Work In Process.

We can create a board to track patches if we choose. In a sense, I am 
doing that already.

By the way, anyone who wishes to get on the team, send me an email. We 
will keep evolving this tool as we go.

Cheers,

Jerry

Team Collaboration Considerations

[Harald Anlauf]

Hi Jerry, all,

as already said, the basic issue appears to be the low number
of contributors, most (all?) of which are working on gfortran
in their spare time (like me).  I think it is not likely that
they will commit to being available regularly.

I have used IRC once for a discussion that was really helpful
for me, but we agreed in advance to meet there, and this was
how it worked.  Other tools may work similar or even better.
(The ML was just not appropriate for the type of discussion.)

A collaboration tool could be helpful for introducing newcomers,
for giving advice in trying to understand how the code works,
and maybe when it doesn't.  Caveat: in many respects I still
feel as close to being a newcomer.

Though I could give a very basic introduction to working with
git, also in the context of gcc, if that is needed... ;-)
(Perhaps using git even is more fun than programming in C :-)

Personally, many things work fine for me using bugzilla and
the mailing list.  I just don't expect immediate replies
because of the current situation.

So can we get the attention of new possible contributors?
Or increase the activity of some of those who've been
contributing in the past?  So that a critical mass is
reached for a modern collaboration tool to be useful?

Cheers,
Harald