[PROPOSAL] Workflow with forked repos

[Alexander Shorin <kx...@gmail.com>]

Hi devs,

I was plan to sync our couchdb-jiffy fork up to the current master
(upstream latest release 0.13.3, our fork is on 0.9 tag). Recent
versions of jiffy contains a lot of useful improvements for scheduler,
tests, Windows build.

However, here I came to the problem: our master is different from
upstream one, because we removed binary rebar from the repo. And
actually it should be different after all since we would need to
configure .travis for our needs and do other organization work which
drifts us away from upstream.


So here is what I came with help of Paul J. Davis thoughts:

- Each fork repo should contain upstream branch which is in sync with
upstream source repository;

- When need knocks the door, we merge upstream into master, where our
local changes happens;

- If our changes are not CouchDB-specific, we should try to avoid
commit the to master and try to push them through upstream (submit PR
to upstream repository, get it merged, sync upstream branch in our
repo, merge it to master).

- When release time happens, we need to pin our masters to specific
commit. Hashes are not much verbose, so better to use tags. But in the
same time we cannot say that we use mochiweb-2.8.1 since our fork is
too much different from upstream. That's not good situation, but it's
real one. To avoid confusion, we need to tag it specifically. I
propose X.Y.Z-couchdb.N schema where X, Y, Z are closest upstream
release tag, couchdb is an release identifier and N is our own
incremental version.

Example:

Our current mochiweb fork is references to 2.8.1 version. So we can
tag it HEAD as 2.8.1-couchdb.0 (0 as we didn't count any previous
fixes per release).

Assume, we fix something else there for the new CouchDB release - then
we tag master as 2.8.1-couchdb.1 and so on.

If we sync it with upstream, then next tag will be 2.12.2-couchdb.0 -
assuming that our local changes survived the merge.


I think such scheme will bring a little bit order into our workflow
with forks and help to easily distinguish upstream releases from our
own.


Thoughts? Critics? All welcome!

--
,,,^..^,,,

Re: [PROPOSAL] Workflow with forked repos

[Alexander Shorin <kx...@gmail.com>]

Hi Adam,

Correct. N plays role of Z here if it we could control over it. But
since we don't, we're also free from obligation to follow
major/minor/patch requirements per semver, so it's just our own
releases counter that signs that we changed something and our changes
are based on upstream X.Y.Z version.

--
,,,^..^,,,


On Thu, Jul 9, 2015 at 7:22 PM, Adam Kocoloski <ko...@apache.org> wrote:
> Excellent, very well thought through. I think I understand that the `X.Y.Z-couchdb.N` tag is incremented for every new *release* generated as a descendant of the nearest reachable upstream X.Y.Z version, as opposed to every new *commit*. That is, if we introduce 3 commits after merging with 2.12.2 from upstream our release tag is 2.12.2-couchdb.1, right?
>
> Adam
>
>> On Jul 9, 2015, at 12:01 PM, Alexander Shorin <kx...@gmail.com> wrote:
>>
>> Hi devs,
>>
>> I was plan to sync our couchdb-jiffy fork up to the current master
>> (upstream latest release 0.13.3, our fork is on 0.9 tag). Recent
>> versions of jiffy contains a lot of useful improvements for scheduler,
>> tests, Windows build.
>>
>> However, here I came to the problem: our master is different from
>> upstream one, because we removed binary rebar from the repo. And
>> actually it should be different after all since we would need to
>> configure .travis for our needs and do other organization work which
>> drifts us away from upstream.
>>
>>
>> So here is what I came with help of Paul J. Davis thoughts:
>>
>> - Each fork repo should contain upstream branch which is in sync with
>> upstream source repository;
>>
>> - When need knocks the door, we merge upstream into master, where our
>> local changes happens;
>>
>> - If our changes are not CouchDB-specific, we should try to avoid
>> commit the to master and try to push them through upstream (submit PR
>> to upstream repository, get it merged, sync upstream branch in our
>> repo, merge it to master).
>>
>> - When release time happens, we need to pin our masters to specific
>> commit. Hashes are not much verbose, so better to use tags. But in the
>> same time we cannot say that we use mochiweb-2.8.1 since our fork is
>> too much different from upstream. That's not good situation, but it's
>> real one. To avoid confusion, we need to tag it specifically. I
>> propose X.Y.Z-couchdb.N schema where X, Y, Z are closest upstream
>> release tag, couchdb is an release identifier and N is our own
>> incremental version.
>>
>> Example:
>>
>> Our current mochiweb fork is references to 2.8.1 version. So we can
>> tag it HEAD as 2.8.1-couchdb.0 (0 as we didn't count any previous
>> fixes per release).
>>
>> Assume, we fix something else there for the new CouchDB release - then
>> we tag master as 2.8.1-couchdb.1 and so on.
>>
>> If we sync it with upstream, then next tag will be 2.12.2-couchdb.0 -
>> assuming that our local changes survived the merge.
>>
>>
>> I think such scheme will bring a little bit order into our workflow
>> with forks and help to easily distinguish upstream releases from our
>> own.
>>
>>
>> Thoughts? Critics? All welcome!
>>
>> --
>> ,,,^..^,,,
>>
>

