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" <[email protected]> wrote: > On 03/19/2014 07:45 PM, Dmitry Borodaenko wrote: > > On Wed, Mar 19, 2014 at 4:56 AM, Bogdan Dobrelya <[email protected]> > 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 : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
