[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] Has the time come?
|
> Though, it could be sufficient to write a decent manual that
> describes the way of working within the Eclipse eco-system
Developers tend to not being very attracted by reading long manuals.
Also these manuals tend to degrade over time as slight variants or
adjustments are not updated. M2E is a recent example of this where it
seems hard to setup an IDE from the manual as it seems to be outdated
and/or some details have changed.
I think I recently read about that's it is possible to have a "button"
in a html page that links to an Oomph setup file and simply creates the
IDE+checkouts and so on. I think that should be the very first thing any
project that wishes to attract developers should setup.
> From an external perspective, the project seems outdated and dying.
> For instance, many of the website pages and wiki pages contain
> outdated content
Github-pages would be a nice feature to use to manage the web-page with
the code, one could even require for PRs that there are corresponding
documentation changes. The same applies to the wiki. Github even
recently introduced a "discussion" feature that could serve as an
alternative to the forums/mailing-lists.
> Eclipse RCP/IDE is not the cool-thing (anymore), it is old technology.
And the contribution workflow is one of the "not so cool things", if
people can edit code, documentation, wiki ask questions and open issues
with just one user-account that might already exits under one UI (no
eclipse-git, eclipse gerrit- eclipse whatever each require to login
separately with different UIs) this could make people more attracted to
contribute even to 'old' RCP/IDE.
Am 18.03.21 um 09:30 schrieb Rolf Theunissen:
Slightly late comment on the goal.
The goal is to facilitate contributors and get more contributions. I
guess that we can agree on the goal.
Then you can start thinking about how to reach that goal, and moving to
GitHub could be an option and part of the solution. Though, it could be
sufficient to write a decent manual that describes the way of working
within the Eclipse eco-system, targeted at people who are used to the
GitHub workflow. I.e. write down the steps in the workflow and for each
set make the relation to the GitHub workflow. Surely there are some
things in the workflow that can be optimized, but those can be changed
regardless of a move. But also keep in mind the possible drawbacks of
the move, not only the effort of the move, but also the dependence on
the policies of an external company. Do you really want to depend on the
free services of an external company, or does the project want a proper
SLA (paid or free) with real guarantees?
Also, there is no free lunch nor a silver bullet, just moving to GitHub
will not gain (m)any contributors. People will not get magically more
involved in the project, for that the community should be nurtured.
Personally I think that the following topics have a bigger impact than
'just' the way how patches are submitted, many people will not even
reach the point of submitting code:
* Eclipse RCP/IDE is not the cool-thing (anymore), it is old technology.
How to market Eclipse as a cool thing? What makes it special? How make
people proud to have contributed to Eclipse?
* Having hassle free setup of the development environment. I think that
the functionality provided by Oomph is a game changer here: no lengthy
complex description of setting up the environment, just a few clicks and
within minutes you are ready to start coding on a patch. (And
Signed-off-by is automatically enabled). It would be really nice that
the full submit/review cycle would be supported from within Eclipse so
you never need to switch to other tools.
* From an external perspective, the project seems outdated and dying.
For instance, many of the website pages and wiki pages contain outdated
content (e.g. https://www.eclipse.org/eclipse/development/
<https://www.eclipse.org/eclipse/development/> next release is 4.9?),
are incomplete, describe long gone processes (bug triage process?), etc.
* Total ignorance of the communication channels to the community. There
are hardly any experts active on the Eclipse forum pages. Even straight
forward questions get hardly any answer, let alone the more complex ones.
* Total ignorance on bugs submitted by the community, e.g.
https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&list_id=20462834&namedcmd=Platform%20-%20External%20no-comments
<https://bugs.eclipse.org/bugs/buglist.cgi?cmdtype=runnamed&list_id=20462834&namedcmd=Platform%20-%20External%20no-comments>
* And even if people reach to point of submitting code: The backlog of
reviews on submitted issues in Gerrit
For me, moving to GitHub would not have priory. Why burn resources on
that if there aren't even resources available to properly facility and
support the community? But who am I, never earned any penny with my work
on Eclipse, I can freely spend my spare time on any topic I like,
without being hindered by any companies policies/expectations.
Best Regards, Rolf
Op di 16 mrt. 2021 om 13:25 schreef Mickael Istria <mistria@xxxxxxxxxx
<mailto:mistria@xxxxxxxxxx>>:
The goal is not just to change tools for the sake of changing tools,
as there is a relative consensus that the current tools we have (BZ
and Gerrit) are pleasant enough to work with.
The goal is to facilitate contributions and get more contributors,
this is one of the key factors the sustainability of any OSS
project. So it's not really about GitLab vs GitHub; it's more about
exposing code and contribution process on whatever.eclipse.org
<http://whatever.eclipse.org> vs GitHub. GitHub is the platform
where most of OSS projects and contributors are, and that's not a
temporary thing now, it's been so for many years and has only grown
in size and quality. It's global, bigger than eclipse.org
<http://eclipse.org> has ever and will ever be, and it's now the
main driver of OSS development practices (contributor agreement and
license check bots are basically providing a good enough
plug-and-play governance). IMO, the real question is not really
about whether to move some process to GitHub, as it will sooner or
later be a requirement for project sustainability; it's more about
how and when to move code and processes GitHub.
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
<https://www.eclipse.org/mailman/listinfo/platform-dev>
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
