Experimental copy of petascope while patchmanager gets upgraded

[abeccati]

We need to start adding destabilizing changes for preparation of version 9.0 but the patchmanager still is not ready to handle branches (hence we cannot use a feature branch yet).

As an interim solution we should clone our git repo and give write access to it to 9.0 features developers (at least).

When its available we also need to document how to access it and request write access. When either patchmanager supports branches or we get a stable status (whichever comes first), we then send an aligning patch via the patchmanager to the main repo.

[Dimitar Misev]

Didn't we discuss this and decided to simply go on with the master ("development") branch? Or you changed your mind in the meantime?

[Dimitar Misev]

It's not worth setting up this separate development repo, since the patchmanager should become available by the end of the month.

[abeccati]

As far as I know the patchmanager will be "started to be worked on" by end of the month, I have no idea when it will be available (stable and well tested). We need to start development of experimental features involving the community hence the need for it…
Simply cloning on a separate address should be fine, then we can grant access to it for pushing changes collaboratively.

I would also go for the master but it will get unstable and we do not have yet in place a well established branching support, hence the temporary solution.

[Dimitar Misev]

Ok, then we should find some volunteer for setting up and maintaining this extra repo. I'm afraid I myself don't have the time for it.

The other option is to submit to master. I'm not convinced at all that the master will get that unstable; as long as we keep tests passing, and announce on the mailing lists that drastic changes are applied, there should be no issues. If there are we can revert, people can revert themselves, etc. I really don't understand all the fear..

[Piero Campalani]

Hi there,
so, as proposed by Alan, since we are pretty in a hurry for the next release of rasdaman 9.0, by now we are going to create an applications/petascope9/ folder to allow shared, contributor-agreement aware and parallel development of the new Petascope (and petascopedb), while keeping a compilable and stable Petascope in the same repo.

Tables for the new database will have a different prefix, other than PS_: PS9_?

Regarding future solutions, I suggest:

1. no copying of folders, nor entire repos: only branches and possibly some gitolite management for access rights, so that the main repo becomes a unique place for sharing open development, under-construction features with controlled access, different releases. In the end users can also clone single branches.
2. regarding contributor agreement: why don't we let only registered users push patches, and let them acknowledge a one-for-all agreement for any uploaded patch/commit? This would also allow a terminal-based committing on branches which may give push-rights to some developers.
3. If this is not possible, then the patch-manager (which is slower everyday ) is the one endpoint for any branch in the repo, which is still fine. No gitolite but more load for our benevolent dictator for patch review/evaluation.

Opinions?

[abeccati]

Closed as wontfix (no repo clone to be created) and moved topic to #373