fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Sorry, but I'm personally lost in the approach... Andrew's first email in
the thread looks to me pretty viable in most of the cases.

Once we keep in mind simple rule - make it simple for others to review, and
accept with minimal risk - all should be fine.

Another thing is that we must be very careful with merging whole pieces
from upstream, such as puppet modules. They should be very well written.
Otherwise the cost of maintenance will be high. So in some cases we may
better write from scratch, than to take something existing.



On Wed, Mar 19, 2014 at 9:45 PM, Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx
> wrote:

> On Wed, Mar 19, 2014 at 4:56 AM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>
> wrote:
> > On 03/19/2014 01:31 PM, Dmitry Nikishov wrote:
> >> Actually, zabbix module doesn't come from any upstream repo, it's our
> >> own reimplementation of the module by PL team, which was based on
> >> upstream code. In Zabbix thread it was suggested that we split it into
> >> multiple commits instead of trying to push the whole thing at once.
>
> It can't be both our own reimplementation and based on upstream code
> at the same time. If it's not rewritten from scratch, you should track
> down the original upstream version and start your commit series from
> that.
>
> >> It's unclear how it will affect internally developed modules like zabbix
> >> one. Should there be any at all? Or should we make a public repo with
> >> that module first and then try to include it into fuel-library?
>
> That's a very good question. Personally, I think that we should prefer
> the second option most of the time: create a public repo for the
> standalone module, and use that as upstream for the copy of that
> module in fuel-library. It will make it more likely that this module
> will attract other engineers who will help us find and fix bugs in
> this code, and eventually even add more new features that we'd be able
> to reuse in Fuel.
>
> > It is also not quite clear how to submit these team-specific changes.
> > 1) E.g. I've submitted the puppet-logstash module from Apollo11 team
> > (Poland) and that module was diverged from the original upstream version
> > by the team. Now we have a two diverged versions - an upstream one and a
> > submitted one.
>
> I think that you should present each hand-over as a separate commit:
> {original upstream commit} -> {modifications from Apollo11 team} ->
> {modifications to integrate with Fuel}. If you have the commit history
> from Apollo11 and it's not too long, it would be nice to have all of
> it instead of squashing it all into one commit (although if it's more
> than a dozen commits it might now be worth the trouble of pulling each
> commit through Gerrit).
>
> > 2) Should I submit the diverged commits rebased onto the upstream
> > HEAD/stable version as a separate patchset which depends on the verbatim
> > copy of HEAD/stable patchset? That could be a very bad idea, because
> > rebasing might broke the module completely.
>
> Yes, I also think that would be a bad idea. Rebase is a kind of a
> change, you don't want to combine that and other changes in a single
> commit, or you loose ability to distinguish what were you changes and
> what changed due to rebase.
>
> > 3) Should I do the same as (2) but use the common parent commit as an
> > upstream base for verbatim copy instead? Despite on no more rebasing
> > needed, that is not so good idea as well, because it would also
> > complicate the  upstream sync contribution process, if any planned in
> > the future.
>
> You're not going to be able to kill two rabbits with one stone here.
> Either you significantly diverge from upstream, and keeping up will be
> near impossible, or you keep Fuel specific changes minimal and well
> isolated, and keeping up becomes simple.
>
> a) If you diverge, the best you can do is submit all your
> non-Fuel-specific improvements to upstream (you will obviously need to
> heavily modify them to decouple from Fuel specific code), and then
> periodically (e.g. once per Fuel release) merge upstream changes back
> into Fuel by hand. The further you deviate, the harder this process
> becomes. It becomes even harder if you don't submit anything to
> upstream, because there will be more changes to hand-port later.
>
> b) If you can isolate Fuel specific code, keeping up with upstream
> becomes much easier. Create a fork of upstream repo on Github, create
> a fuel branch in that fork, commit all changes for that module to the
> fuel branch before submitting them to fuel-library. Submit non Fuel
> specific changes to upstream (keep them on your fuel branch until they
> are merged). Pulling a new upstream version into fuel-library becomes
> a rebase of your fuel branch of the forked upstream onto the latest
> upstream release, and then copying the result verbatim into
> fuel-library. If Fuel specific code is well isolated, that rebase will
> be trivial.
>
> > 4) So, looks like the only good option is to accept changes to the
> > puppet modules which are only the sync requests from the upstream (see
> > Openstack projects and Oslo) and never change them locally in the Fuel?
> > But I'm afraid the Fuel puppet modules are not ready yet for such
> > dramatical changes... Looks like we need a kind of Fuel-oslo ;)
>
> I think we're very far from being able to use this approach.
>
> --
> Dmitry Borodaenko
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Mike Scherbakov
#mihgen