[Kimchi-devel] [PATCH ] Fix screenshots and debug reports paths.

Zhou Zheng Sheng zhshzhou at linux.vnet.ibm.com
Fri Feb 28 06:58:08 UTC 2014


on 2014/02/28 10:32, Leonardo Augusto Guimarães Garcia wrote:
> On 02/27/2014 12:39 PM, Shu Ming wrote:
>> 2014/2/27 21:47, Paulo Ricardo Paz Vital:
>>> Ming,
>>>
>>> Your patch solves only the DebugReports problem, while Leonardo's patch
>>> solves any difference between what UI expects and backend sets.
>> I was planing to send screenshot patch later after all of us agree
>> with the method to fix DebugReports, anyway this is another issue not
>> directly linked to my point.  My point was that:
>> 1) when one people already worked on something, the later one should
>> communicate with the  former one to avoid duplicate effort
> Sorry, Ming, I didn't see your patch in the mailing list before I sent
> mine. I apologize for that.
>> 2) The patch should have some soaking time to be merged, say 24 hours,
>> and people in other timezone can get an opportunity to review it.
> To be honest, I think this is not necessary. If we are talking about a
> new feature or a complex bug fix, I agree with you. But this is a fairly
> simple patch that directly solves a regression that was exposed by
> aother modification in late January. I have already discussed this in a
> scrum meeting: I think that simple patches like this one should not
> necessarily have a complete review process. Having to have a formal
> review process for every small patch is just a way to overload the
> contributors and make the project slower. But, anyway, I think this is a
> good topic for discussion on the next scrum meeting.

Everyone has his/her own opinion on the necessary and sufficient
condition of a quick bug. Sometimes quick fix leads to nasty bug.
Sometimes maybe it's just a keyword typo, a quick fix is enough. IMHO,
regardless how we define a quick fix, 24 hours delay should be quick
enough for it. Unless it's an urgent && quick bug fix, we should not
bypass the normal review process.

Since Kimchi is an open source project, I doubt if there would be any
"urgent" bugs that should bypass the 24 hour delay. There might be some
bugs preventing us releasing a new version, but in this case I think we
should delay the release rather than submitting quick fix and
introducing new bugs.

I don't think a 24 hours delay would much slow down Kimchi development
speed. Sometimes it's the bug introduced from the quick patch that eats
our time to fix it.

We are building a new community, it's a wisdom to balance the
development speed and code quality. I believe that every developer for
each time he submits a patch/comment to a big community such as kernel
and libvirt, he would be very careful, because it's about the
reputation. In Kimchi we should build the same atmosphere, so that it
leads the Kimchi project to a "smooth highway".

>>>
>>> In addition, IMO the point you mentioned about not expose host file
>>> system to the front is the root cause of this bug. Many UI paths were
>>> broken because the paths set up by backend was not used or followed.
>>
>> In most cases ,we should use relative path to hide the host file
>> systems from the front users.
> The patch is not exposing anything to the front users. This path mapping
> is used internally by Cherrypy and never exposed in the UI. So I didn't
> get your point here. If someone really wants to know the real paths,
> well, this is an open source project: they will be able to see the
> source and figure out the paths in the server anyway, regardless how
> they are typed in the source code.
> 
> When Kimchi is installed through RPM, we are distributing files in
> various directories, just following what is described in the unix file
> system standard (to the best of my knowledge). Hence, using absolute
> paths is mandatory as there is no common path root shared between all
> files used by Kimchi.
> 
> If you don't think this is the case, feel free to send a patch improving
> the patch I sent before.
> 
> Best regards,
> 
> Leonardo Garcia
>>   Only if it must, the absolute path can be used.  I don't like the
>> idea to change all the relative static path to absolute ones.  IMO, we
>> can only use absolute path for the debugreport and screenshot path. 
>> Even better, we can take more effort to re-organize the path to have a
>> reasonable root for all of the path including debugreport and
>> screenshot paths.
>>
>>>
>>> Best regards,
>>
> 
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> 


-- 
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397




More information about the Kimchi-devel mailing list