On 12 March 2013 13:05, Frank Shearar <[email protected]> wrote: > On 12 March 2013 02:41, Igor Stasenko <[email protected]> wrote: >> On 11 March 2013 22:06, Frank Shearar <[email protected]> wrote: >>> On 11 March 2013 19:00, Igor Stasenko <[email protected]> wrote: >>>> On 11 March 2013 19:06, Frank Shearar <[email protected]> wrote: >>>>> On 11 March 2013 17:54, Igor Stasenko <[email protected]> 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.
