Prelim branch

[zeffii]

I'm going to start somewhere, so that's what the Prelim branch is. The naming and conventions are by no means permament, but I think they make sense (but will of-course be subject to the collective mood)

I think i'll start with adding a panel to a new CustomTreeType view, so sort out the relative imports / import reloads and then take it further. You are welcome to contribute, but maybe give me a day before pushing code to Prelim. or start your own branch of Prelim.

[nortikin]

do prelim aimed to make placeholders for all undefined stuff?

[zeffii]

yeah, I recommend branching from it and not editing it directly... i'll be branching from it too when I've time to

[nortikin]

Start from basic defs in data_structure_np that will handle only numpy manipulations, than we can make text viewer, i lovely will write definitions to show data in text file. if you know, frame in node tree can show text files, so in node area we see text viewer data. handy. or we can add graphicall representation of data itself with opengl or QT

[ccamara]

Since you're starting from scratch, and since you don't seem very convinced with branches and naming, let me suggest to use a gitflow workflow (you can read excelent explanation -far better than the one I could write now here- on this post from Vincent Driessen and this one on atlasian).

Let me summarise it:

Workflow: There are two main branches (master and develop) and secondary branches. I'd propose that each feature (eg. each issue on github) would have its own branch (and it would be great if we prefixed each branch with the issue number -as well as commit messages). Each feature branch would be created from develop branch and merged to develop again as soon as it has been finished (and ideally verified/supervised by some other person). Whenever develop branch is feature complete and does not present any regression, it would be merged to master and tagged with a new release.

Pros This workflow has many advantages, some of them being:

• Each issue is idled, so it won't interfere with other development made by other developers.
• Easier to prevent possible regresions and track them whenever they occur.
• Effective workflow with few rules to remember, which makes collaboration with different collaborators easier (everyone knows how to proceed -something which I haven't been able to know yet and being one of the big barriers from contributing to Sverchock -the other one being my really basic python knowledge)
• Well known workflow (so, again, promotes possible collaboration from others)
• It works great with forks and allows peer reviews, making the code better, and allowing others to learn from peers.
• It won't interfere with current workflow because you're starting from scratch

Hope you can consider this suggestion, even though it comes from someone who has barely contributed to Sverchock (just added one line) despite I'm following it from quite some time.

[zeffii]

I think we've been close to gitflow since the first major refactor by @wclyffe last year. At least those of us who have contributed most code have tried to follow this already. We will continue to work this way because it has proven quite successful.

Right now there we are still in a phase of re-boostrapping, and don't have anything to commit to master.

[zeffii]

But having said that we have Sverchok more structured like the Blender project itself, which is one Master branch and countless Feature branches, forgoing the 'develop' branch as we have at times been working on very different features simultaneously. The point of a development branch seems a little excessive and just an extra step for merging.. It's something we considered early on, but it never was practical for Sverchok.

[zeffii]

we could certainly add an Issue number to branches that are specific to a Bug Fix process

[nortikin]

agree to add some order. master than release (to make todo files for exact versions, but it conflict with agile development paradigm some, but make sense) than development. Maybe Sverchok not so huge yet for milestones as versions tags? but in future it will appear. Now we can have development branch wich is prelim for redux stage. We will merge it to Original sverchok master later. Maybe to clean branches in original sverchok git??? what do you think?

[nortikin]

forking is it a way to reduce branches count? for now there are too many.

[ccamara]

Thanks for your comments, @nortikin and @zeffii

About Forks: Forks are not thought specifically for having less branches but for as a collaboration method. The fork / pull request method works like this:

• When you fork you create a clone of the repo. This repo is exactly the same at the moment of cloning, but there's no other relationship to it, so there's no problem in messing thigs up. It may be used to converge at some point with the original repo (by pull request) or not.
• When you create a pull request you are comparing two specific branches: one from your forked repo and another one from the original one. Pull requests create a special issue which contains a description and a commit number with any differences between branches. This commit is pending to be merged until the original repo owner (or if using teams, anyone with permissions), approves the pull request. The owner can make comments or suggestions so the user who started the pull request will try to amend them. Since the changes will be made in the same branch, any new commit made to the same branch will be updated in the same pull request. The process will be repeated until the original repo owner accepts the PR or closes it.

This method is great because it prevents errors from being included in the original repo since it requires manual supervision from trusted users. A part from peer reviewing it can be extended with Continuous Integration Tools such as Travis (I don't know how could it be added in python apps, but it may be useful for checking coding standards, for example -since I don't have enough experience with python I do not know if I am saying nonsense or not, forgive me if I am doing so :P)

More info: https://help.github.com/articles/using-pull-requests/

About Agile development IMHO I don't see any inconvenient in using gitflow with an agile approach. In fact I have been working in a company doing drupal projects using SCRUM and gitflow with quite success, although we didn't use milestones as a goal. We created user stories and each user story had several tasks, being each of them an issue on Github which had to be developed on its own branch (prefixed with issue number). Usually each branch had only one commit (we amended the commit with commit amend instead of creating new ones) which has a message containing the issue number (so it gets linked to the issue). The feature branch was merged (in fact it was rebased) to development branch when accepted by other peers. Being said that, I don't mean that what worked for us has to work for sverchock or has to be implemented here! (just giving some point of view!)

About having too many branches I don't see why this could be a problem (Specially if they are prefixed with a number, which makes its goal clearer), but there are some ways to tackle this situation:

• Using rebase instead of merge will keep the working tree cleaner (see: http://www.git-scm.com/book/en/v2/Git-Branching-Rebasing)
• Github provides information about the branches that have completely been merged and thus can be deleted with no problems, so it could be deleted manually.
• With a clear workflow in which every branch has been prefixed with an issue and that issue is closed when the branch has been merged to develop branch (or master) that means that any feature branch prefixed by an issue number that has been closed can be safely deleted, since it would have been merged.

About develop vs master branch It may not make any sense right now (in fact, it doesn't since there's no stable version), but in the future may be useful because we would have a master branch which is completely stable and a development branch which may have few problems. As I have said I do not have experience in python (and not proficient at all in other programming languages) but I'd bet that there may be problems that won't appear in a feature branch but only show up when merging with other people work doing in parallell, so that would be detected in develop branch and won't affect anyone whith sverchock already installed (this happened to me quite some time ago -at the begining, so you may not have these kind of problems now). But again, it's just my opinion and despite merging does not require a lot of time (Well, some times it does if they are conflicts when merging old commits) I agree it adds extra steps. The good news is that this can be easily be changed in the future if you see there's a need for that or not.

Regards

[zeffii]

@ccamara I think I was not very articulate in my first post in the thread, regarding naming conventions. This was not talking about the name of the branch, but instead the naming used for the code structures .

As for the branch names, we've done branches per feature / node and fix branches, but I guess we could make them more uniform. I fail to see however how this will increase accessibility to new coders. We've had success with 8 or 9 coder contributions, but no remarks for potential coders claiming that the code was hard to get into ..

[zeffii]

In the end the project gets formed by people who actively contribute code, no-one else.

[ccamara]

Indeed @zeffii

You're the ones that are making the code and thus, the ones who decide how to do it. I do not have anything to complain about that, of course!

[zeffii]

this is no longer needed.