Re: Work Branches
On Fri, Oct 18, 2019 at 8:51 AM Johan Ouwerkerk wrote: > > Just one question here: what is the impact on projects in the KDE/ > namespace which have only a single maintainer/contributor? > > Are we then essentially going to accept that users merge in their own > MRs? And also, how then does that tie in with the expressed preference > for fast-forward only merges on kde-devel? I.e. are we going to switch > to fast-forward before or after doing the protcected branches thing? Please note that no proposal to date has proposed restricting developers from being able to push directly. That will be continuing. I therefore expect projects that have one or two contributors to be minimally impacted by these various proposals. The "protection" you may have seen discussed was referring to inbuilt capabilities of Gitlab to ensure branches cannot be force pushed or deleted. > > Regards, > > - Johan Cheers, Ben > > On Sat, Oct 5, 2019 at 4:11 AM Ben Cooksley wrote: > > > > Hi all, > > > > Recently we had a discussion (which I think may have ended up spread > > over a couple of mailing lists in the end) concerning branches and the > > ability to force push to them. > > > > Current policy forbids force pushing to branches except in very > > limited circumstances (essentially where it is the only option to fix > > a branch) > > > > The discussion ended with two ways forward, but no 100% clear > > consensus on which way we want to go forward. The two proposed ways > > were: > > 1) Only protect 'master' and declared 'stable' branches. > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > > > I'd like to clean this up and sort out the policy we want to have > > surrounding this so we can move forward. > > > > From my perspective i'd rather we go with Option 2, as this will be > > the approach that will be easier to both implement and maintain in the > > long term and be the least likely to cause collaboration problems (as > > the branch naming conventions will be universal across all our > > repositories). > > > > Thoughts? > > > > Thanks, > > Ben Cooksley > > KDE Sysadmin
Re: Work Branches
Just one question here: what is the impact on projects in the KDE/ namespace which have only a single maintainer/contributor? Are we then essentially going to accept that users merge in their own MRs? And also, how then does that tie in with the expressed preference for fast-forward only merges on kde-devel? I.e. are we going to switch to fast-forward before or after doing the protcected branches thing? Regards, - Johan On Sat, Oct 5, 2019 at 4:11 AM Ben Cooksley wrote: > > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > Current policy forbids force pushing to branches except in very > limited circumstances (essentially where it is the only option to fix > a branch) > > The discussion ended with two ways forward, but no 100% clear > consensus on which way we want to go forward. The two proposed ways > were: > 1) Only protect 'master' and declared 'stable' branches. > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > I'd like to clean this up and sort out the policy we want to have > surrounding this so we can move forward. > > From my perspective i'd rather we go with Option 2, as this will be > the approach that will be easier to both implement and maintain in the > long term and be the least likely to cause collaboration problems (as > the branch naming conventions will be universal across all our > repositories). > > Thoughts? > > Thanks, > Ben Cooksley > KDE Sysadmin
Re: Work Branches
On Fri, Oct 11, 2019 at 11:05 PM Michel Hermier wrote: > > Hi, > What about a refinement of that solution with "work/" and only users to > commit on their branch? In would help, if desired in the future, to enforce a > review of submited code by third party reviews even for maintainers. Hi Michel, As a general rule, we've preferred social solutions to problems over technical enforcement measures - only using technical enforcement when strictly necessary. This is why despite a preference for getting code reviewed, developers still have permission to commit directly to repositories without review. To allow for the possibility that people need to adopt work done already by others, it would be preferrable to not restrict work branches in the manner you've suggested above. Cheers, Ben
Re: Work Branches
Hi, What about a refinement of that solution with "work/" and only users to commit on their branch? In would help, if desired in the future, to enforce a review of submited code by third party reviews even for maintainers. Cheers
Re: Work Branches
Hi all, Thanks for your responses confirming Option 2 as the preferred way forward. We'll schedule this for implementation in the next few days and will announce this once it has been completed. Thanks, Ben
Re: Work Branches
On Wed, Oct 9, 2019 at 11:32 PM David Edmundson wrote: > > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > Works for me. > Would protection here also cover deletion? If so we need some heads up > notice in Plasma to do a mass move of people's forks. It would not initially prevent the deletion of branches. In the long run though we will likely restrict the right to delete non-work branches to ensure release branches cannot be removed by accident or other error. Cheers, Ben
Re: Work Branches
On woensdag 9 oktober 2019 12:32:39 CEST David Edmundson wrote: > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > Works for me. > Would protection here also cover deletion? If so we need some heads up > notice in Plasma to do a mass move of people's forks. > In krita, our convention for work branches is to use the identity name of the person working on them: rempt/T379-resource rewrite , for instance. It's proven pretty useful, but I'm not proposing we'd write a hook that scans identity to identify work branches :-) So, I'm also fine with this proposal. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Work Branches
> 2) Protect all branches, aside from a given prefix (proposed to be work/) Works for me. Would protection here also cover deletion? If so we need some heads up notice in Plasma to do a mass move of people's forks.
Re: Work Branches
On Mon, Oct 7, 2019 at 4:28 AM Luigi Toscano wrote: > > Ben Cooksley ha scritto: > > Hi all, > > > > Recently we had a discussion (which I think may have ended up spread > > over a couple of mailing lists in the end) concerning branches and the > > ability to force push to them. > > > > [...] > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > > > I'd like to clean this up and sort out the policy we want to have > > surrounding this so we can move forward. > > > > As many others pointed out, 2) seems to be really the cleanest solution. > > Just to be clear: will this apply to all repositories including personal > clones/scratches (which are now the same thing, I guess), or just to the > "official" repositories? Just to official repositories. You've always been able to force push to all branches in repositories within your personal namespace. Please note that clones and scratch repositories will become the same thing when we move to Gitlab. > > Ciao > -- > Luigi Cheers, Ben
Re: Work Branches
Ben Cooksley ha scritto: > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > [...] > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > I'd like to clean this up and sort out the policy we want to have > surrounding this so we can move forward. > As many others pointed out, 2) seems to be really the cleanest solution. Just to be clear: will this apply to all repositories including personal clones/scratches (which are now the same thing, I guess), or just to the "official" repositories? Ciao -- Luigi
Re: Work Branches
Hey Ben and developers, On Fri, Oct 4, 2019 at 7:11 PM Ben Cooksley wrote: > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > Current policy forbids force pushing to branches except in very > limited circumstances (essentially where it is the only option to fix > a branch) > > The discussion ended with two ways forward, but no 100% clear > consensus on which way we want to go forward. The two proposed ways > were: > 1) Only protect 'master' and declared 'stable' branches. > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > I'd like to clean this up and sort out the policy we want to have > surrounding this so we can move forward. > > From my perspective i'd rather we go with Option 2, as this will be > the approach that will be easier to both implement and maintain in the > long term and be the least likely to cause collaboration problems (as > the branch naming conventions will be universal across all our > repositories). > > Thoughts? > > Thanks, > Ben Cooksley > KDE Sysadmin > We in the CWG have been in discussions about this too, since there have been some people trying to force-push even after being warned by the system and sysadmin. I see that there seems to be consensus about proposal 2. My question is how will this be documented and then how do we spread the word? Our devel announce list does not seem to be as well-read as it should be. Perhaps the new policy can be linked to the Manifesto or even added to it? Valorie -- http://about.me/valoriez - pronouns: she/her
Re: Work Branches
On Fri, Oct 4, 2019, 10:11 PM Ben Cooksley wrote: > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > Current policy forbids force pushing to branches except in very > limited circumstances (essentially where it is the only option to fix > a branch) > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > In view of the fact that other may also be working on the code this seems best.
Re: Work Branches
El dissabte, 5 d’octubre de 2019, a les 4:11:11 CEST, Ben Cooksley va escriure: > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > Current policy forbids force pushing to branches except in very > limited circumstances (essentially where it is the only option to fix > a branch) > > The discussion ended with two ways forward, but no 100% clear > consensus on which way we want to go forward. The two proposed ways > were: > 1) Only protect 'master' and declared 'stable' branches. > 2) Protect all branches, aside from a given prefix (proposed to be work/) Yeah we discussed this at Akademy and i talked with some other people and they all agreed 2) was the way to go if it made things easier for everyone. I know i promised you i'd write this email and i failed, sorry about that :/ So yeah, a few +1 for solution 2) Cheers, Albert > > I'd like to clean this up and sort out the policy we want to have > surrounding this so we can move forward. > > From my perspective i'd rather we go with Option 2, as this will be > the approach that will be easier to both implement and maintain in the > long term and be the least likely to cause collaboration problems (as > the branch naming conventions will be universal across all our > repositories). > > Thoughts? > > Thanks, > Ben Cooksley > KDE Sysadmin >
Re: Work Branches
On Saturday, 5 October 2019 04:11:11 CEST Ben Cooksley wrote: > 2) Protect all branches, aside from a given prefix (proposed to be work/) +1 for a simple and clear policy. [ade] signature.asc Description: This is a digitally signed message part.
Re: Work Branches
On Saturday, 5 October 2019 04:11:11 CEST Ben Cooksley wrote: > Hi all, > > Recently we had a discussion (which I think may have ended up spread > over a couple of mailing lists in the end) concerning branches and the > ability to force push to them. > > Current policy forbids force pushing to branches except in very > limited circumstances (essentially where it is the only option to fix > a branch) > > The discussion ended with two ways forward, but no 100% clear > consensus on which way we want to go forward. The two proposed ways > were: > 1) Only protect 'master' and declared 'stable' branches. > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > I'd like to clean this up and sort out the policy we want to have > surrounding this so we can move forward. > > From my perspective i'd rather we go with Option 2, as this will be > the approach that will be easier to both implement and maintain in the > long term and be the least likely to cause collaboration problems (as > the branch naming conventions will be universal across all our > repositories). > > Thoughts? +1, sounds good to me :) Thanks, Volker signature.asc Description: This is a digitally signed message part.
Work Branches
Hi all, Recently we had a discussion (which I think may have ended up spread over a couple of mailing lists in the end) concerning branches and the ability to force push to them. Current policy forbids force pushing to branches except in very limited circumstances (essentially where it is the only option to fix a branch) The discussion ended with two ways forward, but no 100% clear consensus on which way we want to go forward. The two proposed ways were: 1) Only protect 'master' and declared 'stable' branches. 2) Protect all branches, aside from a given prefix (proposed to be work/) I'd like to clean this up and sort out the policy we want to have surrounding this so we can move forward. >From my perspective i'd rather we go with Option 2, as this will be the approach that will be easier to both implement and maintain in the long term and be the least likely to cause collaboration problems (as the branch naming conventions will be universal across all our repositories). Thoughts? Thanks, Ben Cooksley KDE Sysadmin
