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: [] XML Project Plans]


I only wished that the new project-plan.xml format would allow me to maintain the N&N data, too, since there's already the data of milestones and so. We also started to collect the data for new features in an html files i the doc plugin:
But an xml database would be smarter ;-)


Nick Boldt schrieb:
Re: N&N:

Most projects have chosen to take the time to advertise to adopters what's new in their latest release. The "we're too busy to bother" approach is another way, but if you don't market your new features, fewer people will know about them. If "marketing" is a taboo word, consider "advertising", "documentation", or "evangelism." :)

So, you'll notice in the wiki some projects have actual N&N per component, others have per-project (but updated per-milestone rather than per-release), and still others have "see the release notes" pages.

This is your opportunity to grow your user base (and, if you're doing N&N every milestone, to encourage early adopters). Don't waste it!


As to themes, I like "More With Less", which can be interpreted in numerous (and humorous) ways, and still sounds like an admirable goal even if it's partly touch-in-cheek. :)


Ed Merks wrote:

Comments below.

Eike Stepper wrote:

I have a couple of questions:

- 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:
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...

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... ------------------------------------------------------------------------

emf-dev mailing list

Back to the top