[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
Christoph,
What you say here is a perfect example of what I mean. It's just so
absolutely self evident (to you) that one should be able to edit the
file via web page in a browser that a question about how to change the
contributing file is assumed to be a joke. But it's not. One couldn't
edit a file via git.eclipse.org so why must it necessarily occur to
someone (other than someone who is a complete idiot) that it is possible
to do this with github. It's a cool feature and there are a great many
things about the github workflows that are cool, once you know about
them and understand them. So just be patient and answer questions with
a focus on creating a positive environment; assume lack of knowledge as
the reason for "stupid" questions and "contradictory" statements and
seek to enlighten...
If it sounds like I need to climb down off of my high horse, let me do
so now. See this as example where I'm far from perfect and I need too
need to apologize for being unhelpful not nice:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/732#note_1013206
On 12.09.2022 10:11, Christoph Läubrich wrote:
Ed,
Entering "github edit file" into a famous web search engine has the
first hit at:
https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files
it gives an exhaustive documentation (as with most github stuff)
explaining all the details for anyone who really wants to know these.
So I can only assume that this "meta-question" was not a real question
but more a "joke" so if one should not expect a real "helpful" answer,
but in the context of the thread where each answer given (by me and
others) always reveals new 'contradiction' it is just a logical
consequence.
And yes, things are changing, if it is "better" is not me to decide,
it is just different ... and as Mickael mentioned we should simply be
open to other workflows than hunting for "the one and only" that is
always only a snapshot of our current understanding and best-practice
changes every day.
So if there is a real problem to solve, we should solve it, if it is
just because it was different in the past it might be better to accept
that things are changing over time and make the best out of it.
Am 12.09.22 um 09:48 schrieb Ed Merks:
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
_______________________________________________
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, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
- Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...