Exact procedure for committing changes to the OSDK on SVN.

Questions, bug reports, features requests, ... about the Oric Software Development Kit. Please indicate clearly in the title the related element (OSDK for generic questions, PictConv, FilePack, XA, Euphoric, etc...) to make it easy to locate messages.

Post Reply
User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Exact procedure for committing changes to the OSDK on SVN.

Post by NekoNoNiaow » Sun Apr 14, 2019 4:01 am

Hello kitties,

I will (very) soon (like, this Sunday ;)) have a few (very) small changes to the OSDK that I want to share with the community so before I do that I would like to be certain of the contribution procedure.
(Note: my goal is not to change that procedure, let us not discuss that, I just want to understand it.)

We discussed this topic in a previous OSDK thread and DBug precised his priorities on this post:
post: viewtopic.php?f=3&t=1805&p=17444#p17424.

If I understand these rules correctly it would seem to me that the context and procedure intended by Dbug are the following:

First of all, no branches are used. Everyone contributes to the same trunk at the same time.
Then, when kitten X wants to contribute his changes to the OSDK back to SVN,
  • X fetches the latest SVN version locally
  • X merges his changes into this latest version (locally, on X's machine),
  • X verifies, locally, that the changes still work
  • X modifies his changes so that can be enabled/disabled via #define/#ifdef (if appropriate)
  • X informs the community officially that there are some changes to be committed
  • DBug decides whether he wants the changes or not
  • X pushes their changes to the SVN repository (directly on trunk)
  • DBug verifies the changes by examining the code and indicates if he wants them or not
  • people get the latest SVN and enable the changes on a voluntary basis via #define/#ifdef
  • when the changes eventually get validated by the community, someone (X or DBug?) removes the #define/#ifdef in the code and commits to SVN
  • a new version of the OSDK is published by DBug
Is that correct? And if not, what would be the exact list?
Thanks in advance! ;)

User avatar
Dbug
Site Admin
Posts: 2929
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Exact procedure for committing changes to the OSDK on SVN.

Post by Dbug » Sun Apr 14, 2019 12:05 pm

I don't think the process is cast is stone, and so far has been highly dependent of the type of changes.
The priorities are to make it as simple for everybody, keep things reliable, and avoid having too many people having too many different versions so things get impossible to diagnose.

On my side, when I release new versions of the OSDK, the SVN is updated at the same time, I did not do it yesterday because it was a release candidate, but ISS wanted to test how it worked on Linux so I submitted the changes, the current SVN version is identical to what is on my computer.

#ifdef is only for things that we want to try that we are not sure we will want to keep, it's rarely used, and only by developers doing testing in their particular setup.

Regarding the contribution process, it's highly dependent of who, what, and the scale: I only enforce things on the version I maintain (the Windows version of the OSDK), or that have an impact on the depot (like putting things all over the place without any logic, or adding terabytes of binaries that are not relevant).

When mmu_man, jylam and iss are doing linux changes, as long as it does not have an impact on the way the windows version works, I don't care.

