[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
|
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...
Regarding search:
https://docs.github.com/en/issues/tracking-your-work-with-issues/filtering-and-searching-issues-and-pull-requests
Am 11.09.22 um 00:51 schrieb Stephan Herrmann:
Let me throw in another detail of what the old FAQ contained: "tags"
which classify bugs (e.g., [1.8], [null]...). Apparently this can be
encoded as Labels in GitHub. Maybe everybody can just make up their own
labels (at least committers seem to have the permission). But that's
quite beside the point:
In bugzilla I have used these tags *extensively* to search for bugs
touching specific aspects. If there is no system behind tagging, this
information is lost, and searching bugs, er, issues will soon become a
nightmare. Don't be fooled by today's experience of few hundreds of
issues in JDT. Our system must empower developers to leverage the
information in tens of thousands of issues.
As Jay picked up the topic of force push: when committers do reviews for
contributors, let's say I will accept changes only as individual
commits, whereas some other committer is happy with a series of
force-pushs. Now each time a contributor works with a different
committer, they have to ask up-front, in which style they should make
their changes. Possible, sure, but isn't that more friction than a few
clear-cut rules? And force-push is only one example.
Do other committers have an opinion?
best,
Stephan
Am 10.09.22 um 23:43 schrieb Jayaprakash Arthanareeswaran:
Well, in a perfect world, where everyone is contributing in a vacuum,
I guess we all can do whatever workflow
that suits us. But in a project where people work with one another,
some sort of guideline or recommendation
is always good for a smooth functioning of the project. For e.g,
Stephan’s concern of force-pushing a branch by
a contributor. In this case, it’s better if the contributors follow a
certain way so that it helps the reviewer do his job comfortably. In
other words, what’s good enough for someone may not cut it for someone
else.
Having said that, we don’t want to restrict someone to the point of
affecting their productivity. We don’t want to be unreasonable here.
But at the same time, I am pretty sure there are newbies and some
seasoned contributors that would like some sort of recommendation. I
don’t see this affecting the level of contribution at all. FWIW, I
don’t see any noticeable difference in new contributions after moving
to GitHub.
And I like the idea of having one for all the JDT projects. That
should be the way forward.
Regards,
Jay
*From:*jdt-dev <jdt-dev-bounces@xxxxxxxxxxx> *On Behalf Of *Mickael
Istria
*Sent:* 10 September 2022 19:11
*To:* Eclipse JDT general developers list. <jdt-dev@xxxxxxxxxxx>
*Subject:* [EXTERNAL] Re: [jdt-dev] Telling GitHub to rebuild, rebase,
...
Hello, On Sat, Sep 10, 2022 at 1: 22 PM Stephan Herrmann <stephan.
herrmann@ berlin. de> wrote: From incoming answers I seem to
understand that everybody knows something but there's no clear
consensus of what should be done when. I could
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hello,
On Sat, Sep 10, 2022 at 1:22 PM Stephan Herrmann
<stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>> wrote:
From incoming answers I seem to understand that everybody knows
something but
there's no clear consensus of what should be done when. I could
see a tendency
that Eclipse doesn't care, *how* GitHub is used, since everybody
can just
search
the net for how others are using it.
I believe that is true, but I don't see it as an issue.
Developers have tailored workflows that fit their preferences, their
experience, their habits... Those workflows are built according to
documentation, experience or other sources of knowledge that are
rather personal, so it's not surprising that different people have
different workflows, it's a form of diversity in action. And all those
workflows may even be the best ones in their context.
IMO, projects can and should embrace these diverse workflows as long
as all those workflows do lead to "good enough" quality. Projects
should specify the actual constraints on the resulting contribution,
not the way contributions are made.
But indeed, it can be useful to have some of those workflows
documented somewhere for "educative" purposes.
If, however, JDT still prefers a coordinated, somewhat uniform
approach, I'd
suggest: let's first agree on *where* the results of this
discussion should be
captured (I regard a mailing list as the least suitable option for
this).
As mentioned, I don't think the project should aim at preferring 1
uniform approach when there are multiple working approaches. That
would be adding constraints on some contributors without clear benefit
for them nor for the project. If those constraints happen to make some
developers less productive than usual, they'll be less likely to
contribute.
So project may promote 1 or several workflows, but not enforce or
require a particular one if some others are working as well for some
people.
Should we maintain jdt.core's CONTRIBUTING.md accordingly? Should
we coordinate
and push this into the next level (JDT)?
The CONTRIBUTING.md file is indeed where such guidance would fit best,
adding a section with tips for typical review operations.
You may like to remove the CONTRIBUTING.md from eclipse.jdt.core and
eclipse.jdt.ui GitHub repo and instead enrich the common one that is
located at
https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md
<https://github.com/eclipse-jdt/.github/blob/main/CONTRIBUTING.md>
_______________________________________________
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, ...