Gitlab fork or branch workflow?

[Dominik Haumann]

Hi Kåre,

I also use branches. There is one drawback though: If you e.g. use
CCMAIL, BUG, CCBUG, then e.g. the bug is already closed even though
the merge request is not done yet.

For that reason, the sysadmin working group was thinking about
introducing "work/*" or "feature/*" branches, but I am not aware of
any conclusion...

That said, do as you wish, but the drawback with CCMAIL et al. stands.

Best regards
Dominik

On Sun, Feb 2, 2020 at 11:04 AM Kåre Särs <kare.sars at iki.fi> wrote:
>
> On lördag 1 februari 2020 kl. 22:35:31 EET Christoph Cullmann wrote:
> > On 2020-02-01 21:33, Kåre Särs wrote:
> > > Hi,
> > >
> > > I tried to search for the the answer to this but could not find it.
> > >
> > > What is the preferred way to make a pull-request on invent.kde.org for
> > > Kate
> > > (and other KDE projects)? Is it to create a personal fork or to create
> > > a
> > > branch in the main repo?
> >
> > I tend to just use branches in the main repository.
> > I am not aware of some KDE wide rule for this at the moment.
>
> I just noticed a little drawback with using branches in the main repo. The
> commit message for the pull-request branch comes together with the normal
> commit messages to master and stable branches. This adds noise to the commit
> messages... I can add mail filters at my end, but I wonder if there could be a
> filter on gitlab...
>
> >
> > > From issues in invent.kde.org it is possible to create branches
> > > directly in
> > > the master repo...
> >
> > Would be ok with that.
> >
> > > We are not supposed to use gitlab as bug tracker, but are we going to
> > > use the
> > > issues for our development tasks?
> >
> > I think we can use it for development tasks.
> >
> > For user bug reports, bugs.kde.org is the way to go.
> >
> > > Do we want to document the way of working in the README.md?
> >
> > I think that would make sense ;)
> >
> > Let's wait for more feedback here, then we can add some lines.
> >
> > Greetings
> > Christoph
>
>
>
>