[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
Christoph,
Your last sentence is not actually helpful and not so nice.
Folks who have been active for years or decades knew exactly what
to do and how to do it. With a new and different-though-better
way that's suddenly not true anymore, and that tends to make the
old way seem better than the new better way. So when someone who
doesn't know all the details of the new (and better) way asks a
question that has an obvious answer---obvious to you but not to
them or they wouldn't ask it---simply answer it without value
judgement. Stephan's record of contribution to Eclipse speaks
for itself:
https://www.eclipse.org/org/foundation/eclipseawards/winners_lifetime.php
Stephan,
Yes, it's easy to contribute to a *.md via a browser without
needing to clone the repo. You can preview it to see if it looks
as expected and then you can create a PR easily. It's not so
substantially different from a wiki...
Yes, the culture is different. Many more folks are involved who
know the "git way" and to them everything is obvious, intuitive,
and self-evident. You often have to explain to them, "assume that
I am stupid and know nothing" when asking a question because often
the answer won't fully explain what you need to know, so you keep
having to clarify the question to get a clearer answer. This is
not because of any ill intent, it's because it's easy to forget
what's obvious and what's not. E.g., you might want to know how
to do some git thing, implicitly meaning in the IDE with EGit, but
the answer will be how to do it with the git command line...
I asked months ago about guidelines for how best to maintain a
fork and how to push to it in order to create a PR and such. I
was told that no one really wants to spend time writing such
documentation because it's kind of pointless given there is plenty
of documentation on the internet how to do things like that. That
may well be true, but I couldn't find it and it seems there are
multiple different ways...
E.g., one is often told to create a fork, and to clone that fork,
as you see in the CONTRIBUTING.md. Then you should create a
"feature" branch (never commit to master/main) and push to that
branch. Creating the pull request requires visiting the browser.
But I don't like that way because to keep your fork's master/main
up to date you also need to visit the browser, and in my SDK setup
with dozens of clones, that way too painful. So I prefer
to clone the original and to create an additional remote for my
fork (if and when I need one) and then push the branch
specifically to that remote. Then I can easily switch back to
master and pull from the original repo, never needing to keep my
fork master/main up-to-date. This highlights is another problem
with such guidelines; does everyone agree on the best way and in
the end, does it matter which way folks do it. For this case, I
suppose not, but for a contribute-and-review process there are two
parties involved, so setting expectations up front seems quite
important.
Regards,
Ed
On 11.09.2022 16:31, Christoph Läubrich
wrote:
If
you open that page in a browser there is a tiny icon with a pencil
on it labeled "edit this file" ...
But let me guess this leads to the question on how do I open a
browser ... so as each answer leads to a new question it seems it
is impossible to contribute via github, compared to
bugziilla/gerrit where everything was immediately clear ;-)
Am 11.09.22 um 15:38 schrieb Stephan Herrmann:
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
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
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, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...