fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

There is some info at docs.mirantis.com/fuel-dev. We can add a link to
corresponding section.
Any improvements and additions to the doc are highly appreciated.

Thanks,
On Mar 25, 2014 1:38 PM, "Bogdan Dobrelya" <bdobrelia@xxxxxxxxxxxx> wrote:

> On 03/19/2014 07:45 PM, Dmitry Borodaenko 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.
> >
>
> So, do we have an accepted "how-to" for introducing puppet modules in
> Fuel-library? If we do, let's add it to the Fuel wiki as well.
>
> --
> Best regards,
> Bogdan Dobrelya,
> Skype #bogdando_at_yahoo.com
> Irc #bogdando
>
> --
> 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
>