GsDevKit submit 'testing'

Ciao,
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Ah, excellent! I've been waiting for this question:)

I saw your issue[1] and I've just commented on the issue.

https://github.com/GsDevKit/GsDevKit is an interesting beast, because in the normal scenario you are actually using https://github.com/glassdb/glass, a fork of https://github.com/GsDevKit/GsDevKit. Eventually I will provide a migration path, but for now all bugfixes should be made against https://github.com/glassdb/glass.

Step 1:

Fork https://github.com/glassdb/glass, on github using the fork button[2]. I see you already have a fork[3], so you don't need to perform this step.

Step 2:

Clone your fork of glassdb/glass to your local development machine.

If you are using GsDevKit_home, then you already have a local clone in $GS_HOME/shared/repos/glass. If you are not using GsDevKit_home, tell me more about your setup, so I can give you advice, but for bugfixes it makes sense to go ahead and set up a little GsDevKit_home installation to make the bugfix, then when it makes its way through the process to the master branch, you can access the bufix.

For completeness I'll list the steps to perform clone a git repo (use the git@ variant if you have already registered an SSH key passphrase, otherwise use the https variant and you will be prompted for your username and password):

  cd $GS_HOME/shared/repos
  # git clone [hidden email]
  git clone https://github.com/dariogithub/glass.git

Step 3:

The GsDevKit_home clone has the default remote ("origin") pointing at "https://github.com/dariogithub/glass" and you need to create a remote that points at your github repository by doing the following (as with `git clone`, use the git@ variant if you have already registered an SSH key passphrase, otherwise use the https variant and you will be prompted for your username and password):

  cd $GS_HOME/shared/repos/glass
  # git remote add dario [hidden email]
  git remote add dario https://github.com/dariogithub/glass.git

I've used `dario` as the remote name, but you can use any name that makes sense to you. The following command lists the remote names that you've defined for a repo:

  git remote

Step 4:

Now that you've got your git remote defined, you want to make sure that you've got the latest code in your local clone ... I see that your github fork is a bit out of date (3 commits behind) so I will include the steps to get the latest code from glassdb/glass and synchronize with dariogithub/glass ... steps that you should always perform:

  cd $GS_HOME/shared/repos/glass
  git checkout master
  git pull origin master
  git push dario master

Step 5:

Before you start work on the bugfix, you should create a topic branch off of the master branch for your work, this isolates the changes that you are making for the bugfix from any other work you may have done:

  cd $GS_HOME/shared/repos/glass
  git checkout master
  git checkout -b issue_88

For bugfixes I always use the pattern `issue_<bug-number>` in naming the branch so that there is no confusion about why the branch was created.

Step 6:

Now you need to update your existing stone by executing the following tODE command:

  project load GLASS1

If you didn't already have a stone, create one now and it will be build using the the new master branch.

Step 7:

Implement the bugfix ... test or better yet, write new tests.

Step 8:

Commit your bugfix using the following tODE command:

  project commit --message=`Issue #88: blah blah` GLASS1

The `#88` in your commit comment, will cause this commit to show up in the bug report.

Step 9:

Push your fix to your github repo:

  cd $GS_HOME/shared/repos/glass
  git push daro issue_88

Step 10:

Now create a pull request to submit the changes to the glassdb/glass repo.

