| Let's start with the first step, remove stale branches.
If you don’t need the merged branches, please remove them by yourself.
I’ll insert my five coins. As for me, pushing developer to use only fork is not a good way. As for me, it would be better to improve developing guidelines and provide the information about stale branches that left after PR merge.
In PR template add check box with the notice and link, that developer will carefully read and agree the rules provided in this guideline. Smth like it has been done in Theia repository:
<pr.png>
Then in developing guidelines provide information about that fact, if developer didn't remove the following branch, then we’d remove it manually/automatically/etc, for example after week or less.
To provide some insight into why there might be resistance to using personal forks (thanks to @Anatolii Bazko for this & to @Radim Hopp for the explanation)...
It seems some people might not be aware that personal forks' branches can be edited by multiple contributors.
There's a checkbox on PRs to allow "maintainers" to edit your PRs even if they're in private fork vs. origin repo.
(I learned this one when contributing to the CRW docs in gitlab too -- it was a new workflow for me a few months ago but the docs team regularly edits each others' MRs.)
So if your workflow involves collaborating on the same PR / pushing changes to someone's PR or topic branch, you can do that in a private branch too. It's only a small change to work outside the origin in your fork, which will keep the origin cleaner.
THAT BEING SAID, I personally have no problem with people using the origin for their topic branches, especially for collaborative work. I was not trying to stifle creativity, make contributing harder, or prevent peer programming.
My concern was simply that these temporary topic branches don't always get cleaned up once merged or abandoned, resulting in a "dirty" project.
It's a bit like if you make a coffee and leave your used mug (merged topic branch) on the counter for someone else to clean up, vs. loading it in the dishwasher when you're done (deleting it). :D
If we all have the diligence to take care of our shared spaces (branches in the origin) then there's no need to police that with GH rules or coded restrictions or administrators. We're all capable of doing our own housekeeping.
So... if we want to continue to use topic branches in the origin, that's fine -- but you're potentially creating work for others (team leads, architects) to clean up your leftovers, if you forget to clean up later.
Hope that clarifies the intent, impact, and workflow concerns with using origin branches vs. personal fork branches.
Nick Gennady it's it not like we were going to vote for the next president of a country ...
Here are the principles (getting inspirations from the Open Decision framework ... ): - Make this simple stupid - Open exchanged: in this thread and during the community call - Let the community to give a voice (survey) - From all the information we collect, the decision makers take a decision. Mario did. - "Fail fast" or "Release early, release often" -> we make that decision today but it doesn't mean this is the best. Let's give a try and see what happens.
Thanks
Sun Tan Senior Software Engineer Eclipse Che - CodeReady Workspaces @ Red Hat
Paris JUG leader
Red Hat Paris
@Anatolii Bazko if someone needs to work with someone else: talk to each other, fork, add user/permission. @Gennady Azarenkov it has been discussed during the last community call ... After 10 minutes debating, Mario, as project lead, asked for a survey/vote to decide what we do. @all at some point we need to move forward, let's do like this, we have more important issues to work on.
@Sun Tan I have nothing against the survey, I am asking whether this vote is legitimate and representative enough to take some action? Does that mean that result of ANY community survey with arbitrary worded questions (note: the initial request was some different) and ANY number of participants is taking as a "decision made" based on simply majority of voters? Do you follow some regulations defaulting this manner of decision making?
@Mario Loriedo ok I can take the action item.... first see if I have permissions to do that :) will keep you posted. Sun Tan Senior Software Engineer Eclipse Che - CodeReady Workspaces @ Red Hat
Paris JUG leader
Red Hat Paris
I am not sure I understand what the survey result means for us...
Does this survey have the power to change anything at all?
Hello.
Sorry, but I am strongly against that.
It will bring complications when several developers work on the same issue.
Ok so it looks like we need to change our github repositories configurations. Sun do you want to take the action item?
Hello, so here is the result of the survey:
Sun Tan Senior Software Engineer Eclipse Che - CodeReady Workspaces @ Red Hat
Paris JUG leader
Red Hat Paris
Sorry, I had not finished my "for example", but hope you've got the idea ;)
I don't want to force you to do anything, I want to understand
why you work that way. Maybe there is a cost to working in forks
which I'm not seeing. It's an honest question.
If we are talking about me: at some point, I've switched my preferences to work with forks. However, I respect the rights of other contributors to work in a way that way want to work. Without asking why if we don't have a strong technical reason for that.
Let me put this story from a different angle.
Is there a reason to keep branches of merged or closed PRs?
That really looks like garbage. Don't you think so?
/Thomas
On 18/02/2020 09:46, Sergii Kabashniuk
wrote:
What I didn't understand is why do you forcing
someone to do things in the way you like to do without strong
technical reasons?
Why we are ignoring diversity and pushing everybody to work in
the way how the mainstream is doing?
Is there a technical reason why we should not allow some
contributors to collaborate in the way how they used to do
that for years?
I proposed to move this conversation in a less strict tone.
1. Propose the recommended way to do the contribution.
2. Propose the recommended way for branch names.
3. Encourage people to clean up after the work has been done.
What I don't understand in the whole discussion is why
someone would object to working in their own fork. There
is really not downside to it: if you want to start
collaborating with someone else, you can just push the
branch to the main repo. Otherwise the workflow is exactly
the same as if you created your branch in the main repo.
Can someone enlighten me? /Thomas
On 17/02/2020 17:19, Sun Tan wrote:
hey,
I have created this survey:
Sun Tan Senior
Software Engineer Eclipse
Che - CodeReady Workspaces @
Red Hat
Paris
JUG leader
Red Hat Paris
OMG! Big +1 to this. I've been trying
to convince people to start using forks and keep
upstream "celan" for some time now...
yes please, do the work in personal
fork is imho right way to go on github. I would
even disable creating branches upstream so we
don't have a mess like this and each `git fetch`
downloads 10 new random branches.
I do my my work (unless I need to
cooperate with others) on my personal fork
of said projects. Is there any reason not
to? Maybe we should adopt this as a good
practice.
/Thomas
On 12/02/2020 17:11, Nick Boldt wrote:
Just a reminder to
committers that your merged PR branches
and old topic branches from closed
issues should be purged from the origin
repo to keep it clean.
Please take a few minutes to delete
your old branches. I've done so
for che-plugin-reg and che-devfile-reg
if the branch was marked merged, but
there are many more.
etc.
Thanks!
--
Nick Boldt Principal Software Engineer, RHCSA Productization Lead :: CodeReady Workspaces IM: @nickboldt / @nboldt / http://nick.divbyzero.com
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
ANATOLII BAZKO PRINCIPAL DEVELOPER
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
-- Nick Boldt Principal Software Engineer, RHCSA Productization Lead :: CodeReady Workspaces IM: @nickboldt / @nboldt / http://nick.divbyzero.com
“The Only Thing That Is Constant Is Change” - Heraclitus
_______________________________________________ che-dev mailing list che-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
|
