Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Counting Indigo Projects

This is one of the reasons why I want to tackle this early. We didn't discover the bug and sort out the workaround until very late in the process.

And yes, the new tool handles this nicely. EMF and EMF Compare are my new best friends.


On 12/15/2010 03:53 PM, John Arthorne wrote:
This is probably solved by your new IP log tool, but want to confirm. The 
only thing preventing our project from conforming to this last year was 
the IP log tool. Essentially we didn't find a way for a single person to 
submit a single IP log for all three of our sub-projects. It turned out 
there was a back door way to do this but we didn't discover it until too 
late [1]. Ideally I can select a single project, and the IP log tool will 
generate a log for the entire sub-project tree below that level (for 
whatever level I choose). This would include scraping the data from 
ipzilla for all sub-projects as well (a log for "eclipse" would include 
all CQ's filed against "eclipse.platform", "eclipse.platform.swt", etc).



Wayne Beaton <emo@xxxxxxxxxxx> 
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
12/15/2010 12:43 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


[cross-project-issues-dev] Counting Indigo Projects

Hey folks. Sorry, this message is a little longer than I hoped. Please 
read this if your project is participating in Indigo.

Last year, it was very difficult to determine participation numbers [1]. 
Depending on how we counted, there were four very different numbers. I 
think this makes us look a little silly.

This year, I expect to receive exactly one IP Log and one review 
document for each project that has opted in. More specifically, projects 
that are participating at an aggregate level should provide me with one 
IP Log and one review document that includes information for all the 
aggregated subprojects. Recall that we asked for a short description (~ 
one paragraph) from each project last year. I believe that this was 
valuable and think we should do it again this year. Let me know if you 
have a different opinion. Again, I expect to receive one paragraph for 
each project that opts-in (I'll set up a wiki page).

Web Tools, for example, opts into the simultaneous release at the 
top-level; they provide me with one roll-up IP Log and one combined 
review document for the many sub-projects. The Tools project is 
different in nature, and instead lets its projects opt-in individually, 
with each providing its own IP Log and Review documentation. Both work 
fine, let's just keep the manner in which we participate consistent. In 
my mind, if you are opting in at an aggregate level (say a second-level 
project aggregating several nested third-level projects), then that 
means you've probably got a shared build and provide shared downloads. 
If this isn't the case, then this might be a really good time to rethink 
your participation strategy. Of course, this is just how I think (and is 
merely a guideline), and I defer to the wisdom of the community and 
Planning Council.

If the provided tools are a problem let me know (I hope to release the 
new and improved IP Log Tools very soon). If this just isn't practical 
for you, then maybe you're not participating at the right level.

I am prepared to help you start getting your IP Log and release 
documentation ready now. If you're not sure if you need a CQ, need some 
help determining how to mark bugs and patches for inclusion in your log, 
or have other process-related questions, let me know. Incubating 
projects can also engage with their Architecture Council Mentors to make 
sure that this gets started early.

Please make sure that your project plans are up-to-date. Please also 
ensure that your project's Indigo release is indicated in the Developer 
Portal with appropriate links to your new and noteworthy and 
(eventually) approved IP Log. While you're in the portal, please also 
make sure that your project's descriptionurl and paragraphurl fields [2] 
point to simple HTML documents containing a medium-length and short 
(respectively) description for your project. Neither of these fields 
should contain a link to your project's website (doing so makes  your 
project's summary page look terrible). If this information is 
consistently provided, then I have a fighting chance of automating 
summary documents and such (and then you don't have to bother with that 
sort of thing).

Be aware that the IP team will be making an announcement shortly with 
regard to cut-off dates for IP reviews. Get your Third-party library CQs 
for Indigo releases in quickly (sooner is better than later).

If any of this causes you concern, please let me know. This seems 
reasonable to me, but I understand that there may be mitigating 
circumstances to consider (hopefully I've demonstrated my desire to be 
flexible and reasonable).



cross-project-issues-dev mailing list

_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx

Back to the top