Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] Telling GitHub to rebuild, rebase, ...
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

Back to the top