[Pharo-project] Code review tools?
Hello, here is some thoughts what i would like to have.. one day. imagine guy A did some change(s) to code, and guy B wants to review it. Currently we having only one tool which helps a little: MC diff viewer.. but main tool is still human.. And it is quite tedious for guy B to go somewhere, copy pieces of code and/or comment on things.. what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy. Going further, and integrating this into pharo development process, as one guy (stef) said: automation is good, but no changes should be made into image unless at least one human took a look at it. So, i thinking if we could have more streamlined review process, this could help a bit (or a lot).. because personally, for me it is tedious today, because integrator or reviewer has to do many things manually, which is not fun and takes too much precious time :) I imagining something like opening a window, pressing "get list of pending reviews from bug tracker" and then selecting a change, review it and pressing "approve or disapprove" which then will trigger the rest of automatic things like integration into image and/or putting entry into bug tracker with reviewer comments. -- Best regards, Igor Stasenko.
Igor Stasenko wrote
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc ----- Cheers, Sean -- View this message in context: http://forum.world.st/Code-review-tools-tp4676066p4676068.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 11 March 2013 02:19, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc
It's probably less work to get tools working with github than it is to re-invent an in-image github. frank
Sean
On 2013-03-11, at 09:09, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 02:19, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc
It's probably less work to get tools working with github than it is to re-invent an in-image github.
there is torch http://soft.vub.ac.be/torch/Home.html by Verónica Uquillas Gómez which I presume does most of the things you want. AFAIK it doesn't run on 2.0 yet, maybe I am wrong ;). Besides that we have Erwann doing and internship here working on validation of Configurations, which is also going into the same direction. The we have CodeCritics for validating code, which BTW is already in the image.
On 11 March 2013 09:09, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 02:19, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc
It's probably less work to get tools working with github than it is to re-invent an in-image github.
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
frank
Sean
-- Best regards, Igor Stasenko.
On 11 March 2013 13:34, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 09:09, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 02:19, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
This would be very cool. For me, this is one of github's killer features. Dale and I were having conversations about particular statements right in the diff for the commit. What makes it even more crazy is that there is markup to hyperlink to issues/users/etc
It's probably less work to get tools working with github than it is to re-invent an in-image github.
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow? frank
frank
Sean
-- Best regards, Igor Stasenko.
2013/3/11 Frank Shearar <frank.shearar@gmail.com>
On 11 March 2013 13:34, Igor Stasenko <siguctua@gmail.com> wrote:
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow?
I totally agree on that. But Github is great if your project is open source or you're willing to pay for private repos. On the other hand, BitBucket.org has free private repositories. But it doesn't have code review. In my case it is not a required feature, and I'd go for the already implemented Github alternative. Every time I see smalltalkers forking away from established mainstream solutions/practices I hear a big noise inside my head. On the opposite, whenever I see stuff like the CI integrations, FileTree, standards compliance, and so on, I'm really happy. Regards, Esteban.
On Mar 11, 2013, at 4:05 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/3/11 Frank Shearar <frank.shearar@gmail.com>
On 11 March 2013 13:34, Igor Stasenko <siguctua@gmail.com> wrote:
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow?
I totally agree on that. But Github is great if your project is open source or you're willing to pay for private repos. On the other hand, BitBucket.org has free private repositories. But it doesn't have code review.
In my case it is not a required feature, and I'd go for the already implemented Github alternative.
Every time I see smalltalkers forking away from established mainstream solutions/practices I hear a big noise inside my head. On the opposite, whenever I see stuff like the CI integrations, FileTree, standards compliance, and so on, I'm really happy.
Do you know when monticello was invented? and working for real? Stef
2013/3/11 stephane ducasse <stephane.ducasse@free.fr>:
Every time I see smalltalkers forking away from established mainstream solutions/practices I hear a big noise inside my head. On the opposite, whenever I see stuff like the CI integrations, FileTree, standards compliance, and so on, I'm really happy.
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess. Why? Regards! Esteban.
On 11 March 2013 16:28, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/3/11 stephane ducasse <stephane.ducasse@free.fr>:
Every time I see smalltalkers forking away from established mainstream solutions/practices I hear a big noise inside my head. On the opposite, whenever I see stuff like the CI integrations, FileTree, standards compliance, and so on, I'm really happy.
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess.
Why?
Presumably because it predates git :) But I think 2003 is the actual birth year. But the counter argument is trivial: how many people use Monticello? (At most, hundreds. In comparison to at least 10s of thousands using git.) Does Monticello actually use any of the special syntax-awareness it's supposed to bring to the table? (No.) But the counter-counter argument is "it's good enough". (I disagree, but I accept the argument that it does work well enough to actually get stuff done, even if code review in Smalltalk is currently way harder than in Ruby or Clojure, the other languages in which I most commonly program. And they're so easy to code review because being git-friendly allows me to see diffs and discuss diffs and use all manner of cool tools that hook into git.) frank
Regards!
Esteban.
Sorry I do not have the time to discuss. Busy writing report. Our goal is to make sure that people can use Pharo to build real application. Of course we would love to be as big as ruby and have 1000 of contributors. So far this is not the case so ⦠Still by focusing on key assets we are making progress. Stef
Every time I see smalltalkers forking away from established mainstream solutions/practices I hear a big noise inside my head. On the opposite, whenever I see stuff like the CI integrations, FileTree, standards compliance, and so on, I'm really happy.
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess.
Why?
Presumably because it predates git :) But I think 2003 is the actual birth year.
But the counter argument is trivial: how many people use Monticello? (At most, hundreds. In comparison to at least 10s of thousands using git.) Does Monticello actually use any of the special syntax-awareness it's supposed to bring to the table? (No.)
But the counter-counter argument is "it's good enough". (I disagree, but I accept the argument that it does work well enough to actually get stuff done, even if code review in Smalltalk is currently way harder than in Ruby or Clojure, the other languages in which I most commonly program. And they're so easy to code review because being git-friendly allows me to see diffs and discuss diffs and use all manner of cool tools that hook into git.)
frank
Regards!
Esteban.
Presumably because it predates git :) But I think 2003 is the actual birth year.
yet it shares almost the same model as git does. Sadly the tools don't make proper use of it :). But that means that Monticello as a model isn't that bad.
But the counter argument is trivial: how many people use Monticello? (At most, hundreds. In comparison to at least 10s of thousands using git.) Does Monticello actually use any of the special syntax-awareness it's supposed to bring to the table? (No.)
indeed, that is one of the arguments that make git support for smalltalk absolutely feasible. And even if there is going to be special object support, I think we can store that in separate binary blobs if necessary.
But the counter-counter argument is "it's good enough". (I disagree, but I accept the argument that it does work well enough to actually get stuff done, even if code review in Smalltalk is currently way harder than in Ruby or Clojure, the other languages in which I most commonly program. And they're so easy to code review because being git-friendly allows me to see diffs and discuss diffs and use all manner of cool tools that hook into git.)
I would love to run different branches on that topic: - in image tools (such as torch) - versioning model (such as git) those two are basically orthogonal, but if you have a look at torch you see that there is already quite a complex and rich tool available for Pharo. It needs polishing I guess and depends on too many external packages, but it is there and can server as a very good basis to go further. For the versioning model we're running multiple branches as well: - git (slow progress) - libgit bindings - filetree as a dialect agnostic fileout format (mostly completed)
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess.
Why?
because pay attention when you talk about smalltalker reinventing the wheel. So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't. So if you want Pharo to make progress, contribute. Simple easy and with measurable impact. Stef
Regards!
Esteban.
On 11 March 2013 16:39, stephane ducasse <stephane.ducasse@free.fr> wrote:
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess.
Why?
because pay attention when you talk about smalltalker reinventing the wheel. So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't.
In 2003, Monticello was the only game in town. It's now 10 years later. You need to reevaluate your decisions sometimes. Concentrating on application level stuff at the expense of infrastructure comes at a cost. In particular, spending time on better code review tools will in the long run accelerate your development velocity. This is supposed to be a key Pharo trait. Now note: I said "spending time". That MIGHT mean reinventing github's features. That MIGHT mean giving Camillo and friends free reign to integrate git into a Pharoer's workflow. But this kind of passive aggressive attitude is seriously counterproductive. Because you're _not_ just telling people to shut up and contribute. You're just telling people to shut up. At any rate, Esteban, people _are_ working on Smalltalk/github integration. Some of them are actually Pharo devs! frank
On Mar 11, 2013, at 6:04 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 16:39, stephane ducasse <stephane.ducasse@free.fr> wrote:
Do you know when monticello was invented? and working for real?
Around 2004-2005 as far as I remember. And working for real at that very moment, I guess.
Why?
because pay attention when you talk about smalltalker reinventing the wheel. So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't.
In 2003, Monticello was the only game in town. It's now 10 years later. You need to reevaluate your decisions sometimes. Concentrating on application level stuff at the expense of infrastructure comes at a cost.
Apparently you did not read the documentation I wrote about the Pharo vision :) too bad because I wrote it so that people understand that we are focusing on infrastructure. This is already 3 years that we are focusing infrastructure. I suggest that you have a serious look at what we are doing.
In particular, spending time on better code review tools will in the long run accelerate your development velocity.
Yes may be
This is supposed to be a key Pharo trait. Now note: I said "spending time". That MIGHT mean reinventing github's features. That MIGHT mean giving Camillo and friends free reign to integrate git into a Pharoer's workflow.
But this kind of passive aggressive attitude is seriously counterproductive. Because you're _not_ just telling people to shut up and contribute. You're just telling people to shut up.
Ahhhh you were talking to esteban :)
At any rate, Esteban, people _are_ working on Smalltalk/github integration. Some of them are actually Pharo devs!
frank
2013/3/11 stephane ducasse <stephane.ducasse@free.fr>:
because pay attention when you talk about smalltalker reinventing the wheel. So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't.
Well... Eclipse was a mutation from VisualAge... it took the best parts of it. So in that case they did exactly that. I don't want an Eclipse IDE Plugin for Pharo. I expect the Pharo team to do that? Of course not! But I wont deny I think it could be a good selling point.
So if you want Pharo to make progress, contribute. Simple easy and with measurable impact.
I totally agree with that. On the other hand there's no need to be harsh, we're all on the same side, but please consider that contributing with a project is not only a matter of producing code. Getting people aboard by advocating its use also helps. IMHO, The user base is as important as the features. Regards, Esteban.
On Mar 11, 2013, at 6:09 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/3/11 stephane ducasse <stephane.ducasse@free.fr>:
because pay attention when you talk about smalltalker reinventing the wheel. So far with this argument we could say that we should all use eclipse because Java invented the ide, isn't.
Well... Eclipse was a mutation from VisualAge... it took the best parts of it. So in that case they did exactly that. I don't want an Eclipse IDE Plugin for Pharo. I expect the Pharo team to do that? Of course not! But I wont deny I think it could be a good selling point.
So if you want Pharo to make progress, contribute. Simple easy and with measurable impact.
I totally agree with that.
On the other hand there's no need to be harsh,
I'm not harsh :) Believe the day where I will be harsh you will feel it.
we're all on the same side, but please consider that contributing with a project is not only a matter of producing code.
Sure You have blogs, tests, chapter, documentation, doing presentation in various audienceâ¦â¦
Getting people aboard by advocating its use also helps. IMHO, The user base is as important as the features.
Totally true.
Regards,
Esteban.
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow?
how many man month engineer time do you have free for that? Personally I prefer that FFI VM vector graphics ⦠get pushed. So git integration will come but on people free time. Stef
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow?
how many man month engineer time do you have free for that? Personally I prefer that FFI VM vector graphics ⦠get pushed.
So git integration will come but on people free time.
So I see, your git allergies haven't stopped yet
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git. okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser . -- Best regards, Igor Stasenko.
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish. But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care. frank
On Mar 11, 2013, at 7:06 PM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line.
But if igor would concentrate on the command line I would hit him with something else :)
You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
Frank, do not say that because you do not know that igor would love to use git to manage the VM code. So do not generalise, life is complex.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I'm waiting for this day :)
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
frank
-- Best regards, Igor Stasenko.
On 11 March 2013 19:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed. So if I can summarise, * git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is. But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code. Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.) frank
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
Oh yes and me too. Because the git model is open and svn not.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed.
So if I can summarise,
* git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is.
But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code.
Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.)
frank
On 11 March 2013 22:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 19:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed.
So if I can summarise,
* git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is.
So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources.. But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK.. now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks.. yes, maybe it is too complicated/idealistic .. propose yours.
But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code.
Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.)
Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image.
frank
-- Best regards, Igor Stasenko.
On 12 March 2013 02:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 22:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 19:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed.
So if I can summarise,
* git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is.
So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources..
But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK..
now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks..
yes, maybe it is too complicated/idealistic .. propose yours.
But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code.
Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.)
Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image.
I'll have to disagree with you there: reviewing diffs covers the most important of my requirements, and github's webhooks covers the rest: * does this pull request pass all its tests? * is the test coverage sufficient? * when it gets merged in, will the new master pass all its tests? I _do_ agree that for more advanced review - tinkering around with the pull request - you'd need to be inside an image, running the code. But I don't see how you can't have that with github. Your webhook calls out to the CI, which constructs you a clean image with the pull request merged in, and you download that image. You could set up your browser to run that artifact directly off the link. So your workflow would be: * get a mail that someone's opened a pull request * open up your browser * check the commit status of the pull request - if it's red, reject the pull request. * assuming the commit's green, click on the "details" link in the status * you've set up that webhook to display the artifact itself in the link, so that downloads the image and it starts running. * you do whatever you need to do to verify the change. (Perhaps the constructed image has a bunch of analysis/review tools preloaded.) * you accept or reject the pull request in your browser But this presupposes that you've spent some time on * getting a git backend set up (not hard: filetree and gitocello already do this; it boils down to new McStReader/Writers) * figuring out how exactly you construct an image from the sources. That second step's the harder of the two, but I'd have thought not _too_ hard given the work on bootstrapping Pharo? frank
On 12 March 2013 13:05, Frank Shearar <frank.shearar@gmail.com> wrote:
On 12 March 2013 02:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 22:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 19:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed.
So if I can summarise,
* git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is.
So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources..
But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK..
now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks..
yes, maybe it is too complicated/idealistic .. propose yours.
But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code.
Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.)
Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image.
I'll have to disagree with you there: reviewing diffs covers the most important of my requirements, and github's webhooks covers the rest: * does this pull request pass all its tests? * is the test coverage sufficient? * when it gets merged in, will the new master pass all its tests?
I _do_ agree that for more advanced review - tinkering around with the pull request - you'd need to be inside an image, running the code. But I don't see how you can't have that with github. Your webhook calls out to the CI, which constructs you a clean image with the pull request merged in, and you download that image. You could set up your browser to run that artifact directly off the link. So your workflow would be:
* get a mail that someone's opened a pull request * open up your browser * check the commit status of the pull request - if it's red, reject the pull request. * assuming the commit's green, click on the "details" link in the status * you've set up that webhook to display the artifact itself in the link, so that downloads the image and it starts running. * you do whatever you need to do to verify the change. (Perhaps the constructed image has a bunch of analysis/review tools preloaded.) * you accept or reject the pull request in your browser
But this presupposes that you've spent some time on * getting a git backend set up (not hard: filetree and gitocello already do this; it boils down to new McStReader/Writers) * figuring out how exactly you construct an image from the sources.
That second step's the harder of the two, but I'd have thought not _too_ hard given the work on bootstrapping Pharo?
Well, Frank, what i initially proposed is to do something on top of what we currently have. My idea is that code review tools in image can be used universally for any code no matter where it goes from. But you diverting discussion whether we should drop everything we did so far (jenkins setup, issue tracker etc), the whole infrastructure ecosystem we built over last few years and migrate to github... That will not happen, because there's a lot of inertia and amount of work to do. So, we should think how we can introduce things gradually and then at one day we will get there..
frank
-- Best regards, Igor Stasenko.
On 12 March 2013 17:46, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 March 2013 13:05, Frank Shearar <frank.shearar@gmail.com> wrote:
On 12 March 2013 02:41, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 22:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 19:00, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 March 2013 19:06, Frank Shearar <frank.shearar@gmail.com> wrote:
On 11 March 2013 17:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
Camillo needs to hit you around the head with a command line. You haven't used it. You've heard several people who have used both Monticello and git extensively say that git beats the crap out of Monticello. Go and learn git properly. THEN come back and maybe we can have a conversation.
I always using git from command line. And let me remind you it was me who created Cog mirrors on gitorious.. so, you shoot into the sky here. But i want more than that.. and why i happy to see that github proposes more on top, i do not really see how you can integrate that with usual workflow of smalltalk developer (means navigating/debugging living code in image).
OK, fair enough. I had indeed forgotten about your gitorious work, and in fact if I recall correctly you tried to pushed the VM folk into moving from subversion to git. My apologies.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
I do believe you ought to take a moment and go read the archives. Also, I happen to nearly violently disagree with the file-per-method approach, but that's an entirely different kettle of fish.
But you know what, just forget it. It's not your problem, other people are already solving the problem, and one day hopefully you'll forget all about this while quietly your tools happily use git under the hood, where you neither know nor care.
I actually don't care where files stored , in what format and what service it using. I want to make my life easier integrating those services with image, so i could, without switching contexts (like between image/web browser), do my work faster and more efficient.
Yes, agreed.
So if I can summarise,
* git is not an answer for you because you don't care about the format source is stored in. * git is an answer for me because it immediately gives you a fantastic user interface and hooks into just about everything. * github is not an answer for you because it doesn't provide you with any tools more advanced than a diff * github is an answer for me because you can always implement your own hooks for triggering CI, arbitrary code analysis, etc. Github's commit API will let you give the green light or red light to any commit so you can see at a glance how good a pull request is.
So, lets get back to the topic. Right now we have more or less same with MC + jenkins.. yes.. it may be ugly and inferior etc.. but if we compare human resources..
But see, the model right now is that to review the code, i must go to bug tracker/git (or if it is commit in some other project, go to that project repo) and manually load code from there.. and then after i loaded it into image, fun begins.. except that after review i have few choices: - send mail to author that his work sucks - say, code is fine and go back to web page, click here and there and mark it as OK..
now what i want is a tool which could help me to put a comments as i looking at code and then when i done, package that and upload where i want.. then other guy can load it into image and see my remarks..
yes, maybe it is too complicated/idealistic .. propose yours.
But of course there's nothing stopping one using github OR an-image tools. (Or tools that produce custom images based on github commits that run analyses and then persist somewhere so you can (a) see the analyses immediately and (b) play around with the code.
Mainly I think it's a mistake to reinvent tech _just because_ you simply must work in an image. That's the core behind my moaning. (And yes, I am working on addressing these issues, so I'm not _just_ moaning.)
Yes, please.. but i hope you agree with me, that reviewing smalltalk code on web page or in text/diff viewer is not something you can do, if you wanna do it for real, not just looking for typos :) For doing it for real, you need an image.
I'll have to disagree with you there: reviewing diffs covers the most important of my requirements, and github's webhooks covers the rest: * does this pull request pass all its tests? * is the test coverage sufficient? * when it gets merged in, will the new master pass all its tests?
I _do_ agree that for more advanced review - tinkering around with the pull request - you'd need to be inside an image, running the code. But I don't see how you can't have that with github. Your webhook calls out to the CI, which constructs you a clean image with the pull request merged in, and you download that image. You could set up your browser to run that artifact directly off the link. So your workflow would be:
* get a mail that someone's opened a pull request * open up your browser * check the commit status of the pull request - if it's red, reject the pull request. * assuming the commit's green, click on the "details" link in the status * you've set up that webhook to display the artifact itself in the link, so that downloads the image and it starts running. * you do whatever you need to do to verify the change. (Perhaps the constructed image has a bunch of analysis/review tools preloaded.) * you accept or reject the pull request in your browser
But this presupposes that you've spent some time on * getting a git backend set up (not hard: filetree and gitocello already do this; it boils down to new McStReader/Writers) * figuring out how exactly you construct an image from the sources.
That second step's the harder of the two, but I'd have thought not _too_ hard given the work on bootstrapping Pharo?
Well, Frank, what i initially proposed is to do something on top of what we currently have. My idea is that code review tools in image can be used universally for any code no matter where it goes from. But you diverting discussion whether we should drop everything we did so far (jenkins setup, issue tracker etc), the whole infrastructure ecosystem we built over last few years and migrate to github...
That will not happen, because there's a lot of inertia and amount of work to do. So, we should think how we can introduce things gradually and then at one day we will get there..
On the one hand you need these fancy review/merge tools... which github _largely_ gives you, but you'd have to write some code to use git properly. (*) Or you can write the fancy review/merge tools yourself. You're saying "wow, it really sucks the way we have to work" and I'm saying "wow, it's so easy to review/merge code on github" and you're saying "gosh, we have to throw everything away!". No, you don't. Keep your CI; it's better by far than Travis's, and you just write a webhook for github to trigger builds. Keep your issue tracker; it's better than github's. Now does github give you super static analysis tools? Does it do k-CFA to check your types are what you think they are? No. It _does_ give you a really slick code review process into which you can plug anything you want, and you can record the outcome of all those analyses in a simple red/green commit status on every commit in the pull request. So, to take another tack, what kind of tools do you find you have to have to conduct a proper review? I can imagine a bunch of automated tests ("did coverage decrease since the last run?" for instance), but those are uninteresting - if they're automated you shouldn't be doing them, but merely reviewing their output. frank (*) I don't think this is very hard: I knocked up an InstallerGitHub that pulls source from an arbitrary commit (so tag, branch name, commit id) from a github repository in chunk format (need to support filetree still, which is why I've not released anything yet). So I can imagine a webhook that when pinged will take a Squeak trunk, run Installer github user: 'frankshearar repository: 'Zippers'; install: 'ConfigurationOfZippers'. (Smalltalk at: #ConfigurationOfZippers) load. "Run the tests, and ping back to github the commit status" frank
On 2013-03-11, at 18:54, Igor Stasenko <siguctua@gmail.com> wrote:
pff... really people... i am thinking how to streamline our existing development process.. and instead i hear once again about git.
okay, lets throw away MC & stuff, migrate everything on file-based file-per-method git repository
I can repeat this slowly for you, because even if you sit 1m away from me you seem to not hear me: 1. git for smalltalk is mostly going to be a backend 2. if we migrate to git it is going to be a fluent step by step process 3. you don't like file based?? what the heck does monticello store? right, zips, with what inside? right some strangely serialized data that is highly inefficient for parsing. 4. If smalltalk want's to be visible and every play along with other people we have to get out of the image, that implies file-based sources. 5. I don't care about git particularly, but it is what I know best, any other distributed versioning system does the trick here.
and then navigate diffs on github, and trying to find senders or implementors of selector using web browser .
tricky counter question: have you ever tried a diff of two mczs? without a running pharo image? right, doesn't work. So even with monticello you need decent image-based tools to accomplish things. So why not using something else than our highly exotic versioning backend. so no igor, most of your arguments are very invalid here.
Let me clarify: - i am 10000% not against git i am for it. - what i am against is treating a source as a bunch of static files.. like github does. so, if you telling me that we should not reinvent the wheel and use github code review features, i would encourage you to explain me how you see that process, staring at web page and having no ability to navigate the code in a way how you navigating smalltalk code in image. And think, how good the quality of your reviews will be is you will be crippled by "static source code" approach. For me git as a backend is a way to go. But it looks like people misunderstood my original proposal, because git is orthogonal to what i want: i want more integration with issue tracker but more than that, i would love to have a tool which could create a reviews so i can send them to author or to bug tracker... and for creating a review i just need two versions of code.. and it is completely unimportant where those two versions come from: git, .cs, or .mcz files. -- Best regards, Igor Stasenko.
On Mar 11, 2013, at 6:17 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
i am very happy that github exists.. and its features available only if you put code there.. but if code is not on github, then what you will do?
To rephrase the question: what do we still need to do before we can integrate (something like) github into a standard Smalltalk workflow?
how many man month engineer time do you have free for that? Personally I prefer that FFI VM vector graphics ⦠get pushed.
So git integration will come but on people free time.
So I see, your git allergies haven't stopped yet
No I'm not allergic. Get it working and I will use it. Now when I think about synectique or other projects I prefer to focus on offering something that work on important areas. Where is a decent FFI simple to use? Can we get a stable VM? Why do I have to spend hour trying to understand menusâ¦. Where is a decent UIBuilder? So my priority are into making the minimum works well. Stef
It is a good idea for GSoC. -- Best regards, Dennis Schetinin 2013/3/11 Igor Stasenko <siguctua@gmail.com>
Hello,
here is some thoughts what i would like to have.. one day.
imagine guy A did some change(s) to code, and guy B wants to review it.
Currently we having only one tool which helps a little: MC diff viewer.. but main tool is still human.. And it is quite tedious for guy B to go somewhere, copy pieces of code and/or comment on things..
what would be really cool to have is to integrate some steroids into diff viewer where guy B can press "create a review report" and write his comments directly under selected change .. then post it somewhere on web (or send emal), so guy A can see directly which of his changes made guy B unhappy.
Going further, and integrating this into pharo development process, as one guy (stef) said: automation is good, but no changes should be made into image unless at least one human took a look at it.
So, i thinking if we could have more streamlined review process, this could help a bit (or a lot).. because personally, for me it is tedious today, because integrator or reviewer has to do many things manually, which is not fun and takes too much precious time :)
I imagining something like opening a window, pressing "get list of pending reviews from bug tracker" and then selecting a change, review it and pressing "approve or disapprove" which then will trigger the rest of automatic things like integration into image and/or putting entry into bug tracker with reviewer comments.
-- Best regards, Igor Stasenko.
participants (8)
-
Camillo Bruni -
Dennis Schetinin -
Esteban A. Maringolo -
Frank Shearar -
Igor Stasenko -
Sean P. DeNigris -
stephane ducasse -
Sven Van Caekenberghe