Home » Archived » Board committer reps » Projects vs. Components and Incubation Conformance
| Projects vs. Components and Incubation Conformance [message #2981] |
Sat, 21 April 2007 01:32  |
Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
I request the committer reps' consideration of the following bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178944
The bug is about the Board policy about projects in incubation and what
they must do differently from projects not in incubation.
What was the committer rep's input on this apparent policy decision by
the Board?
Isn't application of this policy at the project level particularly
problematic for projects with some components that are mature and others
that are new/in incubation? Won't this eventually be the case for
nearly all projects? Which conformance rules will be used when this is
the case?
Thanks,
Scott
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #2999 is a reply to message #2981] |
Sat, 21 April 2007 00:55  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Scott,
Before I comment about something that was decided without my input and
hence for which I don't know all the background, let me ask you a
question first. Would your objection be alleviated if the requirements
were relaxed a bit to say that only any download containing components
that have not completed IP review be marked with incubation so that you
could have your normal download as before and one or more separate
downloads for the incubating components? It seems to me the intent of
the rule would be that you know from the download that the contained
code is not fully EPL certified, but for any download that is fully
certified, it seem unnecessary to mark it as incubating when in fact
it's not...
Scott Lewis wrote:
> I request the committer reps' consideration of the following bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=178944
>
> The bug is about the Board policy about projects in incubation and
> what they must do differently from projects not in incubation.
>
> What was the committer rep's input on this apparent policy decision by
> the Board?
>
> Isn't application of this policy at the project level particularly
> problematic for projects with some components that are mature and
> others that are new/in incubation? Won't this eventually be the case
> for nearly all projects? Which conformance rules will be used when
> this is the case?
>
> Thanks,
>
> Scott
>
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #3014 is a reply to message #2999] |
Sat, 21 April 2007 04:26 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Ed Merks wrote:
> Scott,
>
> Before I comment about something that was decided without my input and
> hence for which I don't know all the background, let me ask you a
> question first. Would your objection be alleviated if the requirements
> were relaxed a bit to say that only any download containing components
> that have not completed IP review be marked with incubation so that you
> could have your normal download as before and one or more separate
> downloads for the incubating components?
Yes.
It seems to me the intent of
> the rule would be that you know from the download that the contained
> code is not fully EPL certified, but for any download that is fully
> certified, it seem unnecessary to mark it as incubating when in fact
> it's not...
Yes, that's exactly right. I think the problem is that currently the
conformance is too coarse...it's applied at the entire project level
rather than at the component level.
Scott
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #4014 is a reply to message #3014] |
Sat, 21 April 2007 12:54 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Scott,
That's what I expected. I've kept EMFT around as a satellite project
for EMF just to be able to take advantage of the new rules, but upon
closer inspection it seems I also have to get all the existing
components in there to rename the downloads they've been providing for
years to include the word incubation. It seems to me that having a
version number < 1.0 already implies incubation and hence there is
already sufficient information for users to look at the version number.
I have no problem with marking (parts of) the website, download pages,
and any of the other useful places, and perhaps even the feature/plugin
descriptions or names (but not IDs), but I'm not happy with needing to
put a "stamp on ugliness" right on the name of the zip file itself. I
think the requirement to add the word incubation should perhaps only
apply to downloads that contain unreviewed code and hence are suspect
from an IP point of view and in fact might even need to be withdrawn if
there are IP challenges discovered later. Surely the most important
issue is that the client knows she is downloading "suspect code", but by
having to stamp both reviewed and unreviewed code the same way, the
client is actually worse off, I think. Perhaps others might disagree
that this is too lax, but I think requiring the word incubation on
downloads that are not incubating, clearly a meaningless and confusing
contradiction, for no other reason than to be able to take advantage of
parallel IP rules for new incubating components, doesn't make a lot of
sense. It will just result in a multitude of EMFT like projects, but
perhaps that's the intent.
I'll be interested to hear more opinions and to understand better the
current intent along with the thought processes that went into the
current rules. Hopefully we can come up with some improvements that
perhaps satisfy the actual intent better than does the current set of
rules. One problem Bjorn often points out is that components are not a
very well-defined concept in the foundation's rule books and that
there's no such thing as a subsubproject.
Scott Lewis wrote:
> Ed Merks wrote:
>> Scott,
>>
>> Before I comment about something that was decided without my input
>> and hence for which I don't know all the background, let me ask you a
>> question first. Would your objection be alleviated if the
>> requirements were relaxed a bit to say that only any download
>> containing components that have not completed IP review be marked
>> with incubation so that you could have your normal download as before
>> and one or more separate downloads for the incubating components?
>
>
> Yes.
>
> It seems to me the intent of
>> the rule would be that you know from the download that the contained
>> code is not fully EPL certified, but for any download that is fully
>> certified, it seem unnecessary to mark it as incubating when in fact
>> it's not...
>
>
> Yes, that's exactly right. I think the problem is that currently the
> conformance is too coarse...it's applied at the entire project level
> rather than at the component level.
>
> Scott
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #4387 is a reply to message #4014] |
Tue, 08 May 2007 12:44 |
 David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Sat, 21 Apr 2007 08:54:00 -0400, Ed Merks <merks@ca.ibm.com> wrote:
> One problem Bjorn often points out is that components are not a very well-defined concept in the foundation'srule books and that there's no such thing as a subsubproject.
Darn, I thought it was me that always pointed that out :)
These terms, 'component', "subproject", project, and top level project are definitely ill-defined.
(Almost as if "by design"?!)
Normally this doesn't matter, but, does when some rule is "tied" to one of the terms.
As for incubation policy, seems the trend is (or, should be?) for every top level project to propose one Incubaating Project ... and then all those "loose" components can be developed "there". But, for the most part, "there" doesn't mean much in the internet age ... it does sort of all come down to how named and how packaged, which does call into quetions why the 'project' vs. 'component' distinction is so important. Perhaps it has to do with "management ownership" (at least perceived) That is, "compoents" could be one person working on one small thing with little oversite? I'm just guessing obviously, but I'd guess this rule/policy was "designed by committee" trying to balance the many (some conflicting) goals. And, I don't mean to sound critical ... I do think it's great ... a step in the right direction ... and I'm sure by this time next year, our committer reps will have iterated to have an even better version spelled out :)
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #560290 is a reply to message #2981] |
Sat, 21 April 2007 00:55 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Scott,
Before I comment about something that was decided without my input and
hence for which I don't know all the background, let me ask you a
question first. Would your objection be alleviated if the requirements
were relaxed a bit to say that only any download containing components
that have not completed IP review be marked with incubation so that you
could have your normal download as before and one or more separate
downloads for the incubating components? It seems to me the intent of
the rule would be that you know from the download that the contained
code is not fully EPL certified, but for any download that is fully
certified, it seem unnecessary to mark it as incubating when in fact
it's not...
Scott Lewis wrote:
> I request the committer reps' consideration of the following bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=178944
>
> The bug is about the Board policy about projects in incubation and
> what they must do differently from projects not in incubation.
>
> What was the committer rep's input on this apparent policy decision by
> the Board?
>
> Isn't application of this policy at the project level particularly
> problematic for projects with some components that are mature and
> others that are new/in incubation? Won't this eventually be the case
> for nearly all projects? Which conformance rules will be used when
> this is the case?
>
> Thanks,
>
> Scott
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Projects vs. Components and Incubation Conformance [message #560299 is a reply to message #3014] |
Sat, 21 April 2007 12:54 |
Ed Merks
Messages: 33252
Registered: July 2009 |
Senior Member |
|
|
Scott,
That's what I expected. I've kept EMFT around as a satellite project
for EMF just to be able to take advantage of the new rules, but upon
closer inspection it seems I also have to get all the existing
components in there to rename the downloads they've been providing for
years to include the word incubation. It seems to me that having a
version number < 1.0 already implies incubation and hence there is
already sufficient information for users to look at the version number.
I have no problem with marking (parts of) the website, download pages,
and any of the other useful places, and perhaps even the feature/plugin
descriptions or names (but not IDs), but I'm not happy with needing to
put a "stamp on ugliness" right on the name of the zip file itself. I
think the requirement to add the word incubation should perhaps only
apply to downloads that contain unreviewed code and hence are suspect
from an IP point of view and in fact might even need to be withdrawn if
there are IP challenges discovered later. Surely the most important
issue is that the client knows she is downloading "suspect code", but by
having to stamp both reviewed and unreviewed code the same way, the
client is actually worse off, I think. Perhaps others might disagree
that this is too lax, but I think requiring the word incubation on
downloads that are not incubating, clearly a meaningless and confusing
contradiction, for no other reason than to be able to take advantage of
parallel IP rules for new incubating components, doesn't make a lot of
sense. It will just result in a multitude of EMFT like projects, but
perhaps that's the intent.
I'll be interested to hear more opinions and to understand better the
current intent along with the thought processes that went into the
current rules. Hopefully we can come up with some improvements that
perhaps satisfy the actual intent better than does the current set of
rules. One problem Bjorn often points out is that components are not a
very well-defined concept in the foundation's rule books and that
there's no such thing as a subsubproject.
Scott Lewis wrote:
> Ed Merks wrote:
>> Scott,
>>
>> Before I comment about something that was decided without my input
>> and hence for which I don't know all the background, let me ask you a
>> question first. Would your objection be alleviated if the
>> requirements were relaxed a bit to say that only any download
>> containing components that have not completed IP review be marked
>> with incubation so that you could have your normal download as before
>> and one or more separate downloads for the incubating components?
>
>
> Yes.
>
> It seems to me the intent of
>> the rule would be that you know from the download that the contained
>> code is not fully EPL certified, but for any download that is fully
>> certified, it seem unnecessary to mark it as incubating when in fact
>> it's not...
>
>
> Yes, that's exactly right. I think the problem is that currently the
> conformance is too coarse...it's applied at the entire project level
> rather than at the component level.
>
> Scott
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Projects vs. Components and Incubation Conformance [message #560324 is a reply to message #4014] |
Tue, 08 May 2007 12:44 |
David Williams
Messages: 722
Registered: July 2009 |
Senior Member |
|
|
On Sat, 21 Apr 2007 08:54:00 -0400, Ed Merks <merks@ca.ibm.com> wrote:
> One problem Bjorn often points out is that components are not a very well-defined concept in the foundation'srule books and that there's no such thing as a subsubproject.
Darn, I thought it was me that always pointed that out :)
These terms, 'component', "subproject", project, and top level project are definitely ill-defined.
(Almost as if "by design"?!)
Normally this doesn't matter, but, does when some rule is "tied" to one of the terms.
As for incubation policy, seems the trend is (or, should be?) for every top level project to propose one Incubaating Project ... and then all those "loose" components can be developed "there". But, for the most part, "there" doesn't mean much in the internet age ... it does sort of all come down to how named and how packaged, which does call into quetions why the 'project' vs. 'component' distinction is so important. Perhaps it has to do with "management ownership" (at least perceived) That is, "compoents" could be one person working on one small thing with little oversite? I'm just guessing obviously, but I'd guess this rule/policy was "designed by committee" trying to balance the many (some conflicting) goals. And, I don't mean to sound critical ... I do think it's great ... a step in the right direction ... and I'm sure by this time next year, our committer reps will have iterated to have an even better version spelled out :)
|
|
|
Goto Forum:
Current Time: Fri Nov 08 22:37:10 GMT 2024
Powered by FUDForum. Page generated in 0.03870 seconds |
] 
Search
Help
Register
Login
Home
