Am Donnerstag, 9. Dezember 2021, 11:08:01 CET schrieb Ben Cooksley:
> On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau
>
> wrote:
> > Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
> > > This is why I have been pushing for people to use @stable in their
> > > .kde-ci.ym
On 9/12/21 12:08, Ben Cooksley wrote:
On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau
wrote:
Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
This is why I have been pushing for people to use @stable in their
.kde-ci.yml files - even for the 'master' branch.
It is mu
On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau
wrote:
> Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
> > This is why I have been pushing for people to use @stable in their
> > .kde-ci.yml files - even for the 'master' branch.
> > It is much simpler for people if you
On 8/12/21 01:08, Sandro Knauß wrote:
Hi,
Fixing it in master means i have to build a zillion of repositories before
even trying to start fixing the bug, it may also happen that once I built
master i can't reproduce the bug because master has been fixed for various
reasons (re-architecture, fix
Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
> This is why I have been pushing for people to use @stable in their
> .kde-ci.yml files - even for the 'master' branch.
> It is much simpler for people if you can use stable/released dependencies
> when conducting development.
Othe
Dzień dobry,
On środa, 8 grudnia 2021 00:01:18 CET Albert Astals Cid wrote:
> El dimarts, 7 de desembre de 2021, a les 23:20:19 (CET), Slawek Kaplonski va
escriure:
> > Hi,
> >
> > On poniedziałek, 6 grudnia 2021 19:20:20 CET Albert Astals Cid wrote:
> > > El dilluns, 6 de desembre de 2021, a le
On Wed, Dec 8, 2021 at 12:08 PM Sandro Knauß wrote:
> Hi,
>
> > > Fixing it in master means i have to build a zillion of repositories
> before
> > > even trying to start fixing the bug, it may also happen that once I
> built
> > > master i can't reproduce the bug because master has been fixed for
Hi,
> > Fixing it in master means i have to build a zillion of repositories before
> > even trying to start fixing the bug, it may also happen that once I built
> > master i can't reproduce the bug because master has been fixed for various
> > reasons (re-architecture, fixed the bug and forgot to
El dimarts, 7 de desembre de 2021, a les 23:20:19 (CET), Slawek Kaplonski va
escriure:
> Hi,
>
> On poniedziałek, 6 grudnia 2021 19:20:20 CET Albert Astals Cid wrote:
> > El dilluns, 6 de desembre de 2021, a les 7:07:50 (CET), Harald Sitter va
> escriure:
> > > I'm all for cherry picking. It's b
Hi,
On poniedziałek, 6 grudnia 2021 19:20:20 CET Albert Astals Cid wrote:
> El dilluns, 6 de desembre de 2021, a les 7:07:50 (CET), Harald Sitter va
escriure:
> > I'm all for cherry picking. It's both easier and makes sure fixes are
> > actually available in master.
>
> I don't agree that cherry
El dilluns, 6 de desembre de 2021, a les 7:07:50 (CET), Harald Sitter va
escriure:
> I'm all for cherry picking. It's both easier and makes sure fixes are
> actually available in master.
I don't agree that cherry-picking is easier.
Example: I want to fix a bug in kmail.
Fixing it in master mean
On 6 December 2021 06:07:50 GMT, Harald Sitter wrote:
> I'm all for cherry picking. It's both easier and makes sure fixes are
> actually available in master.
I like cherry picking since it tends to be more straightforward than merging,
but there's always the danger that someone might forget t
I'm all for cherry picking. It's both easier and makes sure fixes are
actually available in master.
HS
On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik wrote:
>
> Hi everyone,
>
> as part of the GitLab transition in Plasma we changed our commit
> strategy from committing to stable and merging to m
Hi everyone,
+my 2 cents: I prefer merging from stable to master because it doesn't
require me to know which commits should be ported.
On Fri, Dec 3, 2021 at 9:20 PM Nate Graham wrote:
>
> I don't have any insights into any technical blockers, but if it is
> technically feasible, I think it woul
I don't have any insights into any technical blockers, but if it is
technically feasible, I think it would be good to move everything to the
cherry-pick model due to the following advantages:
1. Unlike the merge-stable-to-master workflow, cherry-picking can be
done from the GitLab web UI, whic
On 3/12/21 21:21, Glen Ditchfield wrote:
I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request
Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* bran
I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request
Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* branch, and commit there to get the changes o
Hi everyone,
as part of the GitLab transition in Plasma we changed our commit
strategy from committing to stable and merging to master to committing
to master and cherry-picking to stable. Reason being that it's a lot
more convenient to do from GitLab's UI. I can merge and cherry-pick all
fro
18 matches
Mail list logo
