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 t
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
ommit 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
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
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
x27;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
le'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
> 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.
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.
> >
> > [...]
> >
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
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
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 excep
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 f
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.
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 br
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 onl
16 matches
Mail list logo
