github experiment with Pharo 1.4 ...

Yesterday, I basically got the code for reading and writing the new filetree format[1].

This morning I realized that one might want to organize the Pharo github project a little bit differently than we're used to..It occurred to me that if all of the packages that went into the core image were saved in the same repository (as is done today with the Pharo14 repository), then a developer who wanted to contribute to Pharo, could fork the PharoCore repository, then make bugfixes and issue a pull request when done.. With git, the bugfix can span more than one package and there's no need for creating slices...

So I created a PharoCore repository[2] in Phariverse, then forked the project as myself[3]. I proceeded to make two independent simulated bugfixes[4] and [5] (click on the commit to see the diffs [6][7]).

I then issued a pull request for for the second simulated bugfix[8].

There are two interesting views ... the network graph[9] and the fork queue[10].

The network graph allows you to see what is going on in the forks of the projects and see the relationship between commits that have been done on the primary project and those done in forks.

The fork queue shows the list of all commits that have been done by forks and gives you a chance to view the work that is going on on other forks and to choose to integrate changes ...

The folks who have forked a project have the same opportunity to see the work that is progressing on the main project and integrate chagnes from the primary to the fork ...

It does seem that this model would work pretty well for folks doing development in Pharo ...

Additionally, I have created a Pharo 1.4 image (and changes file) with Metacello and filetree code already installed[11]. I've set things up so you're expected to fork the PharoCore[2] project github then manually clone the git repository to your local disk, then edit (with PharoCore repository location) a script[12] that automatically downloads a copy of the filetree and metacello projects and hooks up the image to the 3 Monticello repositories:

  PharoCore: 'filetree:///opt/git/PharoCore/repository'
  metacello: 'github://dalehenrich/metacello:newPackageFormat/repository'
  filetree:  'github://dalehenrich/filetree:pharoBugFix/repository'

If you are interested this will give you a feel for what development will be like ... you can make changes to any of the pharo core code and commit packages to the filetree PharoCore repository using the Monticello tools, then manually use git to push your changes up to github and...

I plan to provide a Metacello scripting API for at a minimum, defining the location of repositories that you've cloned so that the script[12] doesn't have to be run...I also plan to get the loading of Metacello projects that use github-based projects working as well as a couple of other features, before I think that folks can start using this stuff for real development...

PS: the *verse organizations I've created are just for experimenting, so don't base any production work on them ...

PPS: I haven't got traits implemented in the filetree format, but that's something on the near term todo list, so if a package has traits, and you do a diff against a filetree repo, you'll see that the traits are missing ...

PPPS: I noticed some significant slowness when opening/saving packages in the 1.4 image and at first thought that filetree was slow, but the same delays show up when doing http opens, so it must be something else ... filetree hasn't been optimized (and probably de-optimized from Otto's version) ...

Dale

[1] https://gist.github.com/1892114
[2] https://github.com/Phariverse/PharoCore
[3] https://github.com/dalehenrich/PharoCore
[4] https://github.com/dalehenrich/PharoCore/tree/simulatedIssueBranch
[5] https://github.com/dalehenrich/PharoCore/tree/simulatedIssue2
[6] https://github.com/dalehenrich/PharoCore/commit/5ba3ce4aa5f34a7396641c55ecaa52c08e7283e8
[7] https://github.com/dalehenrich/PharoCore/commit/680df11c9a1062471f72f91535aecde9fdfcd5bd
[8] https://github.com/Phariverse/PharoCore/pull/1
[9] https://github.com/Phariverse/PharoCore/network
[10] https://github.com/Phariverse/PharoCore/forkqueue
[11] https://github.com/downloads/Phariverse/PharoCore/git.PharoCore1.4.zip
[12] https://gist.github.com/1960662

But we will not keep all the packages of pharoCore in pharoCore since step by step we will extract them.
Having one repository is not good.

> Yesterday, I basically got the code for reading and writing the new filetree format[1].
>
> This morning I realized that one might want to organize the Pharo github project a little bit differently than we're used to..It occurred to me that if all of the packages that went into the core image were saved in the same repository (as is done today with the Pharo14 repository), then a developer who wanted to contribute to Pharo, could fork the PharoCore repository, then make bugfixes and issue a pull request when done.. With git, the bugfix can span more than one package and there's no need for creating slices...

