Open Stack

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. The attribution in
>> > commits is lost because our directory namespace differs such that it
>> > can't just be merged cleanly. Revisiting submodules is an option,
>> > but it led to maintenance problems in the past.
>> What kind of problems?
>
>It was before I got involved with Fuel, but I can offer a guess.
>Managing submodules introduces operational overhead and with it more
>opportunities for failures and mishaps than a single flat git repo.
>
>Flat repo makes it more difficult to reconcile with upstream modules,
>but, when using the process I have described in my previous email to
>this thread, not as difficult as one could think. We also reconcile an
>average module with upstream much less frequently (no more than once per
>Fuel release) than we make commits to that module (many times per
>release), which also tilts the overhead balance if favor of using a flat
>repo.

Matthew, Dmitry,

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.

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.

[..]

>> > The difference is that Fuel is being worked on in the open in
>> > StackForge. Anyone is free to contribute to Fuel as he or she
>> > wishes, take our patches, or review changesets.
>> Should not it be the way around?
>> Puppet OpenStack modules provide the original code. If there is a bug,
>> it has to be fixed in the modules. Puppet OpenStack developers don't
>> have time/bandwidth and moreover don't want to periodically have a
>> look at Fuel git history. I'm not sure this is the best solution for
>> the community.

+1

>(...)
>> The reality (and again I won't blame any patch, you can find them on
>> Gerrit) is that most of patches are not merged and in staled status.
>> If I can suggest something, the policy should be more "upstream first"
>> where you submit a patch upstream, you backport it downstream, and in
>> the until it's merged you should make sure it land upstream after
>> community review process. The last step is I think the problem I'm
>> mentioning here and part of the root cause of this topic.
>
>Yes, this right here is the biggest point of contention in the whole
>discussion.
>
>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:
>
>http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-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".

How many members of the Fuel team are also part of Puppet OpenStack ?

It'd be awesome if more members of the Fuel team could collaborate
with reviews on Puppet OpenStack. That'd certainly increase the team's
bandwidth. (I'd guess/hope you guys are already doing it).

[..]

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150612/61593460/attachment.pgp>