Re: [Engine-devel] Changing Gerrit -1 message
On 19/02/2013 12:06, Laszlo Hornyak wrote: Hi, I agree with that. for the - messages this in my opinion would be both more clear and friendly: -1: In my opinion it needs work. how about "-1: Please review my comments" -2: I disagree. "-2: Please reconsider" - Original Message - From: "Ofer Schreiber" To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 10:51:15 AM Subject: [Engine-devel] Changing Gerrit -1 message I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself. Any thoughts about a more suitable "-1" message? I thought about "-1 Please fix your code" or something similar. Thanks, Ofer Schreiber ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changing Gerrit -1 message
I like most of these proposals. It'll make gerrit friendlier :-) - Original Message - > From: "Itamar Heim" > To: "Laszlo Hornyak" > Cc: engine-devel@ovirt.org > Sent: Wednesday, February 20, 2013 9:32:53 AM > Subject: Re: [Engine-devel] Changing Gerrit -1 message > > On 19/02/2013 12:06, Laszlo Hornyak wrote: > > Hi, > > > > I agree with that. > > > > for the - messages this in my opinion would be both more clear and > > friendly: > > -1: In my opinion it needs work. > > > how about > "-1: Please review my comments" > > > -2: I disagree. > > "-2: Please reconsider" > > > > > - Original Message - > >> From: "Ofer Schreiber" > >> To: engine-devel@ovirt.org > >> Sent: Tuesday, February 19, 2013 10:51:15 AM > >> Subject: [Engine-devel] Changing Gerrit -1 message > >> > >> I feel that the current "-1 I would prefer that you didn't submit > >> this" message in Gerrit is pretty rude, as usually those -1 > >> reviews > >> are just small fix-ups in the code itself. > >> > >> Any thoughts about a more suitable "-1" message? > >> I thought about "-1 Please fix your code" or something similar. > >> > >> Thanks, > >> Ofer Schreiber > >> > >> ___ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: > > > - Original Message - >> From: "Vojtech Szocs" >> To: "Daniel Erez" >> Cc: a...@ovirt.org, engine-devel@ovirt.org >> Sent: Saturday, February 16, 2013 1:07:56 AM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> Hi Daniel, >> >>> The first alternative can be implemented by using GWT >>> RequestBuilder (for sending the HTTP requests) >>> and GWT overlay types (that can be generated from java POJOs). >>> Probably best performance-wise/less data type conversions/etc; >>> However, basically means writing a JavaScript SDK. >> >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but >> using GWT overlay types is possible only if REST API fully supports >> JSON format. In case of XML format, we would have to use GWT >> XMLParser to map "restapi-types" entities/collections to/from XML >> strings, e.g. we could write GWT deferred binding generators to >> generate such mappers from current schema. > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be > useful instead of generating/writing overlay types. AutoBeans will be > converted overlay types internally by GWT automatically. > >> >>> The benefit of the second alternative is currently rather vague >>> since the Java SDK can't be converted to JavaScript as is >>> (can't use apache.commons and javax packages in GWT client side). >>> Need to check how easily they can be replaced >>> with JRE libraries that GWT can emulate (for supporting both GWT >>> web and debug mode). >> >> Indeed, we can't use Java REST API SDK as it is with GWT: >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation >> >> This means we need to implement our own transport layer >> (RequestBuilder) and most likely also the marshalling layer >> (XMLParser vs. JSONParser vs. overlay types). > > It would be better if We can come up with a "GWT REST API SDK", which is > analogous Java SDK. > >> >>> A third alternative could be simply maintaining the current GWT RPC >>> mechanism we use. >>> I.e. integrating the Java SDK into the GWT servlet, which means >>> wrapping the API into GenericApiGWTService. >>> The main drawback is an additional layer of data type conversion >>> and round-trip: >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). >> >> This is interesting, generic API could be used to transfer >> "restapi-types", along with extra information to emulate proper HTTP >> request, without any marshalling involved. >> > > We can't directly use the restapi models in the client side, as they have lot > of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization & talking with api. > >> Vojtech >> >> >> - Original Message - >> From: "Daniel Erez" >> To: "Michael Pasternak" >> Cc: engine-devel@ovirt.org, "Einav Cohen" , >> a...@ovirt.org, "Libor Spevak" , "Vojtech Szocs" >> >> Sent: Friday, February 15, 2013 7:17:43 PM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> >> >> - Original Message - >>> From: "Michael Pasternak" >>> To: "Libor Spevak" >>> Cc: engine-devel@ovirt.org, "Daniel Erez" , >>> "Gilad Chaplik" , "Einav Cohen" >>> , a...@ovirt.org >>> Sent: Wednesday, February 13, 2013 12:55:36 PM >>> Subject: Re: [Engine-devel] REST API calls from the GUI >>> >>> >>> Hi Libor, >>> >>> This issue came across in one of the conversations i had with UX >>> folks, but since we didn't end >>> up with any conclusion/road map (nor discussed it properly to hear >>> other thoughts), this is a perfect >>> place to start this discussion, >>> >>> Intuitively REST is a way to go with GWT AJAX calls >>> --- >>> >>> pros >>> >>> >>> - api data objects can be reused by generating java classes (using >>> jaxb) from the rest schema [1] >>> - no backend logic will be duplicated as api abstracts the backend >>> exposing RESTful collection/resources to operate on >>> - development against api is "easy" as api describes itself in RSDL >>> [2] >>> >>> cons >>> >>> >>> - implementing transport layer (HTTP) under GWT >>> - implementing own j2xml/json/yaml/... marshalling layer >>> - implementing own error handling mechanism >>> - implementing REST callback mechanism (in GWT) >>> - constant maintenance of the data objects generated from the api >>> - painful for Java developers >>> >>> Java-SDK >>> >>> >>> pros >>> >>> >>> - abstracts transport layer (leaving developer in standard Java >>> api) >>> - typesafe code (no need to mess with XML bulks) >>> - has own data objects to work with >>> - abstracts authentication/authorization >>> (kerberos/cookie/session/etc.) >>> - since SDK is auto-generated, it can be easily extended with >>> required >>> features to support UI (such as callback infrastructure for >>> instance) >>> >>> cons >>> >>> >>> - has to be
Re: [Engine-devel] REST API calls from the GUI
- Original Message - > From: "Michael Pasternak" > To: "Kanagaraj Mayilsamy" > Cc: "Vojtech Szocs" , engine-devel@ovirt.org, > a...@ovirt.org > Sent: Wednesday, February 20, 2013 5:55:50 PM > Subject: Re: [Engine-devel] REST API calls from the GUI > > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: > > > > > > - Original Message - > >> From: "Vojtech Szocs" > >> To: "Daniel Erez" > >> Cc: a...@ovirt.org, engine-devel@ovirt.org > >> Sent: Saturday, February 16, 2013 1:07:56 AM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> Hi Daniel, > >> > >>> The first alternative can be implemented by using GWT > >>> RequestBuilder (for sending the HTTP requests) > >>> and GWT overlay types (that can be generated from java POJOs). > >>> Probably best performance-wise/less data type conversions/etc; > >>> However, basically means writing a JavaScript SDK. > >> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but > >> using GWT overlay types is possible only if REST API fully > >> supports > >> JSON format. In case of XML format, we would have to use GWT > >> XMLParser to map "restapi-types" entities/collections to/from XML > >> strings, e.g. we could write GWT deferred binding generators to > >> generate such mappers from current schema. > > > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) > > could be useful instead of generating/writing overlay types. > > AutoBeans will be converted overlay types internally by GWT > > automatically. > > > >> > >>> The benefit of the second alternative is currently rather vague > >>> since the Java SDK can't be converted to JavaScript as is > >>> (can't use apache.commons and javax packages in GWT client side). > >>> Need to check how easily they can be replaced > >>> with JRE libraries that GWT can emulate (for supporting both GWT > >>> web and debug mode). > >> > >> Indeed, we can't use Java REST API SDK as it is with GWT: > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation > >> > >> This means we need to implement our own transport layer > >> (RequestBuilder) and most likely also the marshalling layer > >> (XMLParser vs. JSONParser vs. overlay types). > > > > It would be better if We can come up with a "GWT REST API SDK", > > which is analogous Java SDK. > > > >> > >>> A third alternative could be simply maintaining the current GWT > >>> RPC > >>> mechanism we use. > >>> I.e. integrating the Java SDK into the GWT servlet, which means > >>> wrapping the API into GenericApiGWTService. > >>> The main drawback is an additional layer of data type conversion > >>> and round-trip: > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > >> > >> This is interesting, generic API could be used to transfer > >> "restapi-types", along with extra information to emulate proper > >> HTTP > >> request, without any marshalling involved. > >> > > > > We can't directly use the restapi models in the client side, as > > they have lot of xml and annotations stuff involved which will not > > be compatible with GWT. > > why? they only have jaxb annotations which are 'must' for > serialization & talking with api. > We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. > > > >> Vojtech > >> > >> > >> - Original Message - > >> From: "Daniel Erez" > >> To: "Michael Pasternak" > >> Cc: engine-devel@ovirt.org, "Einav Cohen" , > >> a...@ovirt.org, "Libor Spevak" , "Vojtech > >> Szocs" > >> > >> Sent: Friday, February 15, 2013 7:17:43 PM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> > >> > >> - Original Message - > >>> From: "Michael Pasternak" > >>> To: "Libor Spevak" > >>> Cc: engine-devel@ovirt.org, "Daniel Erez" , > >>> "Gilad Chaplik" , "Einav Cohen" > >>> , a...@ovirt.org > >>> Sent: Wednesday, February 13, 2013 12:55:36 PM > >>> Subject: Re: [Engine-devel] REST API calls from the GUI > >>> > >>> > >>> Hi Libor, > >>> > >>> This issue came across in one of the conversations i had with UX > >>> folks, but since we didn't end > >>> up with any conclusion/road map (nor discussed it properly to > >>> hear > >>> other thoughts), this is a perfect > >>> place to start this discussion, > >>> > >>> Intuitively REST is a way to go with GWT AJAX calls > >>> --- > >>> > >>> pros > >>> > >>> > >>> - api data objects can be reused by generating java classes > >>> (using > >>> jaxb) from the rest schema [1] > >>> - no backend logic will be duplicated as api abstracts the > >>> backend > >>> exposing RESTful collection/resources to operate on > >>> - development against api is "easy" as api desc
Re: [Engine-devel] REST API calls from
On 02/14/2013 11:20 AM, Doron Fediuck wrote: > > > - Original Message - >> From: "Michael Pasternak" >> To: "Libor Spevak" >> Cc: engine-devel@ovirt.org, a...@ovirt.org >> Sent: Wednesday, February 13, 2013 12:55:36 PM >> Subject: Re: [Engine-devel] REST API calls from the GUI >> >> >> Hi Libor, >> >> This issue came across in one of the conversations i had with UX >> folks, but since we didn't end >> up with any conclusion/road map (nor discussed it properly to hear >> other thoughts), this is a perfect >> place to start this discussion, >> >> Intuitively REST is a way to go with GWT AJAX calls >> --- >> >> pros >> >> >> - api data objects can be reused by generating java classes (using >> jaxb) from the rest schema [1] >> - no backend logic will be duplicated as api abstracts the backend >> exposing RESTful collection/resources to operate on >> - development against api is "easy" as api describes itself in RSDL >> [2] >> >> cons >> >> >> - implementing transport layer (HTTP) under GWT >> - implementing own j2xml/json/yaml/... marshalling layer >> - implementing own error handling mechanism >> - implementing REST callback mechanism (in GWT) >> - constant maintenance of the data objects generated from the api >> - painful for Java developers >> >> Java-SDK >> >> >> pros >> >> >> - abstracts transport layer (leaving developer in standard Java api) >> - typesafe code (no need to mess with XML bulks) >> - has own data objects to work with >> - abstracts authentication/authorization >> (kerberos/cookie/session/etc.) >> - since SDK is auto-generated, it can be easily extended with >> required >> features to support UI (such as callback infrastructure for >> instance) >> >> cons >> >> >> - has to be converted in to Javascript (not sure what the impacts are >> in terms of AJAX calls/etc.) >> - probably much more cons that we're not aware of and will have to >> figure out with POC >> >> >> thoughts? >> >> [1] http[s]://server[:port]/api?schema >> [2] http[s]://server[:port]/api?rsdl >> > > Although started as a UI request, there are other needs who wish > to use API calls with a different transport. For example a backend > hook which gets a REST entry point it can use to fetch for additional > data, or perform actions. In this case I'd expect an internal connection > rather than creating additional connections. > How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api<->GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. > >> On 02/12/2013 06:13 PM, Libor Spevak wrote: >>> Hi, >>> >>> I would like to ask, if there have been discussions about an option >>> to call REST API services directly from the Frontend (GWT layer)? >>> GWT compiles Java frontend-side to >>> Javascript, calls to backend services are performed "transparently" >>> by the framework using AJAX support. But, there is still a need to >>> have a special set of data objects >>> and the server-side logic can duplicate. >>> >>> Java REST API SDK enables to build "thick" client. The calls are >>> realized using e.g. Apache HttClient and supported libraries. I >>> think the requirements of GWT can be a >>> little bit different, but something overlaps. >>> >>> I found several links about REST API support from GWT, so there is >>> something for inspiration... >>> >>> - http://www.spiffyui.org/ >>> - http://www.zackgrossbart.com/hackito/gwt-rest/ >>> - http://code.google.com/p/gwt-rest/ >>> - http://restygwt.fusesource.org/ >>> >>> But, do you think it would be useful and what drawbacks can occur >>> (authentication, authorization, response times, need to support >>> larger set of services, painful >>> refactoring, ...)? >>> >>> Regards, >>> Libor >>> >>> ___ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> ___ >> Arch mailing list >> a...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch >> -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote: > > - Original Message - >> > From: "Michael Pasternak" >> > To: "Kanagaraj Mayilsamy" >> > Cc: "Vojtech Szocs" , engine-devel@ovirt.org, >> > a...@ovirt.org >> > Sent: Wednesday, February 20, 2013 5:55:50 PM >> > Subject: Re: [Engine-devel] REST API calls from the GUI >> > >> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: >>> > > >>> > > >>> > > - Original Message - > >> From: "Vojtech Szocs" > >> To: "Daniel Erez" > >> Cc: a...@ovirt.org, engine-devel@ovirt.org > >> Sent: Saturday, February 16, 2013 1:07:56 AM > >> Subject: Re: [Engine-devel] REST API calls from the GUI > >> > >> Hi Daniel, > >> > > >>> The first alternative can be implemented by using GWT > > >>> RequestBuilder (for sending the HTTP requests) > > >>> and GWT overlay types (that can be generated from java POJOs). > > >>> Probably best performance-wise/less data type conversions/etc; > > >>> However, basically means writing a JavaScript SDK. > >> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but > >> using GWT overlay types is possible only if REST API fully > >> supports > >> JSON format. In case of XML format, we would have to use GWT > >> XMLParser to map "restapi-types" entities/collections to/from XML > >> strings, e.g. we could write GWT deferred binding generators to > >> generate such mappers from current schema. >>> > > >>> > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) >>> > > could be useful instead of generating/writing overlay types. >>> > > AutoBeans will be converted overlay types internally by GWT >>> > > automatically. >>> > > > >> > > >>> The benefit of the second alternative is currently rather vague > > >>> since the Java SDK can't be converted to JavaScript as is > > >>> (can't use apache.commons and javax packages in GWT client side). > > >>> Need to check how easily they can be replaced > > >>> with JRE libraries that GWT can emulate (for supporting both GWT > > >>> web and debug mode). > >> > >> Indeed, we can't use Java REST API SDK as it is with GWT: > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation > >> > >> This means we need to implement our own transport layer > >> (RequestBuilder) and most likely also the marshalling layer > >> (XMLParser vs. JSONParser vs. overlay types). >>> > > >>> > > It would be better if We can come up with a "GWT REST API SDK", >>> > > which is analogous Java SDK. >>> > > > >> > > >>> A third alternative could be simply maintaining the current GWT > > >>> RPC > > >>> mechanism we use. > > >>> I.e. integrating the Java SDK into the GWT servlet, which means > > >>> wrapping the API into GenericApiGWTService. > > >>> The main drawback is an additional layer of data type conversion > > >>> and round-trip: > > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client). > >> > >> This is interesting, generic API could be used to transfer > >> "restapi-types", along with extra information to emulate proper > >> HTTP > >> request, without any marshalling involved. > >> >>> > > >>> > > We can't directly use the restapi models in the client side, as >>> > > they have lot of xml and annotations stuff involved which will not >>> > > be compatible with GWT. >> > >> > why? they only have jaxb annotations which are 'must' for >> > serialization & talking with api. >> > > We can't use jaxb, as GWT won't emulate the jaxb classes. > https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation > > If at all we want use jaxb, we should include the source of jaxb to ui > module, so that GWT can compile them to javascript equivalents. But this is > less likely as jaxb relies heavily on reflection which not supported by GWT. > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), if your schema->java converting tool support this, you're okay. -- Michael Pasternak RedHat, ENG-Virtualization R&D ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
thoughts on how to trim these? (in openstack gerrit they auto-abandon patches with no activity for a couple of weeks - author can revive them back when they are relevant) preferred_email | count --+-- mkole...@redhat.com | 17 rgo...@redhat.com | 12 sesub...@redhat.com | 8 lhorn...@redhat.com | 5 lara...@redhat.com| 4 juan.hernan...@redhat.com | 4 lver...@redhat.com| 4 aw...@redhat.com | 4 mhun...@gmail.com | 3 vsz...@redhat.com | 3 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
- Original Message - > thoughts on how to trim these? > (in openstack gerrit they auto-abandon patches with no activity for a > couple of weeks - author can revive them back when they are relevant) > > preferred_email | count > --+-- > mkole...@redhat.com | 17 Is the problem that they're not updated? I am working on a topic branch, so currently no plan to push it to master but I still want it to be open to review. > rgo...@redhat.com | 12 > sesub...@redhat.com | 8 > lhorn...@redhat.com | 5 > lara...@redhat.com| 4 > juan.hernan...@redhat.com | 4 > lver...@redhat.com| 4 > aw...@redhat.com | 4 > mhun...@gmail.com | 3 > vsz...@redhat.com | 3 > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
Hi, Why not sending this as a reminder? But sending also the gerrit links For example, I assume mkolesni sent an engine patch, maybe I as someone who also sends patches to engine can review (even if not ACK, share some thoughts?) Thanks, Yair - Original Message - > From: "Itamar Heim" > To: "engine-devel" > Sent: Wednesday, February 20, 2013 5:39:16 PM > Subject: [Engine-devel] Engine - top 10 with patches with no activity for > more than 30 days > > thoughts on how to trim these? > (in openstack gerrit they auto-abandon patches with no activity for a > couple of weeks - author can revive them back when they are relevant) > > preferred_email | count > --+-- > mkole...@redhat.com | 17 > rgo...@redhat.com | 12 > sesub...@redhat.com | 8 > lhorn...@redhat.com | 5 > lara...@redhat.com| 4 > juan.hernan...@redhat.com | 4 > lver...@redhat.com| 4 > aw...@redhat.com | 4 > mhun...@gmail.com | 3 > vsz...@redhat.com | 3 > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
On 20/02/2013 18:02, Mike Kolesnik wrote: - Original Message - thoughts on how to trim these? (in openstack gerrit they auto-abandon patches with no activity for a couple of weeks - author can revive them back when they are relevant) preferred_email | count --+-- mkole...@redhat.com | 17 Is the problem that they're not updated? yes. any 'touch' to them would be enough. I am working on a topic branch, so currently no plan to push it to master but I still want it to be open to review. so not one reviewed them for a over month... rgo...@redhat.com | 12 sesub...@redhat.com | 8 lhorn...@redhat.com | 5 lara...@redhat.com| 4 juan.hernan...@redhat.com | 4 lver...@redhat.com| 4 aw...@redhat.com | 4 mhun...@gmail.com | 3 vsz...@redhat.com | 3 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
On 20/02/2013 18:04, Yair Zaslavsky wrote: Hi, Why not sending this as a reminder? But sending also the gerrit links For example, I assume mkolesni sent an engine patch, maybe I as someone who also sends patches to engine can review (even if not ACK, share some thoughts?) if you want to help and review old patches, just set your gerrit search to age:30d and review old patches... Thanks, Yair - Original Message - From: "Itamar Heim" To: "engine-devel" Sent: Wednesday, February 20, 2013 5:39:16 PM Subject: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days thoughts on how to trim these? (in openstack gerrit they auto-abandon patches with no activity for a couple of weeks - author can revive them back when they are relevant) preferred_email | count --+-- mkole...@redhat.com | 17 rgo...@redhat.com | 12 sesub...@redhat.com | 8 lhorn...@redhat.com | 5 lara...@redhat.com| 4 juan.hernan...@redhat.com | 4 lver...@redhat.com| 4 aw...@redhat.com | 4 mhun...@gmail.com | 3 vsz...@redhat.com | 3 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Engine - top 10 with patches with no activity for more than 30 days
- Original Message - > From: "Itamar Heim" > To: "Yair Zaslavsky" > Cc: "engine-devel" > Sent: Wednesday, February 20, 2013 6:17:43 PM > Subject: Re: [Engine-devel] Engine - top 10 with patches with no activity for > more than 30 days > > On 20/02/2013 18:04, Yair Zaslavsky wrote: > > Hi, > > Why not sending this as a reminder? > > But sending also the gerrit links > > For example, I assume mkolesni sent an engine patch, maybe I as > > someone who also sends patches to engine can review (even if not > > ACK, share some thoughts?) > > ohad wrote a nagios plugin that send alerts on old patches for jenkins repo (currently set for 7 days), i'm guessing it can be enhanced and generalize to handle more projects to to alert on old patches. > > if you want to help and review old patches, just set your gerrit > search > to age:30d and review old patches... > > > Thanks, > > Yair > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "engine-devel" > >> Sent: Wednesday, February 20, 2013 5:39:16 PM > >> Subject: [Engine-devel] Engine - top 10 with patches with no > >> activity for more than 30 days > >> > >> thoughts on how to trim these? > >> (in openstack gerrit they auto-abandon patches with no activity > >> for a > >> couple of weeks - author can revive them back when they are > >> relevant) > >> > >>preferred_email | count > >>--+-- > >>mkole...@redhat.com | 17 > >>rgo...@redhat.com | 12 > >>sesub...@redhat.com | 8 > >>lhorn...@redhat.com | 5 > >>lara...@redhat.com| 4 > >>juan.hernan...@redhat.com | 4 > >>lver...@redhat.com| 4 > >>aw...@redhat.com | 4 > >>mhun...@gmail.com | 3 > >>vsz...@redhat.com | 3 > >> ___ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changing Gerrit -1 message
I tend to agree as well regarding the -1 message, although I think that since -2 blocks your change from, merging it, it should still be strict. Perhaps we could consider adding one more negative value? Regards, Maor On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote: > I like most of these proposals. It'll make gerrit friendlier :-) > > - Original Message - >> From: "Itamar Heim" >> To: "Laszlo Hornyak" >> Cc: engine-devel@ovirt.org >> Sent: Wednesday, February 20, 2013 9:32:53 AM >> Subject: Re: [Engine-devel] Changing Gerrit -1 message >> >> On 19/02/2013 12:06, Laszlo Hornyak wrote: >>> Hi, >>> >>> I agree with that. >>> >>> for the - messages this in my opinion would be both more clear and >>> friendly: >>> -1: In my opinion it needs work. >> >> >> how about >> "-1: Please review my comments" >> >>> -2: I disagree. >> >> "-2: Please reconsider" >> >>> >>> - Original Message - From: "Ofer Schreiber" To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 10:51:15 AM Subject: [Engine-devel] Changing Gerrit -1 message I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself. Any thoughts about a more suitable "-1" message? I thought about "-1 Please fix your code" or something similar. Thanks, Ofer Schreiber ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel >>> ___ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> ___ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Changing Gerrit -1 message
- Original Message - > From: "Maor Lipchuk" > To: engine-devel@ovirt.org > Sent: Thursday, February 21, 2013 12:25:57 AM > Subject: Re: [Engine-devel] Changing Gerrit -1 message > > I tend to agree as well regarding the -1 message, although I think > that > since -2 blocks your change from, merging it, it should still be > strict. > Perhaps we could consider adding one more negative value? > In my opinion, adding another negative value isn't so friendly... we should be more positive and not negative :-) I liked the "-1: Please review my comments" proposed below. I think the current "-2: do not submit" is pretty polite If you guys think it requires a change, then I'd change it to: "-2: do not submit. Please review my comments." Oved > Regards, > Maor > > On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote: > > I like most of these proposals. It'll make gerrit friendlier :-) > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "Laszlo Hornyak" > >> Cc: engine-devel@ovirt.org > >> Sent: Wednesday, February 20, 2013 9:32:53 AM > >> Subject: Re: [Engine-devel] Changing Gerrit -1 message > >> > >> On 19/02/2013 12:06, Laszlo Hornyak wrote: > >>> Hi, > >>> > >>> I agree with that. > >>> > >>> for the - messages this in my opinion would be both more clear > >>> and > >>> friendly: > >>> -1: In my opinion it needs work. > >> > >> > >> how about > >> "-1: Please review my comments" > >> > >>> -2: I disagree. > >> > >> "-2: Please reconsider" > >> > >>> > >>> - Original Message - > From: "Ofer Schreiber" > To: engine-devel@ovirt.org > Sent: Tuesday, February 19, 2013 10:51:15 AM > Subject: [Engine-devel] Changing Gerrit -1 message > > I feel that the current "-1 I would prefer that you didn't > submit > this" message in Gerrit is pretty rude, as usually those -1 > reviews > are just small fix-ups in the code itself. > > Any thoughts about a more suitable "-1" message? > I thought about "-1 Please fix your code" or something similar. > > Thanks, > Ofer Schreiber > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>> ___ > >>> Engine-devel mailing list > >>> Engine-devel@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> > >> ___ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > ___ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
