recommenders-dev http://dev.eclipse.org/mhonarc/lists/recommenders-dev/maillist.html recommenders-dev en-us Fri, 24 May 2013 20:10:06 GMT Fri, 24 May 2013 20:10:06 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) recommenders-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/recommenders-dev/maillist.html [recommenders-dev] Mapping ProposalKind to CompletionEvent http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01021.html Hello,it is possible to find the corresponding CompletionEvent to a ProposalKind?Code example: StatisticsPreferencePage#appendNumberOfCompletionsByCompletionKind At line 246 I have only the ProposalKind and need the corresponding CompletionEvent.;Regards,T... Hello,

it is possible to find the corresponding CompletionEvent to a ProposalKind?

Code example: StatisticsPreferencePage#appendNumberOfCompletionsByCompletionKind
At line 246 I have only the ProposalKind and need the corresponding CompletionEvent. 

Regards,
Tim
]]> Fri, 24 May 2013 20:01:05 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01021.html achmetow84@xxxxxxx (Timur Achmetow) Re: [recommenders-dev] Mangement of third party dependencies http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01020.html Hi all, the result of this experiment can be found in Gerrit [1]. Important points have been marked with inline comments. One thing in particular that is not entirely clear to me is how the participants of a release train like Kepler decide on a version of... Hi all, > I'll give the different *.target files approach a spin over the weekend, > building with all three profiles, and see how that goes and whether I > get get away without having to specify qualifiers (which is annoying, I > agree). the result of this experiment can be found in Gerrit [1]. Important points have been marked with inline comments. One thing in particular that is not entirely clear to me is how the participants of a release train like Kepler decide on a version of Orbit dependencies to use. (I know that they release milestone builds one week prior to Sim-Rel builds [2], but even then this leaves the question of which version everyone is using.) Marcel, maybe you can help me out here. Best wishes, Andreas [1] <https://git.eclipse.org/r/#/c/12989/> [2] <http://wiki.eclipse.org/Orbit/Promotion%2C_Release%2C_and_Retention_Policies> -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: +49-170-811-3791 http://www.codetrails.com/ Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ]]> Mon, 20 May 2013 17:07:11 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01020.html andreas.sewe@xxxxxxx (Andreas Sewe) [recommenders-dev] Away notice... http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01019.html Hi committers, Hi GSOC students, I just wanna send a short heads up and let you know that I'm away until 07.06. on my Honeymoon. For anything related to GSOC Andreas can help you and answer your questions. Just send your questions to the list instead of to... Hi committers, Hi GSOC students, I just wanna send a short heads up and let you know that I'm away until 07.06. on my Honeymoon. For anything related to GSOC Andreas can help you and answer your questions. Just send your questions to the list instead of to me. I wish you all the best for you applications! Best, Marcel -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: 0179 131 77 21 http://www.codetrails.com Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ]]> Sun, 19 May 2013 05:05:18 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01019.html marcel.bruch@xxxxxxx (Marcel Bruch) Re: [recommenders-dev] Mangement of third party dependencies http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01018.html Hi Marcel, great to see such a lengthy proposal but I fear I need to toy around with this some more before I can you give a really solid answer. Sorry. That being said, there us one thing I am really curious about (and where I am surprised that it didn't b... Hi Marcel, great to see such a lengthy proposal but I fear I need to toy around with this some more before I can you give a really solid answer. Sorry. That being said, there us one thing I am really curious about (and where I am surprised that it didn't bite us yet): Why do we build to o.e.r.feature.3rd.orbit features (one 1.0.4 from the Eclipse build and one 0.1.0 from build.codetrails.com)? This name clash seems dangerous to me and I'd like to understand the existence of *two* Orbit 3rd party dependency features a bit better. > Andreas was asking whether we should use fixed version in our features. > In general, I'd say yes but this will cause a lot of extra trouble. I > don't know out of my head whether we have to specify the qualifier in > the feature.xml too to make the build work. But when we we have to > specify the qualifier, every change in a qualifier will break our build. > This will get annoying pretty soon. I think we should test (or someone > can already tell me?) whether the qualifier is required. Fixing the version in the feature.xml was the solution (workaround, really, as yesterday's fixing of the build was quite stressful) I came up with yesterday. In the longer run, however, I think that fixing the versions in the target definitions makes more sense. Here's why: - Fixing the version in the feature.xml while leaving the version unconstrained in the *.target means that any update sites therein (currently we have 3(!) target definitions) need to supply the exact same version. This restricts us to the versions that where available for the Juno release even when targeting Luna. - Fixing the version in the *.target would allow us to selected different versions of the same library in different build profiles. The feature would, with a 0.0.0 "constraint" simply pick up the version from the current target definition. This would make it possible to bundle SLF4J 1.6.4 with our Juno-compatible builds and 1.7.2 with our Kepler-compatible builds. Of course this requires that the libraries are sufficiently compatible. If not, a *declared* version constraint in our plugins' MANIFEST.MFs should fail the build. Either way, fixing versions in *.target or feature.xml ensures that we honor our IP log obligations, namely to only use approved versions of our dependencies. Leaving them unconstrained everywhere just asks for trouble. > To summarize, > the core changes over the current approach I propose ATM are (i) the > as-is p2 repository (marked orange in the illustration) and (ii) the > publishing to particular download folders. > > Andreas, what do you think? I'll give the different *.target files approach a spin over the weekend, building with all three profiles, and see how that goes and whether I get get away without having to specify qualifiers (which is annoying, I agree). I'll report back on the list. Andreas -- Codetrails.com – The knowledge transfer company ]]> Sat, 18 May 2013 11:11:40 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01018.html andreas.sewe@xxxxxxx (Andreas Sewe) [recommenders-dev] Mangement of third party dependencies http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01017.html hi,yesterday we had some trouble with updating our dependency to SLF4J from 1.6.5 to 1.7.2. The update was required because 1.6.5 caused some unexpected trouble with the Kepler release train [1]. After quite a few problems with the current system, Andreas ...
hi,

yesterday we had some trouble with updating our dependency to SLF4J from 1.6.5 to 1.7.2. The update was required because 1.6.5 caused some unexpected trouble with the Kepler release train [1]. After quite a few problems with the current system, Andreas finally could fix this issue (Thanks Andreas!) but the demand for changing the way how we manage our 3rd part dependencies is bigger than ever.


The current process of adding a 3rd party lib to our build is as follows:

  • In our 3rd git repo, add a new project with the bundle's name (e.g., com.google.guava).
  • In this project, add the class files as bin folders to the project and classpath (only class files, no sources.)
  • Update or create the required OSGI metadata
  • Add the plugin to the 3rd feature
  • Add and update the pom files
  • Push to 3rd git repo. Let Jenkins pick up the changes and publish the new 3rd p2 repo.
  • Done.

At the moment we build this site with maven tycho 0.13 - which fails on some machines and thus makes the release quite painful. So there is a need to update things.


So here is my proposal.

First, we update the build to Tycho 0.17. Then we add a manually maintained "local as-is" p2 repository which contains ready to use osgified libs only. New bundles are just copied into and the p2 repository metadata is regenerated with the p2 publisher.

Then there is a git repository that contains the projects that need to be build from scratch (already exists). This includes all our not-yet osgified or patched libs as well as all features we need for drive the Eclipse Recommenders builds. It also contains the target platform definition that makes all required p2 update sites know to the tycho build. When the build completes, the resulting p2 update site is published to a certain download folder with the current timestamp and build type in it ("IyyyMMdd-hhmm" usually):




Implications:
Every time we update our dependencies, we have to update the .target files to reflect this change. This isn't great but the alternative of having a single "latest" URL only has proven to work badly in the past.

One question to answer is, how many libs do we want to build with Tycho? Wouldn't it be easier to just patch the zip files directly (i.e, unzip, patch the manifest, zip)? In general I think this would be sufficient in most cases. So, the 3rd git repo may only contains those libs that actually have to be patched and build in a more complicated way. We may consider to use submodules to keep the patched bundles separate from the target and feature definitions.

Andreas was asking whether we should use fixed version in our features. In general, I'd say yes but this will cause a lot of extra trouble. I don't know out of my head whether we have to specify the qualifier in the feature.xml too to make the build work. But when we we have to specify the qualifier, every change in a qualifier will break our build. This will get annoying pretty soon. I think we should test (or someone can already tell me?) whether the qualifier is required.

To summarize,
the core changes over the current approach I propose ATM are  (i) the as-is p2 repository (marked orange in the illustration) and (ii) the publishing to particular download folders.

Andreas, what do you think?

Best,
Marcel







]]> Sat, 18 May 2013 10:46:40 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01017.html marcel.bruch@xxxxxxx (Marcel Bruch) Re: [recommenders-dev] GSOC: Introducing Student Proposals in Blog Posts http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01016.html -- Kavith Thiranga Lokuhewage, Undergraduate, BEng (Hons) Software Engineering, Staffordshire University, UK. APIIT Sri Lanka. Linkedin&#xA0; Twitter _______________________________________________ recommenders-dev mailing list recommenders-dev@xxxxxxxxxxx htt... hi Marcel !

I also want to post my gsoc proposal there and have discussions on the topics related.


On Fri, May 10, 2013 at 11:21 AM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
Hi Dammina,

sorry for the delay. I sent you an invitation to the blog.

Best,
Marcel

On May 7, 2013, at 9:15 AM, Dammina Sahabandu <dmsahabandu@xxxxxxxxx> wrote:

Hi Marcel,
I would like like to publish my proposal too.


On Mon, May 6, 2013 at 11:02 PM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
Hi Patrick,

yes we should. One per day would be good I guess. So you are enqueued  as #4 (Friday morning) :-) Can you prepare your proposal as described before too?

Thanks,
Marcel

On May 6, 2013, at 7:27 PM, Patrick Gottschaemmer <mail@xxxxxxxxxxxxxxxxx> wrote:

Hi,

I'd also like to do this, but I suggest we should leave some 'whitespace' between the blog posts?

Best regards
Patrick

On Mon, 6 May 2013 16:22:30 +0530, kavith Thiranga <rc404mekt@xxxxxxxxx> wrote:
Hi Marcel,

Sure, I will do like that.

Thanks a  lot.




On Mon, May 6, 2013 at 4:19 PM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
Hi Kavith, 

I sent you an invite to the recommenders blog. Please create a new blog post with your content on it + a picture of you. But please do not publish it yet. I'll do some editing on Tuesday afternoon and publish it on Wednesday morning.

