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
pgpqds8qhOnSP.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
