Hi, Thanks for the feedback James.
On Tue, Jan 7, 2014 at 3:02 PM, Ketrenos, James P < [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]> > 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] > > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > > > _______________________________________________ > Crosswalk-dev mailing list > [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