But we will always have changes that cross cut so I would not take that as hypothesis
I will check later because I have to run.

Stef

Stef,

I think that giving developers the ability to check out all of the source for Pharo1.4-xxxxxx in one repository and make bugfixes that span multiple packages effortlessly are good things ...

Today you are doing just that with the Pharo1.4 repository on SS3, the only thing that's missing is the ability to check out all of the packages associated with a single "pharo build"...

The Pharo1.4 repository would not be the primary repository ...

Perhaps Cami and I can talk this over in more detail this week...

Dale

----- Original Message -----
| From: "stephane ducasse" <[hidden email]>
| To: [hidden email]
| Sent: Saturday, March 3, 2012 12:33:01 AM
| Subject: Re: [Metacello] github experiment with Pharo 1.4 ...
|
| But we will not keep all the packages of pharoCore in pharoCore since
| step by step we will extract them.
| Having one repository is not good.
|
| > Yesterday, I basically got the code for reading and writing the new
| > filetree format[1].
| >
| > This morning I realized that one might want to organize the Pharo
| > github project a little bit differently than we're used to..It
| > occurred to me that if all of the packages that went into the core
| > image were saved in the same repository (as is done today with the
| > Pharo14 repository), then a developer who wanted to contribute to
| > Pharo, could fork the PharoCore repository, then make bugfixes and
| > issue a pull request when done.. With git, the bugfix can span
| > more than one package and there's no need for creating slices...
|
| But we will always have changes that cross cut so I would not take
| that as hypothesis
| I will check later because I have to run.
|
| Stef
|
| > So I created a PharoCore repository[2] in Phariverse, then forked
| > the project as myself[3]. I proceeded to make two independent
| > simulated bugfixes[4] and [5] (click on the commit to see the
| > diffs [6][7]).
| >
| > I then issued a pull request for for the second simulated
| > bugfix[8].
| >
| > There are two interesting views ... the network graph[9] and the
| > fork queue[10].
| >
| > The network graph allows you to see what is going on in the forks
| > of the projects and see the relationship between commits that have
| > been done on the primary project and those done in forks.
| >
| > The fork queue shows the list of all commits that have been done by
| > forks and gives you a chance to view the work that is going on on
| > other forks and to choose to integrate changes ...
| >
| > The folks who have forked a project have the same opportunity to
| > see the work that is progressing on the main project and integrate
| > chagnes from the primary to the fork ...
| >
| > It does seem that this model would work pretty well for folks doing
| > development in Pharo ...
| >
| > Additionally, I have created a Pharo 1.4 image (and changes file)
| > with Metacello and filetree code already installed[11]. I've set
| > things up so you're expected to fork the PharoCore[2] project
| > github then manually clone the git repository to your local disk,
| > then edit (with PharoCore repository location) a script[12] that
| > automatically downloads a copy of the filetree and metacello
| > projects and hooks up the image to the 3 Monticello repositories:
| >
| >  PharoCore: 'filetree:///opt/git/PharoCore/repository'
| >  metacello:
| >  'github://dalehenrich/metacello:newPackageFormat/repository'
| >  filetree:  'github://dalehenrich/filetree:pharoBugFix/repository'
| >
| > If you are interested this will give you a feel for what
| > development will be like ... you can make changes to any of the
| > pharo core code and commit packages to the filetree PharoCore
| > repository using the Monticello tools, then manually use git to
| > push your changes up to github and...
| >
| > I plan to provide a Metacello scripting API for at a minimum,
| > defining the location of repositories that you've cloned so that
| > the script[12] doesn't have to be run...I also plan to get the
| > loading of Metacello projects that use github-based projects
| > working as well as a couple of other features, before I think that
| > folks can start using this stuff for real development...
| >
| > PS: the *verse organizations I've created are just for
| > experimenting, so don't base any production work on them ...
| >
| > PPS: I haven't got traits implemented in the filetree format, but
| > that's something on the near term todo list, so if a package has
| > traits, and you do a diff against a filetree repo, you'll see that
| > the traits are missing ...
| >
| > PPPS: I noticed some significant slowness when opening/saving
| > packages in the 1.4 image and at first thought that filetree was
| > slow, but the same delays show up when doing http opens, so it
| > must be something else ... filetree hasn't been optimized (and
| > probably de-optimized from Otto's version) ...
| >
| > Dale
| >
| > [1] https://gist.github.com/1892114
| > [2] https://github.com/Phariverse/PharoCore
| > [3] https://github.com/dalehenrich/PharoCore
| > [4]
| > https://github.com/dalehenrich/PharoCore/tree/simulatedIssueBranch
| > [5] https://github.com/dalehenrich/PharoCore/tree/simulatedIssue2
| > [6]
| > https://github.com/dalehenrich/PharoCore/commit/5ba3ce4aa5f34a7396641c55ecaa52c08e7283e8
| > [7]
| > https://github.com/dalehenrich/PharoCore/commit/680df11c9a1062471f72f91535aecde9fdfcd5bd
| > [8] https://github.com/Phariverse/PharoCore/pull/1
| > [9] https://github.com/Phariverse/PharoCore/network
| > [10] https://github.com/Phariverse/PharoCore/forkqueue
| > [11]
| > https://github.com/downloads/Phariverse/PharoCore/git.PharoCore1.4.zip
| > [12] https://gist.github.com/1960662
|
|

