On 01/07/2014 10:11 PM, Carl Anderson
wrote:
As much as I would appreciate
other's input, the time I selected works best for the main
people involved in planning this effort. Note that this is
just a planning meeting- my plan is to open bugs to help us
get from where we are to where we need to be. Between now and
M6, I forsee many more discussions and a lot of work. As is
usual in an open source project, anyone that is willing to
help us achieve that goal is welcome to contribute patches to
the bugs, and to chime in on the discussions (both in meetings
and on the mailing lists). So for now, I feel it is best to
stick to the announced time.
Just for curiosity: who are "the main people involved in planning
this effort"? Is this set of people open? If yes, I'd be glad to be
listed at one of them and help where I can.
Although I don't think it's a big deal if I miss this specific
meeting, I believe it would make sense for the future to plan it in
an open manner via a doodle or something to be more welcoming to new
contributors which are not working in US.
After the meeting, please share meeting minutes with links to all
related bugs so people who couldn't attend can know what was
discussed and continue the meeting via emails or bugzillas.
Here are some bugs that you could discuss during this meeting, and
that seems important to me in order to unify the build and reduce
its grain so it's easier for contributors on a single module to just
care about their single module without having to think about WTP as
a whole.
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=425060
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=425061
Also, here is a topic for discussions:
* How will submodules be managed? Who will have to update references
to commits (would the aggregation maintainer decide which commits to
pull in aggregation, or the project contributors -similarly to what
is done currently with map files-) ? Will you use branch reference
(to master or maintenance branches) as allowed by recent version of
git? I believe this last approach is the right one. With Git (and
especially Gerrit) it's easy to use topic branches and to set up
workflows so that master or maintenance branch is always good to be
consumed by aggregator.
* and a more general discussion: when bug #425060 gets fixed, we'll
see that each WTP project provides a p2 repo. In such case, it could
be tempting to stop relying on submodules and create an aggregator
that consumes those p2 sites directly to create the big WTP site
without re-building. I'm not sure which solution is the best for
WTP, but it would be nice to start listing the pros and cons of
aggregation of p2 repo vs re-build via submodules.
Regards,
|