Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-reviews-dev] Common Models contribution process

Okay, then let's try this on eclipse and see how that works. That way we can still keep reviews process, though I'd ask folks to be a little more liberal with their +1s just for just this branch. :) [bug324327_CommonModel] Please do comment on issues, because that will be a great place to start the discussion, and will definitely feed back into further refinements, but I envision having a formal review of the entire branch before even thinking about merging it, and I'd like to defer some of the discussion while keeping that branch fresh and merged with master as much as possible.

Also, I really would like to use r4E on that process, so this would be a good way to do that. (Though then we have to decide if we want to do the r4E on the branch model or the existing model. ;D)

On 2012-09-25, at 7:46 PM, Alvaro Sanchez <alvsan09@xxxxxxxxx> wrote:

> Your proposal makes a lot of sense although it seems possible to avoid the CQ when going over the 250 lines limit if your commits are submitted by a committer from the same employer I.e. Steffen, see the upper left second box on  http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf
> 
> If the interpretation above is correct we can either work off a github or eclipse.org repository branch.
> 
> We can always double check with EMO to make sure we are interpreting things correctly.
> 
> /Alvaro
> 
> 
> On Tue, Sep 25, 2012 at 7:33 PM, Miles Parker <miles.parker@xxxxxxxxxxx> wrote:
> As this is relevant to Reviews community as a whole, I wanted to be sure that everyone saw this bug. In particular, please see item 3 and let me know asap if you would like to participate in these discussions.
> 
> 324327: Define a common model for reviews https://bugs.eclipse.org/bugs/show_bug.cgi?id=324327
> 
> "Here is proposed plan for working with the complexities of completing a common model design. As background, we've been doing these on Gerrit, but the granularity is way too low for the scale and complexity of the changes proposed, and as a non-comitter I am really hampered by 250-line limit.
> 
> 1. I do a full round of re-factoring, aligning and rationalizing the existing models on a github branch.
> 2. I discuss key issues with all participants and put together a Wiki page summarizing any areas that need clarification or decision and asking for input.*
> 3. We have scheduled meeting(s) to discuss any of these issues. * We'll try to do these as part of regular Mylyn meetings but that might be practical — so if anyone wants to participate in these discussion, please let me know and I'll make sure that you are included.
> 4. Iterate 1-3 as needed.
> 5. When all parties sign-off *, submit CQ for github changes.
> 6. While waiting for 5 and in parallel with the other stuff, I can continue to do work on R4E and Reviews to try to earn my committer status. :) If I can get that status in time, we won't need CQ.
> 
> *Perhaps we could even capture the whole thing as an R4E review, which would be excellent dog-fooding.
> 
> Does this seem workable to everyone?"
> 
> _______________________________________________
> mylyn-reviews-dev mailing list
> mylyn-reviews-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev
> 
> _______________________________________________
> mylyn-reviews-dev mailing list
> mylyn-reviews-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev



Back to the top