I guess everything which has to go into a potential Kernel Image should be put in a single repos.

- makes updates and bugfixes easier
- somehow indicates that everything in there belongs together...

then of course for all conditional projects which are not directly needed in the core we want separate repos...




On 2012-03-03, at 17:43, Dale Henrichs wrote:

At work our general principle (in git, in particular) is "one
artifact, one repo", which would be satisfied here!

frank

On 5 March 2012 12:37, Camillo Bruni <[hidden email]> wrote:

Right,

In fact a MetacelloRepository could be embedded in the Pharo1.4 git repository and it would be populated with configurations for projects that are n=known to work woth Pharo 1.4 ... which addresses one of the issues involved in communicating to developers what works and does not with a particular release ...

The fork/pull request process can be used to harvest configurations as they become available.

Dale

----- Original Message -----
| From: "Camillo Bruni" <[hidden email]>
| To: [hidden email]
| Sent: Monday, March 5, 2012 4:37:33 AM
| Subject: Re: [Metacello] github experiment with Pharo 1.4 ...
|
| I guess everything which has to go into a potential Kernel Image
| should be put in a single repos.
|
| - makes updates and bugfixes easier
| - somehow indicates that everything in there belongs together...
|
| then of course for all conditional projects which are not directly
| needed in the core we want separate repos...
|
|
|
|
| On 2012-03-03, at 17:43, Dale Henrichs wrote:
|
| > Stef,
| >
| > I think that giving developers the ability to check out all of the
| > source for Pharo1.4-xxxxxx in one repository and make bugfixes
| > that span multiple packages effortlessly are good things ...
| >
| > Today you are doing just that with the Pharo1.4 repository on SS3,
| > the only thing that's missing is the ability to check out all of
| > the packages associated with a single "pharo build"...
| >
| > The Pharo1.4 repository would not be the primary repository ...
| >
| > Perhaps Cami and I can talk this over in more detail this week...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "stephane ducasse" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Saturday, March 3, 2012 12:33:01 AM
| > | Subject: Re: [Metacello] github experiment with Pharo 1.4 ...
| > |
| > | But we will not keep all the packages of pharoCore in pharoCore
| > | since
| > | step by step we will extract them.
| > | Having one repository is not good.
| > |
| > | > Yesterday, I basically got the code for reading and writing the
| > | > new
| > | > filetree format[1].
| > | >
| > | > This morning I realized that one might want to organize the
| > | > Pharo
| > | > github project a little bit differently than we're used to..It
| > | > occurred to me that if all of the packages that went into the
| > | > core
| > | > image were saved in the same repository (as is done today with
| > | > the
| > | > Pharo14 repository), then a developer who wanted to contribute
| > | > to
| > | > Pharo, could fork the PharoCore repository, then make bugfixes
| > | > and
| > | > issue a pull request when done.. With git, the bugfix can span
| > | > more than one package and there's no need for creating
| > | > slices...
| > |
| > | But we will always have changes that cross cut so I would not
| > | take
| > | that as hypothesis
| > | I will check later because I have to run.
| > |
| > | Stef
| > |
| > | > So I created a PharoCore repository[2] in Phariverse, then
| > | > forked
| > | > the project as myself[3]. I proceeded to make two independent
| > | > simulated bugfixes[4] and [5] (click on the commit to see the
| > | > diffs [6][7]).
| > | >
| > | > I then issued a pull request for for the second simulated
| > | > bugfix[8].
| > | >
| > | > There are two interesting views ... the network graph[9] and
| > | > the
| > | > fork queue[10].
| > | >
| > | > The network graph allows you to see what is going on in the
| > | > forks
| > | > of the projects and see the relationship between commits that
| > | > have
| > | > been done on the primary project and those done in forks.
| > | >
| > | > The fork queue shows the list of all commits that have been
| > | > done by
| > | > forks and gives you a chance to view the work that is going on
| > | > on
| > | > other forks and to choose to integrate changes ...
| > | >
| > | > The folks who have forked a project have the same opportunity
| > | > to
| > | > see the work that is progressing on the main project and
| > | > integrate
| > | > chagnes from the primary to the fork ...
| > | >
| > | > It does seem that this model would work pretty well for folks
| > | > doing
| > | > development in Pharo ...
| > | >
| > | > Additionally, I have created a Pharo 1.4 image (and changes
| > | > file)
| > | > with Metacello and filetree code already installed[11]. I've
| > | > set
| > | > things up so you're expected to fork the PharoCore[2] project
| > | > github then manually clone the git repository to your local
| > | > disk,
| > | > then edit (with PharoCore repository location) a script[12]
| > | > that
| > | > automatically downloads a copy of the filetree and metacello
| > | > projects and hooks up the image to the 3 Monticello
| > | > repositories:
| > | >
| > | >  PharoCore: 'filetree:///opt/git/PharoCore/repository'
| > | >  metacello:
| > | >  'github://dalehenrich/metacello:newPackageFormat/repository'
| > | >  filetree:
| > | >   'github://dalehenrich/filetree:pharoBugFix/repository'
| > | >
| > | > If you are interested this will give you a feel for what
| > | > development will be like ... you can make changes to any of the
| > | > pharo core code and commit packages to the filetree PharoCore
| > | > repository using the Monticello tools, then manually use git to
| > | > push your changes up to github and...
| > | >
| > | > I plan to provide a Metacello scripting API for at a minimum,
| > | > defining the location of repositories that you've cloned so
| > | > that
| > | > the script[12] doesn't have to be run...I also plan to get the
| > | > loading of Metacello projects that use github-based projects
| > | > working as well as a couple of other features, before I think
| > | > that
| > | > folks can start using this stuff for real development...
| > | >
| > | > PS: the *verse organizations I've created are just for
| > | > experimenting, so don't base any production work on them ...
| > | >
| > | > PPS: I haven't got traits implemented in the filetree format,
| > | > but
| > | > that's something on the near term todo list, so if a package
| > | > has
| > | > traits, and you do a diff against a filetree repo, you'll see
| > | > that
| > | > the traits are missing ...
| > | >
| > | > PPPS: I noticed some significant slowness when opening/saving
| > | > packages in the 1.4 image and at first thought that filetree
| > | > was
| > | > slow, but the same delays show up when doing http opens, so it
| > | > must be something else ... filetree hasn't been optimized (and
| > | > probably de-optimized from Otto's version) ...
| > | >
| > | > Dale
| > | >
| > | > [1] https://gist.github.com/1892114
| > | > [2] https://github.com/Phariverse/PharoCore
| > | > [3] https://github.com/dalehenrich/PharoCore
| > | > [4]
| > | > https://github.com/dalehenrich/PharoCore/tree/simulatedIssueBranch
| > | > [5]
| > | > https://github.com/dalehenrich/PharoCore/tree/simulatedIssue2
| > | > [6]
| > | > https://github.com/dalehenrich/PharoCore/commit/5ba3ce4aa5f34a7396641c55ecaa52c08e7283e8
| > | > [7]
| > | > https://github.com/dalehenrich/PharoCore/commit/680df11c9a1062471f72f91535aecde9fdfcd5bd
| > | > [8] https://github.com/Phariverse/PharoCore/pull/1
| > | > [9] https://github.com/Phariverse/PharoCore/network
| > | > [10] https://github.com/Phariverse/PharoCore/forkqueue
| > | > [11]
| > | > https://github.com/downloads/Phariverse/PharoCore/git.PharoCore1.4.zip
| > | > [12] https://gist.github.com/1960662
| > |
| > |
|
|