Re: [PROPOSAL] Workflow with forked repos

[Adam Kocoloski <ko...@apache.org>]

Excellent, very well thought through. I think I understand that the `X.Y.Z-couchdb.N` tag is incremented for every new *release* generated as a descendant of the nearest reachable upstream X.Y.Z version, as opposed to every new *commit*. That is, if we introduce 3 commits after merging with 2.12.2 from upstream our release tag is 2.12.2-couchdb.1, right?

Adam

> On Jul 9, 2015, at 12:01 PM, Alexander Shorin <kx...@gmail.com> wrote:
> 
> Hi devs,
> 
> I was plan to sync our couchdb-jiffy fork up to the current master
> (upstream latest release 0.13.3, our fork is on 0.9 tag). Recent
> versions of jiffy contains a lot of useful improvements for scheduler,
> tests, Windows build.
> 
> However, here I came to the problem: our master is different from
> upstream one, because we removed binary rebar from the repo. And
> actually it should be different after all since we would need to
> configure .travis for our needs and do other organization work which
> drifts us away from upstream.
> 
> 
> So here is what I came with help of Paul J. Davis thoughts:
> 
> - Each fork repo should contain upstream branch which is in sync with
> upstream source repository;
> 
> - When need knocks the door, we merge upstream into master, where our
> local changes happens;
> 
> - If our changes are not CouchDB-specific, we should try to avoid
> commit the to master and try to push them through upstream (submit PR
> to upstream repository, get it merged, sync upstream branch in our
> repo, merge it to master).
> 
> - When release time happens, we need to pin our masters to specific
> commit. Hashes are not much verbose, so better to use tags. But in the
> same time we cannot say that we use mochiweb-2.8.1 since our fork is
> too much different from upstream. That's not good situation, but it's
> real one. To avoid confusion, we need to tag it specifically. I
> propose X.Y.Z-couchdb.N schema where X, Y, Z are closest upstream
> release tag, couchdb is an release identifier and N is our own
> incremental version.
> 
> Example:
> 
> Our current mochiweb fork is references to 2.8.1 version. So we can
> tag it HEAD as 2.8.1-couchdb.0 (0 as we didn't count any previous
> fixes per release).
> 
> Assume, we fix something else there for the new CouchDB release - then
> we tag master as 2.8.1-couchdb.1 and so on.
> 
> If we sync it with upstream, then next tag will be 2.12.2-couchdb.0 -
> assuming that our local changes survived the merge.
> 
> 
> I think such scheme will bring a little bit order into our workflow
> with forks and help to easily distinguish upstream releases from our
> own.
> 
> 
> Thoughts? Critics? All welcome!
> 
> --
> ,,,^..^,,,
> 

Re: [PROPOSAL] Workflow with forked repos

[Alexander Shorin <kx...@gmail.com>]

On Thu, Jul 9, 2015 at 7:46 PM, Joan Touzet <wo...@apache.org> wrote:
>
>> - When need knocks the door, we merge upstream into master, where our
>> local changes happens;
>
> We will need to be careful about this not to undo the changes
> we need for ourselves, for instance re-introducing a binary rebar or
> clobbering our .travis files as you point out.
>
> As such merging upstream should be done into another branch where work
> is done and a PR is issued before we merge *that* branch into master.

Good and important remark, thanks! (:

--
,,,^..^,,,

Re: [PROPOSAL] Workflow with forked repos

[Joan Touzet <wo...@apache.org>]

Alex wrote:

> - When need knocks the door, we merge upstream into master, where our
> local changes happens;

We will need to be careful about this not to undo the changes
we need for ourselves, for instance re-introducing a binary rebar or
clobbering our .travis files as you point out.

As such merging upstream should be done into another branch where work
is done and a PR is issued before we merge *that* branch into master.

-Joan