Liron, Projects are managed by their committers. This is why its critical to have them within a limited scope that is reasonably addressable by the expertise of their committers. If we would like a summarization to be presentable to the TSC, perhaps an Umbrella project to group them might be in order. I would recommend however that we *not* do a Common Framework project and we *do* individual projects that are well scoped instead.
As to alignment, alignment is typically achieved by the underlying projects providing value to potential consuming projects. A logging project that is being responsive and meeting the logging needs of its consumers will have an easy time being adopted, and alignment will be achieved quite effortlessly. Should it fail to meet needs, it will find it difficult to garner adoption. This is the natural protections built into the system to ensure responsiveness without politics. It works quite well in practice. If you remove that mechanism, many things can go wrong, including incumbent projects failing to meet consumer needs for long periods. Ed On Mon, Jun 5, 2017 at 1:27 AM, Liron Shtraichman < [email protected]> wrote: > Hi guys, thank you for your feedback! > > > > It is a question how we manage those frameworks that we want to be part of > ONAP. I think we can all agree on the need, as managing this complex system > with different framework for logging, AuthN, AuthZ, or extensibility, in > every component will be very difficult. I also understand the concern of > having too big of a project to manage, but we also have this problem today > with Modeling project, which contains several different *repos* that are > un-related in some manner (at least this is how it looks like in the > proposal), and will have its own committers and contributors. > > > > Manage each project separately is also an overhead, as you need to get > good amount of attraction by the community, to have PTLs for each of the > project, release management, committers, etc. In addition, having one > project that all projects need to align with (in regard to libraries and > frameworks) is easier, than start to manage this alignment in 5-6 different > projects. > > This was our proposal to this alignment, and project management. > > > > I would love to hear how you guys think the community should align on > common frameworks and embed those in the core components. I think we all > share the same goal of making ONAP not just working, but also maintainable > and extendable. > > > > Thanx, > > Liron > > > > *From: *Ed Warnicke <[email protected]> > *Date: *Friday, June 2, 2017 at 6:00 PM > *To: *"[email protected]" <[email protected]> > *Cc: *Liron Shtraichman <[email protected]>, onap-tsc < > [email protected]> > *Subject: *Re: [onap-tsc] Common Frameworks - Project Proposal > > > > I second Zhaoxing's comments. A project should have a well defined, > limited scope, for the reasons cited above as well as many others having to > do with the overall health of the community. A DMaap project makes sense > to me, AAA project, a Common Frameworks project does not. > > > > Ed > > > > On Thu, Jun 1, 2017 at 11:32 PM, <[email protected]> wrote: > > Hi Liron, > > > > I don't see significant benefits by putting a new project on top of other > projects after going through the "Common Frameworks" proposal. Instead, > there are some potential issues. > > If some codes/modules are put together into one project, ideally, they > should be interrelated. But these projects which are claimed to be put into > this proposal are created in different problem domains and no overlap. This > will create some management problems, such as > > - How to correctly define the committer for this project? Committers > are supposed to have written the seed codes and have the right skills to > contribute to the project, and they have access to modify and commit the > codes of the project which they are in. Given that the needed skillset and > background knowledge are totally different for the individual projects > inside this proposal, it's hard to assign access control to committers > properly. > - This project will become too huge to manage, for example, the > mailist, gerrit, jira, meeting, etc. will be full of a lot of unrelated > discussion and clues, similar to the current TSC maillist, which are > flooded by messages coming from different concerns. > > > > Thanks, > > Zhaoxing > > > > > > > > > > 原始邮件 > > *发件人：* ＜[email protected]＞; > > *收件人：* ＜[email protected]＞; > > *日* *期* *：*2017年06月01日 18:00 > > *主* *题* *：**[onap-tsc] Common Frameworks - Project Proposal* > > > > Hello Committee Members, > > > > I would like to submit the following project proposal: > https://wiki.onap.org/display/DW/Common+Frameworks?src= > contextnavpagetreemode > > This project is a *consolidation of several other common projects* that > were already introduced to this committee > > > > > > Thanx, > > > > Liron > > > > > > > > > > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > > you may review at https://www.amdocs.com/about/email-disclaimer > > > > > > > _______________________________________________ > ONAP-TSC mailing list > [email protected] > https://lists.onap.org/mailman/listinfo/onap-tsc > > > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > you may review at https://www.amdocs.com/about/email-disclaimer >
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
