[openstack-dev] [puppet] [fuel] more collaboration request
flavio at redhat.com
Fri Jun 12 12:25:31 UTC 2015
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, acceptable.
>To sum up my previous emails, you're wrong on all accounts: commits and
>attribution are different things; we're not losing attribution; losing
>commit history is acceptable.
Do you keep the author of the code you copied?
>> The fact that you are developing Fuel in the open is awesome and I
>> really hope you never change your mind on that but please, do find a
>> solution for this issue. As you can see from this thread, it creates
>> lots of frustration and it makes other project's work more difficult.
>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
>frustration. Does anybody's bonus depend on the number of lines of code
>in stackforge repositories such as fuel-library that git blame
>attributes to their name?
I don't think anyone here is talking about bonuses or worrying about
salaries. The fact that you mention it offends the purposes of this
thread and, as much as you don't care, I'm really sad to read that.
The whole thing this thread is trying to achieve is improving
collaboration and you are derailing the conversation with completely
unfriendly/unhelpful comments like the one above.
It does cause frustration because, as you can read from Emiliem's
original email, it not just adds some extra burden to people in the
puppet team but it also defeates the purposes of the team itself,
which is creating OpenStack puppet manifests that are consumable by
Help them be better and let them help you improve your workflow/app.
>> >The most problematic implication of what you're asking for is the
>> >additional effort that it would require from Fuel developers. When you
>> >say that Puppet OpenStack developers don't have time to look at Fuel git
>> >history for bugfixes, and then observe that actually Fuel developers do
>> >propose their patches to upstream, but those patches are stalled in the
>> >community review process, this indicates that you don't consider taking
>> >over and landing these patches a priority:
>> >The fact that you have started this thread means that you actually do
>> >care to get these bugfixes into Puppet OpenStack. If that's true, maybe
>> >you can consider a middleground approach: Fuel team agrees to propose
>> >all our changes to upstream (i.e. do a better job at something we've
>> >already committed to unilaterally), and you help us land the patches we
>> >propose, and take over those that get stalled when the submitter from
>> >Fuel team has moved on to other tasks?
>> Assuming good faith, I'd guess you meant something: "Please, help us
>> prioritize patches comming from Fuel".
>Please do not assume that what I actually meant (as I explained in
>previous reply to Emilien) is incompatible with good faith. I am a
>strong believer in Free Software, and I want to improve collaboration
>between Puppet OpenStack and Fuel. I also know that unless we come up
>with collaboration improvements that are mutually beneficial to both
>projects, nothing will change and this discussion will remain, as
>Emilien has put it, just words.
Please, do come up with something that works for both. It'll be of
great benefit for both projects.
Just to be clear, I believe in yours and both teams good faith. The
reason I mentioned that is because, as a non-native English speaker, I
could've read that paragraph in a different way. Just trying to be
explicit to avoid others to read it the same way I did.
Thanks a lot,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev