Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [emf-dev] Re: [emft-dev] [Fwd: Re: [eclipse.org-planning-council] XML Project Plans]
Eike,

Comments below.

Eike Stepper wrote:
Hi,

I have a couple of questions:

- http://wiki.eclipse.org/Development_Resources/Project_Plan#Bugs_as_Plan_Items requires me to think about themes. Who benefits from this? Can I specifiy a single dummy theme, too?
In the past, the platform itself had high level themes and we were all expected to conform to those.  I wasn't happy with an approach where the themes were dictated to us with no input from us and we simply paid lip service to them to conform.  So now you can define your own themes.  I'm still not sure the benefit of them. :-P  "Faster and Better" seems like a good theme failing anything more detailed...
- The management of target milestones becomes necessary, too. What can I do if the fix of a bug is applied (merged) to several branches?
It's generally a good idea (at least the way Nick has release notes managed) that when you commit changes you do so against a specific bug and that when done, that set of changes is complete.  Open a new smaller bug and make the "main" one be blocked by it if necessary, to represent increments of progress on a larger problem.
- Is it enough to specifiy the next release instead of smaller milestones (M1, M2, ...)? The ones I'd need are not in the list...
Nick has suggested having just M1-M6 and RC1-RC7 without version numbers so that everyone could reuse them. Other folks didn't like that idea, though it seemed sound to me.  It's easy to add these things directly ourselves.  I can grant access to do this yourself via the portal's committer tools if you don't already have that permission.
- How are the component-level plans merged into a combined project-level plan? I can't enter a plan URL for components in the portal meta data...
Well, that's a bit of a problem.  The new development process allows us to turn out components into projects but the infrastructure for that hasn't caught up.  I definitely want to turn all the EMF and EMFT components into projects and expect that MDT will do the same.  So I'm expecting not have to merge plans.  The foundation's infrastructure will just need to catch up...
- Is there more semantic description of the various elements and attributes? (Which stuff is optional/mandatory, what is the meaning of...)
Not so much.  What you see is all you get. 
- I'm missing a New&Noteworthy section (better: per milestone) to support content like this: http://www.eclipse.org/mylyn/new
So far we've just done the automatic release notes as our New and Noteworthy (which is still better than most projects are doing).  We can try to improve this to better advertise the cool new things we're doing...

Cheers
/Eike


Ed Merks schrieb:
Just a reminder that plans are due at the end of the month.  I'm unfortunately behind on this myself.  I expect components to create a per-component plan as if you were a project, which you soon will be under the newly approved development process, so no one is exempt.  A minimal bare bones plan is fine.  See the attached note for details. Do not follow my bad example and delay until the last minute!  I'll try to set a better example in the coming week... 

_______________________________________________
emft-dev mailing list
emft-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emft-dev
  


_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev

Back to the top