It was <2014-12-10 śro 10:42>, when Dominig ar Foll (Intel OTC) wrote:
> I see today in Gerrit a patch pushed in an unacceptable way and I
> would like to see that type of behaviour changed.
> I speak about the review
>    https://review.tizen.org/gerrit/#/c/31701/
>
> The push is justified on the comment :
>
> "Patch Set 3:
> As of now, I feel adding these credentials here is the right way to do
> because:
>     We want kdbus to be part of official images, so it is not going to
> be optional, although we may disable kdbus at boot time by default.
>     Until we enable sysusers feature of systemd we'd like to avoid
> adding and removing users with useradd/userdel."
>
> The "We want Kdbus ..." is not an agreed general feature

I beg to differ:

 https://wiki.tizen.org/wiki/Tizen_3.0
 https://bugs.tizen.org/jira/browse/TC-1024

Please also note that I haven't indicated any timeframe we want kdbus
running on the image.

> In order to get it in, the same person pushed it, verified it, and
> accept it in less than 2 hours of working day time in Europe where are
> located the Common reviewers.
> Sorry but that is not acceptable.

I am afraid it's been more than 2 hours, please look at the comments
once again.

> 1) Same person submitting, verifying and accepting a patch (even
> simple) is not in line with Tizen review model,

You are right and I share your concern.

> 2) A decent time should be left for reviewer to voice their
> concerns. Typical 24h to cover multiple time zones.

That's why I waited 42h befor putting +2 myself and still not merging.

> 3) Architecture change shall be agreed by architecture team to get in
> Common.

Adding an entry for a user and a group in databases is hardly an
architecture change, merely a preparation which in no way cannot, to the
best of my knowledge, disrupt current operation.

On the other hand a change like this, that

a) has been checked by two independent developers (Philippe and José)

b) got +1 from one of them,

c) does add two lines (and changes one to make it look prettier),

d) does not change absolutely anything in the way current system works,

in my humble opinion can be handeled with a *little* less involvment
From other developers. If you look around the Gerrit you will find that
we work like this every day. Just a few examples from the top of the
list:

https://review.tizen.org/gerrit/31550/
https://review.tizen.org/gerrit/31314/
https://review.tizen.org/gerrit/31795/
https://review.tizen.org/gerrit/31787/

Is it bad? Not necessarily because right next to the rules you've
mentioned is another value I hope we all share, it is trust. We trust
that guys on the other end of the world know what they are doing and do
not *always* bother them with pointing out every single formal mistake
they make (I do, *sometimes*, complain about commit messages). In case
of small changes like this one an oportunistic approach may be more
efficient because the cost of a very through review is larger than cost
of fixing a mistake multipled by probability of making it (risk).

> So please do not force changes any more.
> In that specific case, if you need Kdbus in a profile before than it
> is agree to be generalised in Common, please make an agreement with
> Common to enable it with a clean model.
> In that specific case the use of a "%bcond_with kdbus" seems a viable model.

I did exactly this in systemd-216 because it was the right way. I didn't
do it here in the first place because it makes the patch twice as big,
not a bit more readable and does not change anything in any other part
of the sysem.

> Please accept my apologies for having to be a bit rude.

Accepted.

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Attachment: pgpPv5KH8FrR2.pgp
Description: PGP signature

_______________________________________________
Dev mailing list
Dev@lists.tizen.org
https://lists.tizen.org/listinfo/dev

Reply via email to