> Given the plethora of repositories that comprise
> the Eclipse SDK
Even though it was considered "not important" I always has suggested to
actually merge related stuff into one repository, this splitting across
different repos is just a pain, and we should not blame the tools for
not supporting it well enough but think that obviously things belong
together.
This has always been a pain. We used to have even more repositories. There are plans/hopes to merge a few of them but there are some limiting factors like speed of execution of tests that make verification builds too slow if we merge too much and etc. This shouldn't sound like an excuse - it's just the current state of affairs. Not many people find it interesting to work on these things thus progress on them is even slower. Either way,
Thomas wants to merge equinox.framework and equinox.bundles repositories once Github migration is done, but it hasn't been done at the same time as we didn't want to prolong the migration for even longer with such changes. PDE definitely should become a single repo. Platform is up for consideration too.
Please bear with us while we try to improve the contributor workflow with the limited time we have. And keep asking each step and requirement as only that way we will figure what is really needed and brings benefit and what is done just because we are used to it without any real gain.
Anyways, if one like he can reference other repositories or issues as
well, github will detect links or shortcode like
eclipse/<somerepository>#1234
Am 22.03.22 um 13:15 schrieb Ed Merks:
> Wim,
>
> Note though my comment about a commit related to an issue from a
> different repository. Given the plethora of repositories that comprise
> the Eclipse SDK, that seems not at all unlikely to happen, is it? Or
> should that be forbidden? Or should we not have rules at all? We do
> seem to have several proposed workflows but not really general agreement
> on what should or shouldn't be done nor how it should be done...
>
> Regards,
> Ed
>
> On 22.03.2022 13:00, Wim Jongman wrote:
>> Ed, in time EGit will probably learn how to interpret GitHub-related
>> content as it can now do for Bugzilla. For issues spanning
>> repositories, it would indeed be needed to include a link.
>>
>> Cheers, Wim
>>
>> On Tue, 22 Mar 2022 at 11:05, Ed Merks <ed.merks@xxxxxxxxx> wrote:
>>
>> Wim,
>>
>> Comments below.
>>
>> On 22.03.2022 10:46, Wim Jongman wrote:
>>> In BIRT, Windowbuilder, and Nebula we successfully use the
>>> following workflow:
>>>
>>> 1. Fork the main repo
>>> 2. Create an issue in the main repo e.g. "My Issue" #1 (#1 being
>>> the next ID)
>>> 3. Make changes in a branch in your fork (not in master/main)!!!
>>> 4. Commit with "My Issue #1"(include #1)
>>>
>> A few "concerns" here. This approach does look good in the github
>> views, but the issue URI is implicit. That works well (on the
>> github site) when the issue is open in the same repo as the
>> commit, but I expect in the long term, there may well be commits
>> for a single issue across multiple repos. Also, EGit knows
>> nothing about such implicit links so will not show such links in
>> the UI.
>>
>> It's also possible to include the full issue link like this such
>> that even in EGit, you can see an issue link that you can follow
>> to the github site:
>>
>> This looks like this in the github pages:
>>
>> Note how the long issue link is displayed as #2 here. Also note
>> that the #3 is a link to the PR while #2 is a link to the issue.
>> So here the implicit URI is different depending on the location of
>> the #<fragment>. I'm not sure how EGit might create/display such
>> links in the future...
>>
>> So perhaps it's worth considering including the full link to the
>> issue in the body of the commit message?
>>
>> Just a thought...
>>
>>> 1. Go to GitHub in the main repo. GH offers to create a PR
>>> 2. Use "My Issue #1" as the topic. The PR will be called "My
>>> Issue #1" #2
>>> 3. Start Review
>>> 4. Keep committing on your fork branch
>>> 5. PR is accepted
>>> 6. Go to your fork and "Fetch upstream" [1]
>>>
>>>
>> Yes, this is a PITA. :-( It's hard to keep something like the
>> following up-to-date if you *also *have to go off into github and
>> manually fetch each fork (if you have one) before Select All and
>> to a Pull.
>>
>> I wondered if there were some way to make this easier with
>> multiple configured remotes, but I don't understand that approach
>> well enough
>>
>>> [1] Fetching upstream is currently a pain. I have started a
>>> discussion here. Please also comment or upvote:
>>> https://github.com/github/feedback/discussions/13221
>>>
>>> Cheers,
>>>
>>> Wim
>>>
>>> _______________________________________________
>>> platform-dev mailing list
>>> platform-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev
>> _______________________________________________
>> platform-dev mailing list
>> platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/platform-dev
>>
>>
>> _______________________________________________
>> platform-dev mailing list
>> platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/platform-dev
>
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
