> First thank you for the answers to my questions.
>
> if there is no manager assigned for the GCC development I would like to
> take the part of the project manager for GCC. The aim is to coordinate,
> structure and speed up the GCC development.
>
> I would like to structure the development, possibly find new developers
> who want to join, assign task to finish GCC 10, enhance library support
> and improve public exposure. The aim is to have a GCC developer team.
Hi Stefan,
Thanks for some thought provoking comments. I think it might be helpful to
think about what it is we're lacking and what we could do better.
First of all, I should start by saying I'm not speaking for anyone but
myself, and at the end of the day I'm happy to be led by what others think
is best. If changing the way we do things is useful and makes people more
productive, then I'm all in favour.
One thing that makes open source different from commercial development is
that, unless contributors are being employed to work on the project, they
are doing it for nothing, because they feel motivated to do so. So any
attempt to tell people what to do stops the project being fun anymore and
they simply stop contributing. Hence the focus is on encouraging, enabling
and facilitating rather than 'project management' in the commercial sense.
At the moment there are few developers with even less time, so there isn't
much to manage at the moment. If new developers come on board then we can
help train them up which would improve progress, but we haven't had a
particularly large influx of them in the past. Maybe we did something
wrong, I don't know, or maybe they aren't out there. This area does, after
all, require a lot of technical background of both RISC OS, Unix, toolchains
and software development on other platforms - people with these skills and
interests are relatively rare.
It should be borne in mind that, while it would be great to produce lots of
material on bringing new people up to speed, we don't have the manpower for
that, so the problem is a little self-perpetuating (this is one reason I've
been pushing on Docker of late, to make things a bit less complicated to
pick up). New folks highlighting gaps in our documentation would help us
fill them.
But training can only go so far. There were a couple of messages to the
list this week that I can't answer, so they will have to wait until probably
the only person who knows has time to have a look. And, on some queries,
given that some of the people who developed things are no longer active,
maybe actually nobody knows.
> I think that GCC is one of the most important applications for RISC OS as
> it is the main tool to port open source application to RISC OS. It is
> also the only C++ compiler for RISC OS. So GCC is one of the most
> important tools for RISC OS and should not be neglected by the RISC OS
> community.
It is also worth saying that in the past there's been a considerable 'not
invented here' response from the RISC OS community (notably on packaging,
but also on shared libraries, ELF, and using GCC over Norcroft), and this
pushback is not conducive to maintaining developer motivation (even today on
the ROOL forum there are some quite strong voices in this area). In
particular, the ROOL source tree is very focused on Norcroft (for whatever
reasons) and so that has not helped better integration between tools.
> To accomplish this we need:
> 1. clarify the status of different parts of GCC 10
> 2. discover what needs to be finished
> 3. discover what is not implemented yet
> 4. discover what additional libraries or tools should be added
> 5. discuss alternative stragedies about sharedlibrary, unixlib etc.
> 6. decide what tools or infrastructure are needed ( for example Github,
> Redmine, forum etc.)
These are all sensible, but they rather assume people have time to work on
these things. If more dev time is available (by whatever means), or by
planning this it provides a bit more motivation for existing devs, that's
great. But again you can't manage without anyone to manage - progress won't
happen without people writing code.
> I don't see a mailing list as very effcient tool to discuss and find
> solutions as it is very unstructured. I propose to use my new developer
> forum www.riscosdevforum.com to discuss specific solutions or tasks.
Over the past year there have been about 130 messages to this mailing list.
It is not exactly busy - that's about a message every three days (but more
bursty than that). So I would question how moving medium is going to help?
Is there something email isn't doing for people that a forum would?
One thing that makes a good community is keeping people involved - email is
moderately good at that as messages get pushed to participants. It is less
good at handling volume - not a problem we have. Forums tend to be poor at
keeping people engaged unless they check them all the time (the ROOL forum
is a particularly poor example of one, and as a result I check it on average
every few weeks, because it doesn't notify you there's been recent activity
in areas you're interested in, like threads you've posted on, unless you
visit regularly). And adding another place to check just spreads
information and community more thinly.
Some projects have IRC/Slack/Discord/Mattermost/etc channels for more
realtime discussion - if that's something people want I'm sure we could set
something up.
I can understand discoverability of list postings isn't great
(Mailman+pipermail aren't the best archiving or searching tools) so if
somebody wants to set up another tool - eg the various list archiving sites
out there - I'm happy to provide them with the archives if they want to set
that up.
Bottom line is a question: are the current communication tools working, or
could we do them better in a different way? I'm open to ideas.
> But it might be helpful to have a zoom meeting as startup to know each
> other better and discuss openly what are the options or problems.
I have in the past suggested a RISC OS developer workshop, like the ones
I've previously helped run for FreeBSD devs in Cambridge, and not had a lot
of enthusiasm on the ROOL forum for that. However that would have been a
physical meeting in the Before Times, and now everyone has got used to Zoom
etc then it's easier.
A coordination zoom sounds like a good idea, if other folks are on board
with that?
> To save cost I can offer also my servers to host the current GCC content.
> This service I can offer at least for the next 10 years.
Cost for hosting the GCC content isn't so much of an issue, since the
machine is a build server as well as a web server and that needs a fairly
substantial server anyway. It is also a lot more than a static website (web
server + wiki + database + announcements 'forum' + email notifications +
mailing list server + archives + bugzilla + SVN server + CI server), which
are all tightly bound together due to the way it was initially set up. (I
have tried to untease them all into separate containers, but it's too
complicated)
I am trying to move pieces away from a single point of failure (eg migrate
SVN to git, since RISC OS folks seem to be comfortable with that now) to
encourage greater resilience. Moving to git would help some of the workflow
issues we have (eg allow pull requests and code reviews, etc).
Unfortunately the SVN repo is not straightforward to properly convert to git
due to the peculiar way branches were implemented - help here would be
appreciated.
> Please let me know who is willing to join or if there are any objections.
> This is just a proposal and open for discussion!
Perhaps you could tell us a bit more about how you would get new developers
involved, or help existing devs find time, as I think that is the main issue
at the moment?
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment