[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mylyn-reviews-dev] Architecture discussions, process
|
We definitively want to be involved in the discussions, as R4E does and will continue to use significant portion of the Common Mylyn Reviews code base.
As for the process, we can discuss it, but given the scope of the changes, your approach makes sense.
Thanks a lot Miles for driving this.
/Sebastien (on the behalf of the R4E team)
-----Original Message-----
From: mylyn-reviews-dev-bounces@xxxxxxxxxxx [mailto:mylyn-reviews-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: February-07-13 12:09 AM
To: Mylyn Reviews Project
Subject: [mylyn-reviews-dev] Architecture discussions, process
Hi all,
We're in the midst of planning architecture for the upcoming round of changes. They're quite involved and very interrelated, so we've put together a task for discussion. We want to include as many stake holders as possible in thinking about how we want to build these things out, while trying to avoid paralysis as we need to make progress on some of this right away. I've taken the liberty of adding an agenda item to next week's Mylyn call; we can do it at the end so that people who don't care about it can drop off. Please see:
399656: update reviews version to 2.0.0 https://bugs.eclipse.org/bugs/show_bug.cgi?id=399656
400171: [discussion] Architecture 2.0.0 https://bugs.eclipse.org/bugs/show_bug.cgi?id=400171
http://wiki.eclipse.org/Mylyn/Reviews/Reviews_Convergence_2013
Also, at the risk of over-stepping my aspiring-but-not-confirmed committer status :), I wanted to share some process improvements ideas for team discussion. The current Gerrit based code-review process flow works very well for most cases, but it (arguably) isn't the best fit for the sort of wide-ranging refactorings, design changes and new technology we're planning in this effort. We've had some real frustrations with similar scoped changes in the last effort, so we'd like to avoid that this time around and find a way to improve development flow w/o sacrificing quality. One of the things that Steffen and I have been discussing is the possibility of perhaps doing lighter-weight code reviews for the initial commits and then scheduling more in depth formal code reviews as release(s) approach. This would imply that API will be more fluid for a while, not quite as much as an incubation process, but certainly more so than w/ typical Mylyn projects, and that some features might be i nitially a little less perfect ;) as well. (Naturally, we'll strive to minimize the impact on consumers in any case.) Thoughts?
cheers,
Miles
______________________________
Miles T. Parker
Tasktop
http://tasktop.com
Project Lead, Mylyn MFT and AMP
Committer, Mylyn R4E, Virgo
http://milesparker.blogspot.com
_______________________________________________
mylyn-reviews-dev mailing list
mylyn-reviews-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev
