Zane,
Backing the rules with incentives is very important, thanks for bringing
it up!
This is exactly why I'm trying to be conservative about how much
upstream integration overhead Fuel team can commit to: make it too
burdensome and it will fizzle out. On the other hand, unintrusive and
increment
Emilien,
Thanks for re-raising this. This is a sore subject on the Fuel's side, and
I will sulk in my own shame for not being better here and continue to
encourage my colleagues to be better in this regard.
On Wed, Jun 10, 2015 at 10:45 PM Emilien Macchi wrote:
> Hi,
>
> Before reading this e-m
On 15.06.2015 13:59, Bogdan Dobrelya wrote:
>
> I believe as a first steep, the contribution policy to Fuel library
Sorry, the step, it is not so steep.
> should be clear and *prevent new forks of upstream modules* to be
> accepted in future. This will prevent the technical dept and fork
> main
> On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote:
>
> I'm actually happy to hear from you, since we were discussing together
> about that over the last 2 summits, without real plan between both groups.
I believe as a first steep, the contribution policy to Fuel library
should be clear and *prevent
This thread kind of deteriorated a bit (though it looks like it's
hopefully recovering), so I'd just like to add some observations.
What we have here is a classic case of a long-running fork, with all
that that entails. In this case the fork is a public one, but that
actually makes very little
On Fri, Jun 12, 2015 at 01:23:28PM -0700, James Bottomley wrote:
> However, the commit history is vital to obtaining the provenance of the
> code. If there's ever a question about who authored what part of the
> code (or worse, who copied it wrongly from a different project, as in
> the SCO suit a
On Fri, Jun 12, 2015 at 12:14:52PM -0400, Emilien Macchi wrote:
> On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote:
> > IMO, it's a communication issue and related more to Puppet OpenStack
> > community that to Fuel Library folks. In Fuel Library when patch from
> > external contributor has some pr
On Fri, 2015-06-12 at 13:05 -0700, Dmitry Borodaenko wrote:
> On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> > On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > > What about code history and re
On 06/12/2015 03:33 PM, Dmitry Borodaenko wrote:
> On Fri, Jun 12, 2015 at 02:25:31PM +0200, Flavio Percoco wrote:
>>> I have already explained in the thread how we address the problem of
>>> tracking down and managing the Fuel specific changes in forked modules.
>>> With that problem addressed,
On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > What about code history and respect of commit ownership?
> > > I'm personally wondering if it's fa
On Fri, Jun 12, 2015 at 02:25:31PM +0200, Flavio Percoco wrote:
> >I have already explained in the thread how we address the problem of
> >tracking down and managing the Fuel specific changes in forked modules.
> >With that problem addressed, I don't see any other objective reason for
> >frustratio
On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote:
> Hi,
>
> I have read all this thread trying to understand what's going on. It has
> many emotions but very few logical proposals. Let me try to sum up and
> make some proposals.
>
> * A bug is reported in both Fuel Library and the Puppet mod
Hi,
I have read all this thread trying to understand what's going on. It has
many emotions but very few logical proposals. Let me try to sum up and make
some proposals.
* A bug is reported in both Fuel Library and the Puppet module having
> trouble. A patch is provided in Fuel Library (your fork
On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > What about code history and respect of commit ownership?
> > I'm personally wondering if it's fair to copy/paste several thousands of
> > lines of code from another Open
work?
Thanks,
Kevin
From: Dmitry Borodaenko [dborodae...@mirantis.com]
Sent: Friday, June 12, 2015 2:43 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [puppet] [fuel] more collaboration request
On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrot
On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote:
>> Hi,
>>
>> Before you read me, please remember I know almost nothing about puppet. :)
>>
>> On 06/11/2015 11:03 PM, Matt Fischer wrote:
>>
>> Matt,
>>
>> I appreciate a lot who you are, and all the help you've given me so far,
>> but what you are a
On 06/12/2015 08:29 AM, Flavio Percoco wrote:
> On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote:
>> On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote:
>>> On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
>>> >Secondly, I'd like to point out that Fuel is not so different from
>>> >wh
On 06/12/2015 05:43 AM, Dmitry Borodaenko wrote:
> On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
>> What about code history and respect of commit ownership?
>> I'm personally wondering if it's fair to copy/paste several thousands of
>> lines of code from another Open-Source proj
Folks
As Dmitry already said, we are open towards merging with upstream and would
like to make our code divergence no more than several percents of lines,
but there are historical reasons for this divergence with which we are not
happy either. So let's just point out that both sides look into the
On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote:
On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote:
On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
>Secondly, I'd like to point out that Fuel is not so different from
>what other teams are doing. At the Summit, I heard from others w
On 12/06/15 03:28 -0700, Dmitry Borodaenko wrote:
On Fri, Jun 12, 2015 at 09:24:33AM +0200, Flavio Percoco wrote:
I'm sure you both, and the Fuel team, are acting on good faith but I
believe, in this case, there's no problem that makes copy/pasting
code, and therefore loosing commits attribution
> Hi,
>
> Before you read me, please remember I know almost nothing about puppet. :)
>
> On 06/11/2015 11:03 PM, Matt Fischer wrote:
>
> Matt,
>
> I appreciate a lot who you are, and all the help you've given me so far,
> but what you are asking here is wrong. You shouldn't ask Emilien to
> tra
On Fri, Jun 12, 2015 at 09:24:33AM +0200, Flavio Percoco wrote:
> I'm sure you both, and the Fuel team, are acting on good faith but I
> believe, in this case, there's no problem that makes copy/pasting
> code, and therefore loosing commits attribution, acceptable.
To sum up my previous emails, yo
On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote:
> On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
> >Secondly, I'd like to point out that Fuel is not so different from
> >what other teams are doing. At the Summit, I heard from others who all
> >maintain internal Gerrits and interna
On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> What about code history and respect of commit ownership?
> I'm personally wondering if it's fair to copy/paste several thousands of
> lines of code from another Open-Source project without asking to the
> community or notifying the a
On 06/12/2015 04:31 AM, Dmitry Borodaenko wrote:
> A better alternative would be to make all upstream Puppet OpenStack
> directly usable in Fuel, but even if we figure out a way to make that
> work, it will take a long journey to get there. On the upstream side,
> Fuel core reviewers would have to
On Thu, Jun 11, 2015 at 11:01:19PM -0400, Emilien Macchi wrote:
> > 1) "If you are adding a module that is the work of another project and
> > is already tracked in separate repo (...) review should also contain the
> > commit hash from the upstream repo in the commit message". Using this
> > refer
On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
[..]
Secondly, I'd like to point out that Fuel is not so different from
what other teams are doing. At the Summit, I heard from others who all
maintain internal Gerrits and internal forks of the modules. The
difference is that Fuel is being worked
Greetings,
On 11/06/15 19:31 -0700, Dmitry Borodaenko wrote:
On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote:
On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
> I'm not saying it's the most community-oriented approach, but Fuel
> would have never evolved and matured without it. Th
On 06/11/2015 10:31 PM, Dmitry Borodaenko wrote:
> On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote:
>> On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
>>> I'm not saying it's the most community-oriented approach, but Fuel
>>> would have never evolved and matured without it. The att
Dmitry, thank you for taking your time. Please read inline:
On 06/11/2015 07:12 PM, Dmitry Borodaenko wrote:
> First of all, thank you Emilien for bringing this up, and thank you Matt for
> confirming our commitment to collaborate with puppet-openstack and other
> Puppet modules that Fuel develope
On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote:
> On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
> > I'm not saying it's the most community-oriented approach, but Fuel
> > would have never evolved and matured without it. The attribution in
> > commits is lost because our directory
First of all, thank you Emilien for bringing this up, and thank you Matt for
confirming our commitment to collaborate with puppet-openstack and other
Puppet modules that Fuel developers consider upstream.
I'd like to add some more concrete examples of what Fuel team has
already done, is doing, and
Hi,
Before you read me, please remember I know almost nothing about puppet. :)
On 06/11/2015 11:03 PM, Matt Fischer wrote:
> We as a community don't do a great job watching bugs, so personally I'd
> prefer that fuel developers just push patches, filing a bug too if you
> want. (Note: we do need t
Hey Matt & other OpenStack folks,
I agree that pinging #fuel-dev would not be scalable for every
request. But I think it was more of if someone notices something is
fixed in fuel-library but not in an OpenStack puppet library, then by
all means come and poke someone so we can try and get it in to
Hi Matthew,
Thanks for your reply, please see inline:
On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
> Hi Emilien,
>
> I can see why you might be unhappy with Fuel's actions with regards to
> the OpenStack Puppet modules. You could make this argument about many
> components in Fuel. The heart o
We as a community don't do a great job watching bugs, so personally I'd
prefer that fuel developers just push patches, filing a bug too if you
want. (Note: we do need to improve our bug tracking!) However, I don't
think that asking puppet openstack devs to ask in the fuel channel if a
given bug is
Hi Emilien,
I can see why you might be unhappy with Fuel's actions with regards to
the OpenStack Puppet modules. You could make this argument about many
components in Fuel. The heart of the matter is that we bundle the
upstream OpenStack Puppet modules with all the other modules,
developed both up
+1 for the thread, I would also like to hear from Mirantis on this.
The Fork on fuel/puppet has been actively seen patching and
consolidation.It seems like parallel effort why not merge it.
regards
/sanjay
On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi wrote:
> Hi,
>
> Before reading this e-m
Hi,
Before reading this e-mail, please keep in mind:
* I have a lot of admiration for Fuel and since I'm working on OpenStack
Installers (at eNovance and now Red Hat), Fuel is something I always
consider a good product.
* This e-mail is about Fuel and Puppet, nothing about Mirantis.
* I'm writing
40 matches
Mail list logo