If I commit a change that breaks the linux version (it has happened, not on purpose, but it's hard to remember that this particular feature requires this header file on Windows and this other one on Posix machines), mmu or iss don't have to ask me if they can fix the code so it runs on their system... as long as they tell me so I can verify that it still works fine on Windows.

If it's just a small change to an existing program, posting on the forum with a patch for it is fine as well, everybody can discuss it before it makes it to the actual code repository, and depending if the person has the SVN access right or not can go make the change themselves or I can do it, since ultimately I publish the versions and I test them, that does not add anything to my workflow.

For very large changes, which can impact multiple parts of the toolchain, etc... and since most people prefer to use github, bitbucket, etc... there's nothing wrong with the modification to be done on a OSDK fork, tested and modified there, and when the person feel they have something solid, can show what they have done, everybody can fetch the code and check for issues, rebuild it and test it, etc...

It's basically how I worked with Fabrice for his tools, and recently for the C compiler: On projects the size of the OSDK, it's trivial to do a folder diff to see the changes, and it's much easier to follow the list of changes when you have separate commits that indicate what was changed in one single change list, than 20 small commits with small fixes, etc...

If you want an actual workflow to follow, I would suggest that one:
  • Suggest the change you want to do, your idea, and I can tell you pretty much immediately if I will accept it or not. For example, if it involves any language that is not C or C++, installing custom build tools and new frameworks just for your feature, it's most probably going to be a big no, in which case you can totally do a complete Fork of the project and do your changes and release your versions, I can even add links to the OSDK main page to the various forks with an explanation about why it exists and the differences with my version.
  • If I deem the change interesting, you can as I wrote earlier play on your machine, post on the forum with suggested changes and why you feel they are good and what the benefits are (benefits can be code performance, ease of maintenance, better compatibility, tweaks to make it easier to build for whatever platform you are using, etc...) or link to your own code repository with the changes.
  • If nobody among the three or four persons who usually have opinion on that is against the change, then I can check with the author on how to bring it on board, and I'll try my best to release a new OSDK version with the changes (fully credited obviously).
Imo, that's easier to remember that your 11 point version :)

User avatar
ibisum
Wing Commander
Posts: 1092
Joined: Fri Apr 03, 2009 8:56 am

Re: Exact procedure for committing changes to the OSDK on SVN.

Post by ibisum » Sun Apr 14, 2019 2:20 pm

Hmm. Seems like one way a newbie could help contribute to the OSDK is to set up some automated tests that run on the target platforms ...

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: Exact procedure for committing changes to the OSDK on SVN.

Post by NekoNoNiaow » Mon Apr 15, 2019 6:34 pm

Dbug wrote:
Sun Apr 14, 2019 12:05 pm
If you want an actual workflow to follow, I would suggest that one:
  • Suggest the change you want to do, your idea, and I can tell you pretty much immediately if I will accept it or not. For example, if it involves any language that is not C or C++, installing custom build tools and new frameworks just for your feature, it's most probably going to be a big no, in which case you can totally do a complete Fork of the project and do your changes and release your versions, I can even add links to the OSDK main page to the various forks with an explanation about why it exists and the differences with my version.
  • If I deem the change interesting, you can as I wrote earlier play on your machine, post on the forum with suggested changes and why you feel they are good and what the benefits are (benefits can be code performance, ease of maintenance, better compatibility, tweaks to make it easier to build for whatever platform you are using, etc...) or link to your own code repository with the changes.
  • If nobody among the three or four persons who usually have opinion on that is against the change, then I can check with the author on how to bring it on board, and I'll try my best to release a new OSDK version with the changes (fully credited obviously).
Imo, that's easier to remember that your 11 point version :)
This merges some of my points and removes some others and is more flexible indeed.

I was trying to be precise and you are trying to be more flexible, obviously these two approaches conflict. ;)
It is probably better to be more flexible indeed so I will go with your approach.

My only concern though is that if even after discussion, I (or anyone) submit something that you like in principle but do not like implementation-wise, then this will have to be reverted after the fact. I.e., there is no pre-review of the code.

But if this is fine with you then all good with me. ;)
ibisum wrote:
Sun Apr 14, 2019 2:20 pm
Hmm. Seems like one way a newbie could help contribute to the OSDK is to set up some automated tests that run on the target platforms ...
Maybe, maybe not, but what is certain is this would be off-topic. ;)

User avatar
Dbug
Site Admin
Posts: 2929
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Exact procedure for committing changes to the OSDK on SVN.

Post by Dbug » Mon Apr 15, 2019 6:46 pm

NekoNoNiaow wrote:
Mon Apr 15, 2019 6:34 pm
My only concern though is that if even after discussion, I (or anyone) submit something that you like in principle but do not like implementation-wise, then this will have to be reverted after the fact. I.e., there is no pre-review of the code.
Where did you see that?

If it's as I said "not relevant" to the windows version, they can just commit, but if it's stuff that is relevant to the windows version:
you can as I wrote earlier play on your machine, post on the forum with suggested changes and why you feel they are good and what the benefits are (benefits can be code performance, ease of maintenance, better compatibility, tweaks to make it easier to build for whatever platform you are using, etc...) or link to your own code repository with the changes.
I thought it was clear in what I wrote, the review/comments are done before the code ends up in the SVN repository:
If nobody among the three or four persons who usually have opinion on that is against the change [review], then I can check with the author on how to bring it on board [the SVN depot], and I'll try my best to release a new OSDK version with the changes (fully credited obviously).
We can reformulate if it's not clear, but I thought it was crystal clear :-/

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: Exact procedure for committing changes to the OSDK on SVN.

Post by NekoNoNiaow » Mon Apr 15, 2019 7:14 pm

Dbug wrote:
Mon Apr 15, 2019 6:46 pm
I thought it was clear in what I wrote, the review/comments are done before the code ends up in the SVN repository:
If nobody among the three or four persons who usually have opinion on that is against the change [review], then I can check with the author on how to bring it on board [the SVN depot], and I'll try my best to release a new OSDK version with the changes (fully credited obviously).
We can reformulate if it's not clear, but I thought it was crystal clear :-/
The "funny" thing is that I indeed remember reading that but seem to have forgotten it by the time I decided to reply. :D

Oki then, reviews can be done, but outside of the SVN "main branch". -> I haz now remembered it for good. ;)

Post Reply