Am 18.08.25 um 01:45 schrieb Atiq Rahman:
> OpenIndiana we have a very simple process using github
Enabling github issues on https://github.com/OpenIndiana/oi-userland
will help the simplicity
Like Toomas answered for illumos-gate already, switching the issue
tracker for Openindiana from redmine to github won't change a lot (other
than more depend on Microsoft). Our issue tracker is filled but only
rarely someone is working on reported issues. So adding another
/dev/null device won't change the most pressing problems of OI.
As I have written several times already: we lack maintainers. Depending
on how one counts them we only have approximately 3 to 15 active
maintainers. Most of them are focussed on a single or few areas of
interest. So we have a lot of packages that are problematic for one
reason or another without someone willing to fix them.
It won't help to get more reports on problems without people working on
fixing them.
I recently talked about packaging chromium with Geoff, our maintainer
for firefox, thunderbird and libreoffice.
He told me that FreeBSD pays a high price for having it packaged; they
have more than 1000 patches to make it work on FreeBSD. Even after an
initial port the amount of work that would be needed to keep it updated
would exceed all our existing resources.
At the moment I merge PR's without issue tracker reports or links
because the number of PR's is so low and forcing people into a more
sophisticating process would even lower that small number.
Same for https://github.com/illumos/illumos-gate
On Sat, Aug 16, 2025 at 6:36 AM Andreas Wacknitz via oi-dev
<oi-dev@openindiana.org> wrote:
Am 16.08.25 um 15:09 schrieb Peter Tribble:
On Fri, Aug 15, 2025 at 11:12 PM Joshua M. Clulow via
illumos-developer <develo...@lists.illumos.org> wrote:
On Fri, 15 Aug 2025 at 14:56, Atiq Rahman <ati...@gmail.com>
wrote:
> Thanks to both of you.
You're welcome!
> May I suggest we move https://www.illumos.org/projects to
Github or GitLab?
> Old tools look daunting and will essentially alienate new
contributors. Potential contributors are mostly using
Github/Gitlab IMO.
It has certainly been considered in the past, but it really isn't
clear that merely changing to a different bug tracker or code
review
system is going to result in a significant wave of serious new
contributions.
The telling word there is "merely". It's not just about
substituting one piece
such as the bug tracker for another, it's about replacing the
whole workflow
wholesale.
And if you were to pitch contribution to a newly interested
person, which of
the following would be more likely to succeed?
1. Hi! Yeah, set up a completely new account over here. Fill in a
unique
bugtracker over there. Follow a non-standard set of processes to
create
a change. Interact with a mailing list, which may or may not get
back to
you. Interact again with our bugtracker. Once you've got that
far, interact
with a different mailing list, and if you're lucky your change
might get
committed.
or:
2. Hi! Yeah, just use the exact same process used for millions of
other
projects, on a system you've probably already using.
No contest, really. Our existing processes, systems, and workflow
impose
significant barriers to contribution, which might go some way to
explain
why we don't get any new contributors.
The heavyweight nature of our processes is also a major barrier that
discourages contributions by existing members of the community. If we
want illumos to improve, then barriers must be lowered.
The hurdle we actually have is that working on an operating
system is
itself often daunting. It's a large code base that has been
around
for a long time. It's not the kind of software that most
people work
on. There is a sort of implicit assumption, I guess, that
it's going
to be very difficult instead of merely a different kind of
work. This
isn't actually the case, of course: the kernel is just a big C
program! Anybody can learn enough to contribute, if they're
motivated.
I think if you're already keen to contribute, it's unlikely, on
balance, that the bug tracker is going to be the reason that you
don't.
It won't be *the* only reason, but along with other impediments,
it will
be *a* reason.
The problematic process you are referring to is for illumos-gate.
For OpenIndiana we have a very simple process using github. You
only need to clone our oi-userland repository to a local build
machine and can start right away. Nevertheless the number of OI
maintainers is very low and new contributors are rare.
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
