[Fwd: Re: [eclipse.org-planning-council] XML Project Plans]

[Ed Merks-2]

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


As far as I know, the deadlines are (still) as described previously on this list:

http://dev.eclipse.org/mhonarc/lists/eclipse.org-planning-council/msg01422.html

From:	Scott Lewis <slewis@...>
To:	"eclipse.org-planning-council" <eclipse.org-planning-council@...>
Cc:	Cross project issues <cross-project-issues-dev@...>
Date:	09/09/2008 01:29 PM
Subject:	Re: [eclipse.org-planning-council] XML Project Plans

---

Someone who knows...please provide/announce some definitive input about
the deadline.

Thanks for the page and tooling Martin.

Scott

Oberhuber, Martin wrote:
> Hi all,
>  
> I'm not exactly sure about the deadlines, but since I think pretty soon
> every project needs to specify its project plan by XML in order to support
> producing a combined Roadmap for the Board. I therefore added some
> information to the corresponding Wiki page:
>  
> http://wiki.eclipse.org/Development_Resources/Project_Plan
>  
> In case you've not been following bug 243303
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=243303>, the project plan
> specification was recently changed to require XML namespaces,
> and allow validation through an XSD. I wrote a little shellscript to
> convert the previous (non-namespace) project plan into the
> current required version.
>  
> This shellscript is available form the Wiki page mentioned above,
> and the page also has some information about how to use WTP's
> XML editor to work on the XML project plan (with automatic
> validation) or preview the XML as locally rendered HTML before
> committing it.
>  
> If you find any issues, I recommend filing a bug
> <https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Portal>against
> the
> Community / Portal component.
>  
> Enjoy,
> --
> *Martin Oberhuber*, Senior Member of Technical Staff, *Wind River*
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>  
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@...
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@... to request removal.

_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@...
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@... to request removal.



_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@...
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@... to request removal.
_______________________________________________
emf-dev mailing list
emf-dev@...
https://dev.eclipse.org/mailman/listinfo/emf-dev

[portal on behalf of Eike Stepper]

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?
- The management of target milestones becomes necessary, too. What can I do if the fix of a bug is applied (merged) to several branches?
- Is it enough to specifiy the next release instead of smaller milestones (M1, M2, ...)? The ones I'd need are not in the list...
- 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...
- Is there more semantic description of the various elements and attributes? (Which stuff is optional/mandatory, what is the meaning of...)
- I'm missing a New&Noteworthy section (better: per milestone) to support content like this: http://www.eclipse.org/mylyn/new

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@...
https://dev.eclipse.org/mailman/listinfo/emft-dev
  

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

[Ed Merks-2]

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@...
https://dev.eclipse.org/mailman/listinfo/emft-dev
  

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

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

[Nick Boldt-2]

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.

http://wiki.eclipse.org/Category:EMF
    http://wiki.eclipse.org/EMF/EMF_2.3/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/EMF_2.4/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/MQ%2C_MT%2C_and_VF_1.1/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/MQ%2C_MT%2C_and_VF_1.2/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/Net4j_1.0/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/CDO_1.0/New_and_Noteworthy
    http://wiki.eclipse.org/EMF/Teneo_1.0/New_and_Noteworthy

http://wiki.eclipse.org/Model_Development_Tools_(MDT)#Planning
    http://wiki.eclipse.org/MDT_1.0_New_and_Noteworthy
    http://wiki.eclipse.org/MDT_1.1_New_and_Noteworthy

http://wiki.eclipse.org/M2T_New_and_Noteworthy

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

Nick

Ed Merks wrote:

> 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...
>>
>> 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
emf-dev@...
https://dev.eclipse.org/mailman/listinfo/emf-dev

[portal on behalf of Eike Stepper]

Hi,

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:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org.eclipse.emf.cdo/doc/org.eclipse.emf.cdo.doc/new/new.htm?root=Modeling_Project&view=co
But an xml database would be smarter ;-)

Cheers
/Eike


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.
>
> http://wiki.eclipse.org/Category:EMF
>    http://wiki.eclipse.org/EMF/EMF_2.3/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/EMF_2.4/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/MQ%2C_MT%2C_and_VF_1.1/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/MQ%2C_MT%2C_and_VF_1.2/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/Net4j_1.0/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/CDO_1.0/New_and_Noteworthy
>    http://wiki.eclipse.org/EMF/Teneo_1.0/New_and_Noteworthy
>
> http://wiki.eclipse.org/Model_Development_Tools_(MDT)#Planning
>    http://wiki.eclipse.org/MDT_1.0_New_and_Noteworthy
>    http://wiki.eclipse.org/MDT_1.1_New_and_Noteworthy
>
> http://wiki.eclipse.org/M2T_New_and_Noteworthy
>
> 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. :)
>
> Nick
>
> Ed Merks wrote:
>> 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...
>>>
>>> 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
> emf-dev@...
> https://dev.eclipse.org/mailman/listinfo/emf-dev
>

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