Best,
Marcel


On May 6, 2013, at 12:44 PM, kavith Thiranga <rc404mekt@xxxxxxxxx> wrote:

Hi Marcel,

I would love to publish my proposal there. So what should I do?

Thanks


On Mon, May 6, 2013 at 2:08 PM, Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx> wrote:
Hi GSOC applicants,

I'd like to start a blog post series about this year's GSOC proposals on the Code Recommenders blog. Tim was the first student who published his GSOC proposal [1], and if you like to publish your proposal too (to gather some community, getting early feedback on your ideas etc.), let me know.



DISCLAIMER:
Please note that this *by no means* says anything about your proposal status or quality nor how likely Eclipse or Google will accept this proposal. It's about gathering a community for your proposal :-)




Best,
Marcel


[1] http://code-recommenders.blogspot.com/2013/05/usage-data-collection-for-code.html

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Kavith Thiranga Lokuhewage,
Undergraduate,
BEng (Hons) Software Engineering,
Staffordshire University, UK.
APIIT Sri Lanka.

Linkedin  Twitter

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
Kavith Thiranga Lokuhewage,
Undergraduate,
BEng (Hons) Software Engineering,
Staffordshire University, UK.
APIIT Sri Lanka.

Linkedin  Twitter



_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940


_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev




--
_________________________________________________________
Amandeep Singh Mundra
http://about.me/aman.adsm
http://kodevelop.com/
]]> Tue, 14 May 2013 05:50:50 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01016.html aman.adsm@xxxxxxx (Amandeep Singh) Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01015.html -- Codetrails UG (haftungsbeschr&#xC3;nkt)The knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtMobile: 0179 131 77 21http://www.codetrails.comManaging Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940
Hi Marcel:
  I have done a new commit that contains everything and pushed to refs/for/master [1] (with command line git, instead of EGit), but thereâs no code in this page. Iâm wondering that this commit is same with refs/head/master and thus nothing is actually changed, so there would not be any code in [1] for review?
  If this is the case, can we just remove all files and commit (to make refs/head/master empty), then do another commit with all files, so that others can review our code? Or are there any better ways recommended?
 
 
 
Best,
Tong
 
åää: Marcel Bruch
åéæé: â2013âåâ5âæâ13âæ â23â:â03
æää: Recommenders developer discussions
äé: Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit
 
Can you tell which commit is actually not yet in the blessed repository [1]? I see 7 commits already pushed which cannot (easily) be reverted anymore. Actually, I'd say if there is anything to correct just do a new commit that brings everything in a good shape and try to use gerrit properly in this commit. Just abandon the other changes if they are already merged. You probably already know the EGit guide section about working with Gerrit [2].

Best,
Marcel

[1] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git
[2] http://wiki.eclipse.org/EGit/User_Guide#Working_with_Gerrit

On May 13, 2013, at 4:50 PM, <tong.wu.stap@xxxxxxxxx> wrote:

Hi Marcel:
   Thank you very much for your help.

   Iâm so sorry for pushing changes directly to refs/heads/master. At that time I didnât know push to master will avoid the review.  We will abandon these changes.
   Thereâs a change containing old code that has not been accepted (https://git.eclipse.org/r/#/c/10681/), and we want to push our new code to Gerrit. How should we do now? Abandon the change and push another new change?

Thanks!
 
Best,
Tong 
 
 
åää: Marcel Bruch
åéæé: â2013âåâ5âæâ13âæ â21â:â49
æää: Recommenders developer discussions
äé: Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit
 
Hi Tong,

On May 13, 2013, at 1:46 PM, tong.wu.stap@xxxxxxxxx wrote:
>  At first, we just used push like this: 
>  git push ssh://username@xxxxxxxxxxxxxxx:29418/(project).git HEAD:refs/for/master
>  
>  It seems we pushed our change to repo successfully, but when we checked this page (https://git.eclipse.org/r/#/c/10681/), we found nothing changed. So we tried several other methods, like add change-id, and tried to push several times.


the webpage says:
 â Need Verified
 â Need Code-Review
 â Need IP-Clean


I guess that you know that what every you push to Gerrit's "refs/for/*" needs to be reviewed and accepted by  a committer, i.e., someone has to press the "Review" button and approve the change set when satisfied. Please check [1] and related sections for details on how to approve a change and finally push the commit to the blessed repository.

[2] shows me that you pushed these changes to the repository already without going through the review cycle (i.e., not pushing to refs/for/master but directly to refs/heads/master). If this is what you agreed to, that's fine. We usually let someone else look at /review the commit before accepting it.


> Then we found actually we had made some changes on Gerrit, because when we tried to clone the project it was the latest one and also we found this page (https://git.eclipse.org/r/#/c/12736/). Unfortunately there are some useless commits and no source files which should be reviewed by other committers. For the moment we have no idea how to solve this problem. We want to show the new code to others and remove those useless commits. Could you help us? 

You mean the one in Gerrit? How about pressing "abandon change" on the change-set summary page?

Best,
Marcel

[1] http://wiki.eclipse.org/Gerrit#To_approve_a_change
[2] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git/


> 
>  Thank you very much!
> 
> Best wishes,
> Tong
>  
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

]]> Mon, 13 May 2013 16:01:14 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01015.html tong.wu.stap@xxxxxxx (tong.wu.stap) Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01014.html -- Codetrails UG (haftungsbeschr&#xC3;nkt)The knowledge transfer companyRobert-Bosch-Str. 7, 64293 DarmstadtMobile: 0179 131 77 21http://www.codetrails.comManaging Director: Dr. Marcel BruchHandelsregister: Darmstadt HRB 91940 Can you tell which commit is actually not yet in the blessed repository [1]? I see 7 commits already pushed which cannot (easily) be reverted anymore. Actually, I'd say if there is anything to correct just do a new commit that brings everything in a good shape and try to use gerrit properly in this commit. Just abandon the other changes if they are already merged. You probably already know the EGit guide section about working with Gerrit [2].

Best,
Marcel

[1] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git
[2] http://wiki.eclipse.org/EGit/User_Guide#Working_with_Gerrit

On May 13, 2013, at 4:50 PM, <tong.wu.stap@xxxxxxxxx> wrote:

Hi Marcel:
   Thank you very much for your help.

   Iâm so sorry for pushing changes directly to refs/heads/master. At that time I didnât know push to master will avoid the review.  We will abandon these changes.
   Thereâs a change containing old code that has not been accepted (https://git.eclipse.org/r/#/c/10681/), and we want to push our new code to Gerrit. How should we do now? Abandon the change and push another new change?

Thanks!
 
Best,
Tong 
 
 
åää: Marcel Bruch
åéæé: â2013âåâ5âæâ13âæ â21â:â49
æää: Recommenders developer discussions
äé: Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit
 
Hi Tong,

On May 13, 2013, at 1:46 PM, tong.wu.stap@xxxxxxxxx wrote:
>  At first, we just used push like this: 
>  git push ssh://username@xxxxxxxxxxxxxxx:29418/(project).git HEAD:refs/for/master
>  
>  It seems we pushed our change to repo successfully, but when we checked this page (https://git.eclipse.org/r/#/c/10681/), we found nothing changed. So we tried several other methods, like add change-id, and tried to push several times.


the webpage says:
 â Need Verified
 â Need Code-Review
 â Need IP-Clean


I guess that you know that what every you push to Gerrit's "refs/for/*" needs to be reviewed and accepted by  a committer, i.e., someone has to press the "Review" button and approve the change set when satisfied. Please check [1] and related sections for details on how to approve a change and finally push the commit to the blessed repository.

[2] shows me that you pushed these changes to the repository already without going through the review cycle (i.e., not pushing to refs/for/master but directly to refs/heads/master). If this is what you agreed to, that's fine. We usually let someone else look at /review the commit before accepting it.


> Then we found actually we had made some changes on Gerrit, because when we tried to clone the project it was the latest one and also we found this page (https://git.eclipse.org/r/#/c/12736/). Unfortunately there are some useless commits and no source files which should be reviewed by other committers. For the moment we have no idea how to solve this problem. We want to show the new code to others and remove those useless commits. Could you help us? 

You mean the one in Gerrit? How about pressing "abandon change" on the change-set summary page?

Best,
Marcel

[1] http://wiki.eclipse.org/Gerrit#To_approve_a_change
[2] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git/


> 
>  Thank you very much!
> 
> Best wishes,
> Tong
>  
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev

-- 
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

]]> Mon, 13 May 2013 15:03:26 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01014.html marcel.bruch@xxxxxxx (Marcel Bruch) Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01013.html Hi Marcel: Thank you very much for your help. I&#xE2;m so sorry for pushing changes directly to refs/heads/master. At that time I didn&#xE2;t know push to master will avoid the review. We will abandon these changes. p;There&#xE2;s a change containing old code that ...
Hi Marcel:
   Thank you very much for your help.

   Iâm so sorry for pushing changes directly to refs/heads/master. At that time I didnât know push to master will avoid the review.  We will abandon these changes.
   Thereâs a change containing old code that has not been accepted (https://git.eclipse.org/r/#/c/10681/), and we want to push our new code to Gerrit. How should we do now? Abandon the change and push another new change?

Thanks!
 
Best,
Tong 
 
 
åää: Marcel Bruch
åéæé: â2013âåâ5âæâ13âæ â21â:â49
æää: Recommenders developer discussions
äé: Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit
 
Hi Tong,

On May 13, 2013, at 1:46 PM, tong.wu.stap@xxxxxxxxx wrote:
>  At first, we just used push like this:
>  git push ssh://username@xxxxxxxxxxxxxxx:29418/(project).git HEAD:refs/for/master
> 
>  It seems we pushed our change to repo successfully, but when we checked this page (https://git.eclipse.org/r/#/c/10681/), we found nothing changed. So we tried several other methods, like add change-id, and tried to push several times.


the webpage says:
 â Need Verified
 â Need Code-Review
 â Need IP-Clean


I guess that you know that what every you push to Gerrit's "refs/for/*" needs to be reviewed and accepted by  a committer, i.e., someone has to press the "Review" button and approve the change set when satisfied. Please check [1] and related sections for details on how to approve a change and finally push the commit to the blessed repository.

[2] shows me that you pushed these changes to the repository already without going through the review cycle (i.e., not pushing to refs/for/master but directly to refs/heads/master). If this is what you agreed to, that's fine. We usually let someone else look at /review the commit before accepting it.


> Then we found actually we had made some changes on Gerrit, because when we tried to clone the project it was the latest one and also we found this page (https://git.eclipse.org/r/#/c/12736/). Unfortunately there are some useless commits and no source files which should be reviewed by other committers. For the moment we have no idea how to solve this problem. We want to show the new code to others and remove those useless commits. Could you help us?

You mean the one in Gerrit? How about pressing "abandon change" on the change-set summary page?

Best,
Marcel

[1] http://wiki.eclipse.org/Gerrit#To_approve_a_change
[2] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git/


>
>  Thank you very much!
>
> Best wishes,
> Tong
> 
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev

--
Codetrails UG (haftungsbeschrÃnkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: 0179 131 77 21
http://www.codetrails.com

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
]]> Mon, 13 May 2013 14:50:56 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01013.html tong.wu.stap@xxxxxxx (tong.wu.stap) Re: [recommenders-dev] [Please Help] Problems in pushing new code to Gerrit http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01012.html &#x2022; Need Verified &#x2022; Need Code-Review &#x2022; Need IP-Clean I guess that you know that what every you push to Gerrit's &quot;refs/for/*&quot; needs to be reviewed and accepted by a committer, i.e., someone has to press the &quot;Review&quot; button and approve the change set when sat... Hi Tong, On May 13, 2013, at 1:46 PM, tong.wu.stap@xxxxxxxxx wrote: > At first, we just used push like this: > git push ssh://username@xxxxxxxxxxxxxxx:29418/(project).git HEAD:refs/for/master > > It seems we pushed our change to repo successfully, but when we checked this page (https://git.eclipse.org/r/#/c/10681/), we found nothing changed. So we tried several other methods, like add change-id, and tried to push several times. the webpage says: • Need Verified • Need Code-Review • Need IP-Clean I guess that you know that what every you push to Gerrit's "refs/for/*" needs to be reviewed and accepted by a committer, i.e., someone has to press the "Review" button and approve the change set when satisfied. Please check [1] and related sections for details on how to approve a change and finally push the commit to the blessed repository. [2] shows me that you pushed these changes to the repository already without going through the review cycle (i.e., not pushing to refs/for/master but directly to refs/heads/master). If this is what you agreed to, that's fine. We usually let someone else look at /review the commit before accepting it. > Then we found actually we had made some changes on Gerrit, because when we tried to clone the project it was the latest one and also we found this page (https://git.eclipse.org/r/#/c/12736/). Unfortunately there are some useless commits and no source files which should be reviewed by other committers. For the moment we have no idea how to solve this problem. We want to show the new code to others and remove those useless commits. Could you help us? You mean the one in Gerrit? How about pressing "abandon change" on the change-set summary page? Best, Marcel [1] http://wiki.eclipse.org/Gerrit#To_approve_a_change [2] https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.args.git/ > > Thank you very much! > > Best wishes, > Tong > > _______________________________________________ > recommenders-dev mailing list > recommenders-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/recommenders-dev -- Codetrails UG (haftungsbeschränkt) The knowledge transfer company Robert-Bosch-Str. 7, 64293 Darmstadt Mobile: 0179 131 77 21 http://www.codetrails.com Managing Director: Dr. Marcel Bruch Handelsregister: Darmstadt HRB 91940 ]]> Mon, 13 May 2013 13:49:43 GMT http://dev.eclipse.org/mhonarc/lists/recommenders-dev/msg01012.html marcel.bruch@xxxxxxx (Marcel Bruch)