On Thursday, 16 October 2014 23:43:00 CEST, Kevin Kofler wrote:
In Gerrit, I basically get an ugly command-line interface: I
have to push to
a magic ref encoding all the information (and IIRC, git-cola only lets me
enter the basic refs/for/branchname, the special characters in stuff like
%r=f.
Jan Kundrát wrote:
> A random data point -- I asked a 3rd-party contributor to send a patch to
> Trojita through Gerrit earlier today. He accomplished that goal so fast
> that I asked him for an estimate on how much time it took. The answer was
> 15 minutes, including reading the docs and setting u
The language for Code-Review +2 now reads "Looks good to me and I know this
code, approved". I hope people won't be afraid to approve changes now :).
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
On Mon, Sep 15, 2014 at 09:34:27AM -0700, Thiago Macieira wrote:
> On Monday 15 September 2014 16:49:39 Milian Wolff wrote:
> > Where do I see the diff there? In the gerrit that runs on qt-project, I can
> > easily click one button to go to a unified or side-by-side diff view. Is
> > that a custom
On Monday, 15 September 2014 16:49:39 CEST, Milian Wolff wrote:
Where do I see the diff there?
Thanks to Ben and his review of my patches, Gerrit is now replicating all
of the changes under review into KDE's git as well. In the context of this
discussion, it means that there's now a link to K
On Monday, 15 September 2014 16:49:39 CEST, Milian Wolff wrote:
Where do I see the diff there?
For me, it's easiest to just click on any file name. That will open a diff
view (either side-by-side or a unidiff one, based on your prefs). The diff
shows just a single file, but you can use "[" an
On Monday 15 September 2014 16:49:39 Milian Wolff wrote:
> Where do I see the diff there? In the gerrit that runs on qt-project, I can
> easily click one button to go to a unified or side-by-side diff view. Is
> that a custom extension? Generally, it seems as if the qt-project gerrit
> has a much
On Saturday 13 September 2014 23:05:48 Eike Hein wrote:
> On 13.09.2014 22:50, Sven Brauch wrote:
> > That's my opinion as well. It would be nice to have an explicit way to
> > differentiate the "I think this patch is okay, but I'm not very
> > familiar with the code you changed" (+1) and "I'm conf
On Saturday, 13 September 2014 23:05:48 CEST, Eike Hein wrote:
Yeah, that's something I'm OK with too. Maybe we can even
adapt the UI to use strings like Sven proposes?
https://gerrit.vesnicky.cesnet.cz/r/35
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.fla
On Saturday, 13 September 2014 20:40:27 CEST, Kevin Krammer wrote:
As for submit, that IMHO should at least also be available to the review
request owner.
Does anyone see advantages of having submit restricted at all once the
necessary approval has been achieved?
I made a mistake when descri
On Saturday, 13 September 2014 23:29:55 CEST, David Edmundson wrote:
I think a good example is your patch today (and pretending you're not a
maintainer). There was a single typo in a commit message. I wanted it
fixing, but I don't want to have to have to review that whole thing again
(in reviewbo
On Saturday, 13 September 2014 21:46:55 CEST, Eike Hein wrote:
But as said, I don't think it's actually true. I think we
*can* trust KDE developer account holders, and that's why
we don't need an extra safety net in the form of having a
+2 and restricting it to maintainers.
This is not only abo
On 13.09.2014 21:34, Martin Gräßlin wrote:
I also see that I should have elaborated more. I had written more and removed
it before sending the mail.
I just wanted to say thanks for a well thought-out reply - I
didn't reply in turn because the discussion continued on the
other fork, and it's p
On Saturday 13 September 2014 23:29:55 David Edmundson wrote:
> On 12 Sep 2014 22:53, "Marco Martin" wrote:
> > On Tuesday, September 9, 2014, Jan Kundrát wrote:
> > > If you would like all plasma to go, just give me a list of repos and I
> >
> > can make it happen.
> >
> > No, definitely not y
On 12 Sep 2014 22:53, "Marco Martin" wrote:
> On Tuesday, September 9, 2014, Jan Kundrát wrote:
> >
> > If you would like all plasma to go, just give me a list of repos and I
> can make it happen.
>
> No, definitely not yet
>
> >
> > In my opinion, the purpose of this test is not to verify that
On 13.09.2014 22:50, Sven Brauch wrote:
That's my opinion as well. It would be nice to have an explicit way to
differentiate the "I think this patch is okay, but I'm not very
familiar with the code you changed" (+1) and "I'm confident this patch
is fine" (+2) cases, and I think everyone with a
> Everyone with a KDE developer account should in principle have
> the right to give a +2. One should only use it when appropriate though, i.e.
> when one is the maintainer of a given piece of code or when the patch is
> simple enough so that one feels safe to give the other the ship-it.
That's my
On Sunday 14 September 2014 08:11:43 Ben Cooksley wrote:
> On Sun, Sep 14, 2014 at 8:07 AM, Ivan Čukić wrote:
> >> that needs to be reverted because it's actively objectiona-
> >> ble. As Ivan pointed out, few of us will ever commit any-
> >> thing if we're not confident it would meet with the app
On Sun, Sep 14, 2014 at 8:07 AM, Ivan Čukić wrote:
>
>> that needs to be reverted because it's actively objectiona-
>> ble. As Ivan pointed out, few of us will ever commit any-
>> thing if we're not confident it would meet with the approval
>
> While I do agree that we have a strange and unreally
> that needs to be reverted because it's actively objectiona-
> ble. As Ivan pointed out, few of us will ever commit any-
> thing if we're not confident it would meet with the approval
While I do agree that we have a strange and unreally awesome community that
behaves really well (and I do trust
On 13.09.2014 21:10, Kevin Krammer wrote:
So your suggestion would be to not have +2 but a policy of some sort that only
the +1 of the maintainer, if there is an active one, is considered as "go
ahead"?
Basically my thinking is roughly this: It actually happens
extremely rarely in practice th
On Saturday 13 September 2014 20:38:21 Eike Hein wrote:
> The argument "but you can still bypass Gerrit and push
> directly, this is just social etiquette" doesn't matter
> because the whole thing is about social etiquette. The
> ACLs we already have reflect our social etiquette, and
> that means w
On Saturday, 2014-09-13, 20:38:21, Eike Hein wrote:
> These things reinforce each other in multiple ways. If main-
> tainers are not entrenched positions, they're easy to replace
> when they move on (whether they can accept this themselves or
> not). Once you codify them in ACLs (and yes, we do th
On 13.09.2014 20:21, Ivan Čukić wrote:
I agree, +2 should be retained by the maintainer, or a smaller set of
developers as decided by the maintainer.
Or perhaps it simply turns out that the whole idea of
*having* a '+2' is incompatible with the KDE community
in the first place.
Do we really
On Saturday, 2014-09-13, 17:49:31, Martin Gräßlin wrote:
> On Saturday 13 September 2014 16:51:15 Albert Astals Cid wrote:
> > El Divendres, 12 de setembre de 2014, a les 22:52:40, Marco Martin va
> >
> > escriure:
> > > On Tuesday, September 9, 2014, Jan Kundrát wrote:
> > > > If you would like
On 13.09.2014 17:49, Martin Gräßlin wrote:
my understanding was that it's still possible to bypass the code review, so I
cannot see that it's against the KDE Manifesto as it's only a kind of social
contract. Or am I missing something.
Personally I like the idea of having the +2 limited to the
> my understanding was that it's still possible to bypass the code review, so
> I cannot see that it's against the KDE Manifesto as it's only a kind of
> social contract. Or am I missing something.
>
> Personally I like the idea of having the +2 limited to the devs familiar
> with the code.
I ag
On Saturday 13 September 2014 16:51:15 Albert Astals Cid wrote:
> El Divendres, 12 de setembre de 2014, a les 22:52:40, Marco Martin va
>
> escriure:
> > On Tuesday, September 9, 2014, Jan Kundrát wrote:
> > > If you would like all plasma to go, just give me a list of repos and I
> >
> > can mak
El Divendres, 12 de setembre de 2014, a les 22:52:40, Marco Martin va
escriure:
> On Tuesday, September 9, 2014, Jan Kundrát wrote:
> > If you would like all plasma to go, just give me a list of repos and I
>
> can make it happen.
>
> No, definitely not yet
>
> > In my opinion, the purpose of
On Tuesday, September 9, 2014, Jan Kundrát wrote:
>
> If you would like all plasma to go, just give me a list of repos and I
can make it happen.
No, definitely not yet
>
> In my opinion, the purpose of this test is not to verify that Gerrit
works or that the ACLs are set up properly -- both were
On Wednesday, 2014-09-10, 06:54:50, Ben Cooksley wrote:
> In regards to why we are permitting Gerrit to be evaluated - it is
> primarily to allow for the community to come to a decision. The
> complexity of the user interface among other issues are still problems
> which sysadmin believes could bl
2014-09-09 17:39 GMT+02:00 Aaron J. Seigo :
>
> [1] even if I have my personal doubts w/regards to gerrit's appropriateness
> for KDE
Probably I'm too late for the party, but have you considered gitlab?
It can be a replacement for review board and redmine (personally i
find its repo view and proj
On Wednesday, September 10, 2014 00.23:18 Jan Kundrát wrote:
> On Tuesday, 9 September 2014 21:44:25 CEST, Alexander Neundorf wrote:
> > Having two different patch review systems for one project... I
> > mean, this is
> > surely not a good idea. Two places to send patches, to places to review
> > p
On Tuesday 09 September 2014 20:02:55 Aaron J. Seigo wrote:
> In any case, can you see the inconsistency between saying "we need highly
> active repos to find pain points" and "these projects will only use it on an
> opt-in basis, and not even for all patches"? You may as well throw a more
> lightl
On Tuesday, 9 September 2014 21:44:25 CEST, Alexander Neundorf wrote:
Having two different patch review systems for one project... I
mean, this is
surely not a good idea. Two places to send patches, to places to review
patches, two different user interfaces,
This is not a final state. To be h
On Tuesday, 9 September 2014 20:02:55 CEST, Aaron J. Seigo wrote:
That would honestly make more sense for Plasma imho, though it still would
make sense to start small and consistent.
A suggestion made by sysadmins was to start with just a couple of repos to
prevent further confusion and to bui
On Tuesday, 9 September 2014 17:39:54 CEST, Aaron J. Seigo wrote:
Would it not make more sense to trial it using newer / smaller / unstable
projects, as it is an experiment?
Yes, which is why trojita.git was dogfooding Gerrit before I announced
this.
As it stands with plasma-framework in par
On Tuesday, September 09, 2014 20:02:55 Aaron J. Seigo wrote:
> On Tuesday, September 9, 2014 18.49:24 Kevin Ottens wrote:
> > > As it stands with plasma-framework in particular, there is now a
> > > difference
> > > in workflow depending on what *part* of plasma one is working on
> > > (framework
Hi all,
Just to clarify what is happening here, based on my reading of the
discussion here thus far, and in #kde-devel earlier today.
I concur with the majority that a unified tool, similar to Gitlab
would be an excellent improvement on our current infrastructure.
Unfortunately we found that at o
On Tuesday, September 9, 2014 18.32:41 Pier Luigi Fiorini wrote:
> 2014-09-09 17:39 GMT+02:00 Aaron J. Seigo :
> > [1] even if I have my personal doubts w/regards to gerrit's
> > appropriateness
> > for KDE
>
> Probably I'm too late for the party, but have you considered gitlab?
Yes; I helped tri
On Tuesday, September 9, 2014 18.49:24 Kevin Ottens wrote:
> > As it stands with plasma-framework in particular, there is now a
> > difference
> > in workflow depending on what *part* of plasma one is working on
> > (framework
> > or workspace). So not only is it now different from the majority of
Hello,
OK, I guess there might be some misunderstanding or at least partial
information due to live meeting vs short announcement on list.
On Tuesday 09 September 2014 17:39:54 Aaron J. Seigo wrote:
> On Tuesday, September 9, 2014 16.59:35 Jan Kundrát wrote:
> > On Tuesday, 9 September 2014 16:4
On Tuesday, September 9, 2014 16.59:35 Jan Kundrát wrote:
> On Tuesday, 9 September 2014 16:44:22 CEST, Eike Hein wrote:
> > Exclusively, or do they remain on ReviewBoard as well?
>
> My understanding is that they do remain on RB as well for now. The goal of
> this excercise is to get some underst
On Tuesday, 9 September 2014 16:44:22 CEST, Eike Hein wrote:
Exclusively, or do they remain on ReviewBoard as well?
My understanding is that they do remain on RB as well for now. The goal of
this excercise is to get some understanding on how Gerrit works and whether
it's a good match for fram
On 09.09.2014 15:51, Jan Kundrát wrote:
Hi,
we agreed on the Frameworks BoF that the following two repos are now
using Gerrit for some initial testing:
Exclusively, or do they remain on ReviewBoard as well?
Cheers,
Eike
Hi,
we agreed on the Frameworks BoF that the following two repos are now using
Gerrit for some initial testing:
- kio
- plasma-framework
Some rudimentary instructions are at
https://techbase.kde.org/Development/Gerrit , edits are welcome.
If you would like to become a Gerrit admin, want to
On Sunday, 7 September 2014 21:27:44 CEST, Eike Hein wrote:
I'm curious however, what's the state of manifesto-compliance[1]
for the Gerrit instance? Does KDE Sysadmin have admin access and
the ability to get the data out if needed?
This is a very good question. Right now, only I (and other CES
On 07.09.2014 11:00, Jan Kundrát wrote:
Hi folks,
as requested by Ben, I would like to accounce that Trojita
(extragear/pim/trojita) is now using Gerrit [1] for patch review.
The system is open for other KDE projects as well -- if you're
interested, see [2] for further details, or come to my t
Hi folks,
as requested by Ben, I would like to accounce that Trojita
(extragear/pim/trojita) is now using Gerrit [1] for patch review.
The system is open for other KDE projects as well -- if you're interested,
see [2] for further details, or come to my talk today at 14:00 in room #2
at the Ak
49 matches
Mail list logo
