Well, to have dedicated owner(owners) to take care of blink/chromium tree for rebase makes sense, but it seems now the actual rebased activities are scattered to individuals, I am not sure whether it will be efficient, especially when the patch number is growing and there are some dependencies among patches. Personally I think the most efficient way is that one person to take care of most of common rebase and if he/she encountered some non-trivial changes which are out of his/her scope, he/she can directly involve the owners (e..g via a separate PR by the owner on this case). And I believe Halton Huo is a very good role model during last time rebase..
Anyway, I am OPEN to do some exploration to continuously improve the process/efficiency. No matter which way to take, I think the bottom line is : We need to have a very clear expectation on the owner during the rebase: i.e. the rebased patches need be reviewed/merged quickly w/ the highest priority - otherwise the whole tree will be blocked. Thanks, Zhiqiang " Simplicity is Beauty..." From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Alexis Menard Sent: Wednesday, January 08, 2014 2:25 AM To: Ketrenos, James P Cc: [email protected] Subject: Re: [Crosswalk-dev] Change how we maintain our Chromium and Blink repositories Hi, Thanks for the feedback James. On Tue, Jan 7, 2014 at 3:02 PM, Ketrenos, James P <[email protected]<mailto:[email protected]>> wrote: For the TL;DR: I am for having a single team/owner responsible for Chromium/Blink in Crosswalk. I'm not sold on the notion of having the original owner of a feature have to continually re-visit "completed" work in order to keep that feature in a newer version of Crosswalk. Long winded answer: In general I am for attempt to improve our methodology, and this takes us a step in the right direction. Having not been in the trenches dealing with the day-to-day impact of the current methodology, I defer to those that have. I *really* like the idea of having a single, unchanging, person/team that owns Chromium. However, this proposal diverges from the BKM illustrated by most open source projects. From the community vantage point (3rd parties, other business groups, etc.) landing something in upstream (to them) means landing it in Crosswalk. In the Linux kernel world (and other open source projects) once a feature has landed in upstream, rebasing is done by the upstream community. In our approach, we are saying landing Right if the rebasing is trivial then sure it can be done by the Owner(s). Problem is when it's not trivial. I agree with you that most open source project consider that if it lands in the tree, it's going to be carried over. However most of these projects expect the original author to be there to maintain the code he landed (both in bug fixes and improvements). If the original author disappear, the project may decide to nominate a new maintainer or owner for this piece of code and carry it forward because it's beneficial for the entire project, however we've seen many of these projects going to the road of removing the feature because it's unmaintained, unsecure and buggy. We need an escape route, I don't think burning many days of engineering power to rebase/understand a feature that was landed by a contributor (not necessarily Intel) is a good thing. These are kind of the exceptions and where we need to balance : crosswalk moving forward with newer chromium / downstream patches. it in Crosswalk means you are going to own that feature forever, and if you don't, it may be deleted. Yes unless someone else steps up to maintain it. This is common workflow (Blink, WebKit, KDE, Qt for example). I would set the expectation that we may start with a single full time resource allocated to owning Chromium, however we may expand that to a forward-porting sub-team long term. I would rather see experts in re-basing and forward porting doing that job than "peanut buttering" that skillset across the entire team. While it sounds nice I don't think we can have a "experts in re-basing" team. There are few reasons for that : - Rebasing downstream patches is not about resolving few conflicts there and there. - Rebasing downstream patches may not be trivial, say upstream refactored/removed some classes used in a given patch. - We don't have the manpower to cover and have expertise (which mean saying that the patch is correctly rebased or not) to cover the entire codebase of Chromium. For now our patches are concentrated enough but who knows when Crosswalk is getting a bit more popular we can see big actors pushing changes in part of Chromium we don't know anything about (and don't have skills/time to learn) and these actors may not want to be "rebasing experts". They may want to rebase their own patches best case. We're open to suggestions to improve the current model. James On Thu, Jan 2, 2014 at 11:59 AM, Oliveira, Caio <[email protected]<mailto:[email protected]>> wrote: > Hello, > > > > Me, Alexis and Raphael (with feedback from Gustavo and Jesus) wrote down a > proposal to change how we handle the Chromium and Blink repositories for > Crosswalk. In summary: > > > > Developers of changes to our branches of Chromium and Blink will have to > make new PRs for every Chromium update. > One person will be responsible for the branches, will take care of the > updates and make final calls about any PR for those branches. > > All the details and rationale are in > https://docs.google.com/a/intel.com/document/d/1rfYTJjMpuGVxIFFwj_g72V2mdkgcrOIm6D8e275tdLw/edit?usp=sharing > (the comments are disabled, please give feedback in this thread). > > > > What do you think? > > > > > > Cheers, > > Caio > > > _______________________________________________ > Crosswalk-dev mailing list > [email protected]<mailto:[email protected]> > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > _______________________________________________ Crosswalk-dev mailing list [email protected]<mailto:[email protected]> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev -- Alexis Menar
_______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
