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....@gmail.com <mailto:rep.dot....@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
