> On Oct. 12, 2012, 2:11 a.m., Commit Hook wrote:
> > This review has been submitted with commit
> > a78c6a50dcb33028eb572bc260bdaca8f30a597a by Dawit Alemayehu to branch
> > KDE/4.9.
Ahhh... I did not do this! How did this patch end up being cherry-picked into
4.9 branch ??!?! It is only sup
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106503/#review20214
---
This review has been submitted with commit
a78c6a50dcb33028eb5
> Problem with this approach is the code you backport is usually a lot less
> tested as you made all your developments on master. In the svn days I even
> remember people telling me they were blind-backporting to stable because it
> was "too much work to test the backported code".
One could say th
Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a écrit :
> > I think the problem is we don't know the commit policy for kde-runtime. Is
> > it:
> >
> > fix-master-and-backport: fix in master, cherry-pick to KDE/4.x
> >
> > -- or --
> >
> > fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in ma
Le jeudi 11 octobre 2012 20:02:51 Laszlo Papp a écrit :
> > I think the problem is we don't know the commit policy for kde-runtime. Is
> > it:
> >
> > fix-master-and-backport: fix in master, cherry-pick to KDE/4.x
> >
> > -- or --
> >
> > fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in ma
> I think the problem is we don't know the commit policy for kde-runtime. Is it:
>
> fix-master-and-backport: fix in master, cherry-pick to KDE/4.x
>
> -- or --
>
> fix-stable-and-merge: fix in KDE/4.x, merge KDE/4.x in master
I personally prefer the former as in contributors should make sure if
i
> If you merge stable into master you cannot miss changes.
Sure, but what I was referring to, is more than that. People should do
that for their changes, but you cannot expect there will be no
mistakes at all in the procedure. Someone making sure about this on
top of the utilities that can just be
Le mercredi 10 octobre 2012 11:13:57 Laszlo Papp a écrit :
> > Hm, as kde-runtime is not frozen in master, whoever does fixes in 4.9
> > should merge them to master.
>
> Unfortunately, there may always be changes missing. Unsure how much it
> can be automated, but I have the impression we do not e
> On Oct. 8, 2012, 9:52 a.m., Aaron J. Seigo wrote:
> > any application which expects the user to access files on disk but does not
> > provide a clear representation of mounted / removable devices is broken.
> > there's no point in degrading our own primary UI for such fixable
> > brokenness.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106527/#review20186
---
Finally took the time to file a Qt5 review:
https://codereview
10 matches
Mail list logo