That's a good principle to keep in mind...

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Monday, March 5, 2012 7:25:20 AM
| Subject: Re: [Metacello] github experiment with Pharo 1.4 ...
|
| At work our general principle (in git, in particular) is "one
| artifact, one repo", which would be satisfied here!
|
| frank
|
| On 5 March 2012 12:37, Camillo Bruni <[hidden email]> wrote:
| > I guess everything which has to go into a potential Kernel Image
| > should be put in a single repos.
| >
| > - makes updates and bugfixes easier
| > - somehow indicates that everything in there belongs together...
| >
| > then of course for all conditional projects which are not directly
| > needed in the core we want separate repos...
| >
| >
| >
| >
| > On 2012-03-03, at 17:43, Dale Henrichs wrote:
| >
| >> Stef,
| >>
| >> I think that giving developers the ability to check out all of the
| >> source for Pharo1.4-xxxxxx in one repository and make bugfixes
| >> that span multiple packages effortlessly are good things ...
| >>
| >> Today you are doing just that with the Pharo1.4 repository on SS3,
| >> the only thing that's missing is the ability to check out all of
| >> the packages associated with a single "pharo build"...
| >>
| >> The Pharo1.4 repository would not be the primary repository ...
| >>
| >> Perhaps Cami and I can talk this over in more detail this week...
| >>
| >> Dale
| >>
| >> ----- Original Message -----
| >> | From: "stephane ducasse" <[hidden email]>
| >> | To: [hidden email]
| >> | Sent: Saturday, March 3, 2012 12:33:01 AM
| >> | Subject: Re: [Metacello] github experiment with Pharo 1.4 ...
| >> |
| >> | But we will not keep all the packages of pharoCore in pharoCore
| >> | since
| >> | step by step we will extract them.
| >> | Having one repository is not good.
| >> |
| >> | > Yesterday, I basically got the code for reading and writing
| >> | > the new
| >> | > filetree format[1].
| >> | >
| >> | > This morning I realized that one might want to organize the
| >> | > Pharo
| >> | > github project a little bit differently than we're used to..It
| >> | > occurred to me that if all of the packages that went into the
| >> | > core
| >> | > image were saved in the same repository (as is done today with
| >> | > the
| >> | > Pharo14 repository), then a developer who wanted to contribute
| >> | > to
| >> | > Pharo, could fork the PharoCore repository, then make bugfixes
| >> | > and
| >> | > issue a pull request when done.. With git, the bugfix can span
| >> | > more than one package and there's no need for creating
| >> | > slices...
| >> |
| >> | But we will always have changes that cross cut so I would not
| >> | take
| >> | that as hypothesis
| >> | I will check later because I have to run.
| >> |
| >> | Stef
| >> |
| >> | > So I created a PharoCore repository[2] in Phariverse, then
| >> | > forked
| >> | > the project as myself[3]. I proceeded to make two independent
| >> | > simulated bugfixes[4] and [5] (click on the commit to see the
| >> | > diffs [6][7]).
| >> | >
| >> | > I then issued a pull request for for the second simulated
| >> | > bugfix[8].
| >> | >
| >> | > There are two interesting views ... the network graph[9] and
| >> | > the
| >> | > fork queue[10].
| >> | >
| >> | > The network graph allows you to see what is going on in the
| >> | > forks
| >> | > of the projects and see the relationship between commits that
| >> | > have
| >> | > been done on the primary project and those done in forks.
| >> | >
| >> | > The fork queue shows the list of all commits that have been
| >> | > done by
| >> | > forks and gives you a chance to view the work that is going on
| >> | > on
| >> | > other forks and to choose to integrate changes ...
| >> | >
| >> | > The folks who have forked a project have the same opportunity
| >> | > to
| >> | > see the work that is progressing on the main project and
| >> | > integrate
| >> | > chagnes from the primary to the fork ...
| >> | >
| >> | > It does seem that this model would work pretty well for folks
| >> | > doing
| >> | > development in Pharo ...
| >> | >
| >> | > Additionally, I have created a Pharo 1.4 image (and changes
| >> | > file)
| >> | > with Metacello and filetree code already installed[11]. I've
| >> | > set
| >> | > things up so you're expected to fork the PharoCore[2] project
| >> | > github then manually clone the git repository to your local
| >> | > disk,
| >> | > then edit (with PharoCore repository location) a script[12]
| >> | > that
| >> | > automatically downloads a copy of the filetree and metacello
| >> | > projects and hooks up the image to the 3 Monticello
| >> | > repositories:
| >> | >
| >> | >  PharoCore: 'filetree:///opt/git/PharoCore/repository'
| >> | >  metacello:
| >> | >  'github://dalehenrich/metacello:newPackageFormat/repository'
| >> | >  filetree:
| >> | >   'github://dalehenrich/filetree:pharoBugFix/repository'
| >> | >
| >> | > If you are interested this will give you a feel for what
| >> | > development will be like ... you can make changes to any of
| >> | > the
| >> | > pharo core code and commit packages to the filetree PharoCore
| >> | > repository using the Monticello tools, then manually use git
| >> | > to
| >> | > push your changes up to github and...
| >> | >
| >> | > I plan to provide a Metacello scripting API for at a minimum,
| >> | > defining the location of repositories that you've cloned so
| >> | > that
| >> | > the script[12] doesn't have to be run...I also plan to get the
| >> | > loading of Metacello projects that use github-based projects
| >> | > working as well as a couple of other features, before I think
| >> | > that
| >> | > folks can start using this stuff for real development...
| >> | >
| >> | > PS: the *verse organizations I've created are just for
| >> | > experimenting, so don't base any production work on them ...
| >> | >
| >> | > PPS: I haven't got traits implemented in the filetree format,
| >> | > but
| >> | > that's something on the near term todo list, so if a package
| >> | > has
| >> | > traits, and you do a diff against a filetree repo, you'll see
| >> | > that
| >> | > the traits are missing ...
| >> | >
| >> | > PPPS: I noticed some significant slowness when opening/saving
| >> | > packages in the 1.4 image and at first thought that filetree
| >> | > was
| >> | > slow, but the same delays show up when doing http opens, so it
| >> | > must be something else ... filetree hasn't been optimized (and
| >> | > probably de-optimized from Otto's version) ...
| >> | >
| >> | > Dale
| >> | >
| >> | > [1] https://gist.github.com/1892114
| >> | > [2] https://github.com/Phariverse/PharoCore
| >> | > [3] https://github.com/dalehenrich/PharoCore
| >> | > [4]
| >> | > https://github.com/dalehenrich/PharoCore/tree/simulatedIssueBranch
| >> | > [5]
| >> | > https://github.com/dalehenrich/PharoCore/tree/simulatedIssue2
| >> | > [6]
| >> | > https://github.com/dalehenrich/PharoCore/commit/5ba3ce4aa5f34a7396641c55ecaa52c08e7283e8
| >> | > [7]
| >> | > https://github.com/dalehenrich/PharoCore/commit/680df11c9a1062471f72f91535aecde9fdfcd5bd
| >> | > [8] https://github.com/Phariverse/PharoCore/pull/1
| >> | > [9] https://github.com/Phariverse/PharoCore/network
| >> | > [10] https://github.com/Phariverse/PharoCore/forkqueue
| >> | > [11]
| >> | > https://github.com/downloads/Phariverse/PharoCore/git.PharoCore1.4.zip
| >> | > [12] https://gist.github.com/1960662
| >> |
| >> |
| >
|