Hi all, This thread have caused some confusion to the contributor at DT. It turned out I've already rubber stamp the patch at bug 1168305, so there is no additional code to land into the repo.
However, I fully agree there should be a boarder conversation on policies and processes on taking contributions -- what Dietrich asked. If that's a discussion we want to continue to have please start another thread on that. Thanks everyone who speak out and sorry for the confusion. Tim On Thu, Oct 29, 2015 at 2:24 AM, Jim Porter <[email protected]> wrote: > On 10/28/2015 04:03 AM, Dietrich Ayala wrote: > > I've been told by participants that it seems arbitrary, which makes them > > feel like the core team can land whatever they decide to in the core, > > but others cannot. > > I don't think that's an arbitrary distinction at all. As others in the > thread have implied, it's the core team's job to maintain the core > codebase, so assuming we're not trying to shoot ourselves in the foot, > we only write patches for things we know we can support. > > External contributors, on the other hand, aren't being paid by Mozilla > with the expectation of maintaining all the code they land. While a > contributor might do so voluntarily, we can't force them. Therefore, all > the code an external contributor lands into the tree needs to be code > that we're ok with maintaining on our own. > > I often argue against landing code with an unacceptable maintenance > burden. The difference is that when it's in a bug assigned to me, I > usually make that argument *before* I write the patch. :) Contributors > don't always ask first, which unfortunately can mean they've wasted > their effort. > > That said, we can do better on our end. I'm trying to eliminate some of > the wasted effort by triaging the bugs in my components so that the only > open bugs are ones for which we'd actually accept patches. That way, a > prospective contributor can just look at our bug list to find something > to do that has a good chance of landing. > > - Jim > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
