[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
Hi Zsombor,
These are valuable comments, from a persons directly affected.
Perhaps the discussion got derailed because people saw "rules" ("thou shalt do
X") and were quick to reject anything limiting their freedom.
What you mention concerns the pursuit of helpful information ("how can I do
Y?"), which doesn't require us to agree on any discipline.
Both kinds of discussions _could_ converge into a shared, living document "how
do we do Z?". And that document should be posted right on the front door to JDT.
I should admit that I, too, bot derailed because I was always looking at the
front door of JDT/Core, without bothering to look up one level:
https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md (Thanks Ed for
reminding us). That document looks like a good start.
When I joined JDT the FAQ I mentioned before served as that shared document. I
saw several committers joining the team (incl. myself), who had new questions,
and once the information was collected, the newbie would first propose additions
to that document, later they would directly edit the document.
I don't currently see this happening as a group effort. I'm not even sure, if
this is due to the move from a legacy wiki page to a GitHub CONTRIBUTING page
(is that what is happening?), or if the culture of this group has changed
fundamentally.
And here's the meta question: how does one contribute to CONTRIBUTING.md? :):):)
Is a PR needed for that?
best,
Stephan
Am 11.09.22 um 13:31 schrieb Zsombor Gegesy:
As one, who just started contributing a year ago, I could share my experience,
that the barrier for contributions are extremely high, due to lack of documentation.
I mean, other open source project generally have some sort of
documentation/tutorials, especially if they are doing some non-conventional things.
With lot of wasted hours of reading forums, year old blog posts, tuning google
search, and trial-and-error, I could collect that information, but I'm still not
sure, if there are simpler way to do this - I guess so, because every couple of
months my environment gone haywire, so I need to start from scratch. As a
wanna-be-contributor, I would expect:
* how to get the source code, and how to setup my IDE? Originally, I tried to
simply 'git clone ...' a couple of repos, and import into Eclipse, but it wasn't
successful. Later found, that I need to use an 'advanced tab of 'Oomph' tool to
install a separate IDE, which will also do the git checkout. (Of course, if that
git operation times out, than you have to start from scratch)
* how to start the project from the IDE? The launcher config is very
complicated, and it take a lot of trial and error until I figured out, what
projects should I close, what needs to be open, and certain errors reported at
startup is just there.
* how to build your changes into a working, shareable software, which can be
used in other machines / by other people? Finally, I found, that I need to
checkout the 'releng.aggregator' project, adjust the submodules, and after an
hour of build, I will get the necessary binaries, that can be used in other
installations.
Compared to these problems, for me it's feels minor thing, that if/when to
rebase/squash/etc, but your mileage may vary.
Zsombor
On Sun, 11 Sept 2022 at 11:22, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx
<mailto:gunnar@xxxxxxxxxxxxxxx>> wrote:
> On Sep 11, 2022, at 07:20, Christoph Läubrich <laeubi@xxxxxxxxxxxxxx
<mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
>
> Just one question:
>
> Are there *that* many contributions to JDT that one really can reject a
valuable contribution just because the person uses (or dont uses) force
push? Just a thought...
On the flip side, contributions are pointless if the subject matter expert
is not able to review them because they require additional work to process.
Thus, I think it's a matter of cooperation on being respectful.
You can't optimize workflows for contributions only when the cost implies
dumping more work or requiring more time from committers/smes. In the case
of JDT, especially the compiler internals needs very careful reviews from a
subject matter expert. This might be different in other areas of JDT (eg JDT
UI). Thus, having those conventions or rules documented upfront for the
community (including some information were they apply or not apply) is not a
bad thing. You will be surprised of how open contributors can be when things
are communicated upfront.
-Gunnar
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
<https://www.eclipse.org/mailman/listinfo/jdt-dev>
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
- References:
- [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- From: Jayaprakash Arthanareeswaran
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- From: Jayaprakash Arthanareeswaran
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...