> we already generate from templates required information for a plugin
developer to start development
and it is great.
So, back to what I said:
> However, we can have fpb generating template plugin, with commented code
in there. If you uncomment, you a get a comprehensive example of a
Well, what about tomorrow? On SCF we create stable branches and master
is open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata. Because it's something that we usually don't want
to release, and FPB
# 2 don't agree, we already generate from templates required information
for a plugin developer to start development, purpose of plugin examples is
different, it's used as integration tests for plugins, also QA team uses
them as Functional tests, they overloaded with tasks and designed to
#1 - If you truly agree with that, you should weigh in here:
#2 - Requires a blueprint and new docs, but okay.
#3 - Yes! We have very poor CI for fuel plugin builder. All it does is
ensure it makes a plugin, not that it can be installed and deployed.
here is what I think:
1) I suggest to fix what is broken now. So that people who come across
examples would not have to deal with issues. We may debate for other few
days (hopefully not more), and all plugin devs will be suffering during
this time. Also, according to Matt,
> I should add
Because it doesn't make much sense for a plugin developer to have scripts
to build packages for installation on slave nodes. For default template
it's better to have something minimalistic and the rest of the tasks
commented, otherwise it may create a lot of confusion.
On Wed, Mar 9, 2016 at 6:37
Talking about templates I mean plugins generated by FBP from the
`templates` folder using command you mentioned above.
Why not to extend (not replace) template-generated plugins with additional
data to provide right coverage?
On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L wrote:
r/is almost a copy-paste/is almost a copy-paste from plugins templates
On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote:
> Igor, i completely agree, actually plugin examples is almost a copy-paste.
> The only thing i see useful in the built plugins example is the
What do you mean by "templates" the plugin which is create by just "fpb
It doesn't cover enough, package installation and all range of tasks
On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote:
> Igor, i completely agree,
Igor, i completely agree, actually plugin examples is almost a copy-paste.
The only thing i see useful in the built plugins example is the ability to
point some code lines, discussing plugin design and writing documentation.
Why not to generate this examples automatically from templates?
Plugin examples mustn't be removed, those plugins are part of integration
tests for fuel plugin builder, which should be able to build any version of
So there are two ways to solve the problem:
1. Before test run update compatibility matrix for plugins automatically.
Yet another example  of why a dummy/example plugin should be integrated
in the Fuel CI process: the current version of Fuel is broken for (almost)
all plugins since a week at least and no one noticed.
On Mon, Mar 7, 2016 at 3:16
What about maintaining a dummy plugin (eg running only one or two very
simple tasks) as a standalone project for the purpose of QA?
IMO it would make more sense than having those example plugins in the
On Mon, Mar 7, 2016 at 2:49 PM, Igor Kalnitsky
> and really lowering barriers for people who just begin create plugins.
Nonsense. First, people usually create them via running `fpb --create
plugin-name` that generates plugin boilerplate. And that boilerplate
won't contain that changes.
Second, if people ain't smart enough to change few lines
+1 to maintain example plugins. It is easy enough and really lowering
barriers for people who just begin create plugins.
On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
> It seems you are proposing an IKEA approach to plugins. Take Fuel's
It seems you are proposing an IKEA approach to plugins. Take Fuel's
example plugin, add in the current Fuel release, and then build it. We
maintained these plugins in the past, but now it should a manual step
to test it out on the current release.
What would be a more ideal situation that
No, this is a wrong road to go.
What if in Fuel 10 we drop v1 plugins support? What should we do?
Remove v1 example from source tree? That doesn't seem good to me.
Example plugins are only examples. The list of supported releases must
be maintained on system test side, and system tests must
IMHO it is important to keep plugin examples and keep testing them, very
valuable for plugin developers.
For example, I've encountered  the case where "plugin as role" feature
wasn't easily testable with fuel-qa because not compliant with the last
plugin data structure,
and more recently we've
On Thu, Mar 3, 2016 at 7:19 AM, Matthew Mosesohn wrote:
> Hi Fuelers,
> I would like to bring your attention a dilemma we have here. It seems
> that there is a dispute as to whether we should maintain the releases
> list for example plugins. In this case, this is
Mail list logo