First select the `issue_88` branch on github, and then click  on the 'New pull request' button next to the branch list or under the `pull requests` tab and fill out the information (include issue #88 in the title and body of the PR, so that a reference to the pr will show up in the bug report), click on the `create pull request` button and you're done.

I'll get notified of the pull request and a job will be kicked off on travis-ci to run all of the tests against your changes ... when the travis tests are green and I've reviewed the code, I'll merge the bugfinx onto the master branch.

Step 11:

Pick up the merged bugfix in your local clone and update your fork:

  cd $GS_HOME/shared/repos/glass
  git checkout master
  git pull origin master
  git push dario master

Let me know if you have any questions,

Dale
 


[1] https://github.com/GsDevKit/GsDevKit/issues/88
[2] https://github.com/glassdb/glass#fork-destination-box
[3] https://github.com/dariogithub/glass
[4] https://help.github.com/articles/working-with-ssh-key-passphrases/

Ciao,

i'm interested to understund how i can submit an integration of some code into GsDevKit.

I submit a new issue [1] .

Now what it's the procedure, the next step ?

Thanks,

Dario

[1]https://github.com/GsDevKit/GsDevKit/issues/88 

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Ciao, thanks,

i have some point ......

Ah, excellent! I've been waiting for this question:)

I saw your issue[1] and I've just commented on the issue.

https://github.com/GsDevKit/GsDevKit is an interesting beast, because in the normal scenario you are actually using https://github.com/glassdb/glass, a fork of https://github.com/GsDevKit/GsDevKit. Eventually I will provide a migration path, but for now all bugfixes should be made against https://github.com/glassdb/glass.

Step 1:

Fork https://github.com/glassdb/glass, on github using the fork button[2]. I see you already have a fork[3], so you don't need to perform this step.

Step 2:

Clone your fork of glassdb/glass to your local development machine.

If you are using GsDevKit_home, then you already have a local clone in $GS_HOME/shared/repos/glass. If you are not using GsDevKit_home, tell me more about your setup, so I can give you advice, but for bugfixes it makes sense to go ahead and set up a little GsDevKit_home installation to make the bugfix, then when it makes its way through the process to the master branch, you can access the bufix.

I install a Seaside server 3.2.12  based on GsDevKit_home ( i follow the [2] indications)

The server works fine.

The only first singularity is what WAWelcome application and relative class is not load in the system.

Because ? The [1] browse it.

How i can load it ( WAWelcome package )  from Tode?

Edit the Seaside3 project entry (Browse > project entry menu item in project list and add 'Welcome' to the loads: argument:

^ TDProjectSpecEntryDefinition new
    baseline: 'Seaside3'
      repository: 'filetree://$GS_HOME/shared/repos/Seaside31/repository'
      loads: #('Zinc' 'Development' 'Examples' 'Welcome');
    installScript:
        '
      project clone --https --local Seaside3
      project install --local --url=http://gsdevkit.github.io/GsDevKit_home/ZincHTTPComponents.ston
      project install --local --url=http://gsdevkit.github.io/GsDevKit_home/GsApplicationTools.ston';
    gitCheckout: 'gs_master';
    status: #(#'inactive');
    locked: true;
    yourself

Save the project list, then run the following two tODE commands:

  project list
  project load Seaside3

For completeness I'll list the steps to perform clone a git repo (use the git@ variant if you have already registered an SSH key passphrase, otherwise use the https variant and you will be prompted for your username and password):

  cd $GS_HOME/shared/repos
  # git clone [hidden email]
  git clone https://github.com/dariogithub/glass.git

But this clone overwrites:

I only included this "for completeness" ... above I mention that the glass repo is already cloned ...

 If you are using GsDevKit_home, then you already have a local clone in $GS_HOME/shared/repos/glass. 

It's correct ?

When i do the command:  git clone https://github.com/dariogithub/glass.git

the system answer: " the bath exist and it is not empty directory "

What should I do?

No need to worry as you've already got the repo cloned ...

Step 3:

The GsDevKit_home clone has the default remote ("origin") pointing at "https://github.com/dariogithub/glass" and you need to create a remote that points at your github repository by doing the following (as with `git clone`, use the git@ variant if you have already registered an SSH key passphrase, otherwise use the https variant and you will be prompted for your username and password):

  cd $GS_HOME/shared/repos/glass
  # git remote add dario [hidden email]
  git remote add dario https://github.com/dariogithub/glass.git

I've used `dario` as the remote name, but you can use any name that makes sense to you. The following command lists the remote names that you've defined for a repo:

  git remote

Step 4:

Now that you've got your git remote defined, you want to make sure that you've got the latest code in your local clone ... I see that your github fork is a bit out of date (3 commits behind) so I will include the steps to get the latest code from glassdb/glass and synchronize with dariogithub/glass ... steps that you should always perform:

  cd $GS_HOME/shared/repos/glass
  git checkout master

  git pull origin master

  git push dario master

Step 5:

Before you start work on the bugfix, you should create a topic branch off of the master branch for your work, this isolates the changes that you are making for the bugfix from any other work you may have done:

  cd $GS_HOME/shared/repos/glass
  git checkout master
  git checkout -b issue_88

For bugfixes I always use the pattern `issue_<bug-number>` in naming the branch so that there is no confusion about why the branch was created.

But how i can define the bug-number to use ?

Good question ... it's a good idea to submit an issue on github, so that the details of the problem can be discussed ... For example, you recently submitted this Issue #88[1], so you would name the branch issue_88.

If you don't have an issue number of bug number to use, you can choose a meaningful branch name for your work and that will be fine ...

Dale

[1] https://github.com/GsDevKit/GsDevKit/issues/88


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass