Changes and Graduation Was: [PROPOSAL] html template

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> That's correct, but someone has to run a scrub someday down the road when we
> eventually try to graduate.
Being a PPMC member I'll help out with that when the time comes.

> Here's an example:  Suppose we have to remove playerproductinstall from the
> template for legal reasons and some patch which was made against a version
> that had it accidentally adds it back in.
I don't see that as being an issue.

Even assuming the change is not discussed on list and is just submitted by a committer without "warning". CTR is the policy for small low risk changes. The SVN diffs would be emailed to the list and someone will notice the change. It would be discussed on the list and if it was decided there was a issue the change would be reverted.

The process does allow for mistakes to be made but that's OK as they can be easily and simply corrected by the community.

Are you really suggesting that we hold off making changes (including bug fixes) until after graduation?

Thanks,
Justin

Re: Changes and Graduation Was: [PROPOSAL] html template

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> If I know that folks are submitting patches based on Adobe IP
I'm not going to commit anything that has not been cleared (from Adobe or otherwise) if that is your concern.

> I was hoping we'd review commits for technical merit, not legality. 
In most cases (simple bug fixes and the like) I certainly can't see there being legal issues. Anything large would need to contributor at a minimum to sign a CLR and may need to be checked if is actually allowed to be donated eg companies usually own IP of code written by employees. I'm sure this will be discussed on the list on a case by case basis.

> I am basically saying that I think it is a bad practice to be making
> modifications to files containing IP that isn't cleared
Misunderstanding on my part there. I thought the discussion was about changes in general not changes to files that have yet to be donated. I think we got a little bit off track as nothing has actually been submitted/patched so far it was just discussion on potential changes. I understand your concerns re working on files before they have been donated.

Thanks,
Justin

Re: Changes and Graduation Was: [PROPOSAL] html template

[Alex Harui <ah...@adobe.com>]

On 3/8/12 4:02 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

> Hi,
> 
>> That's correct, but someone has to run a scrub someday down the road when we
>> eventually try to graduate.
> Being a PPMC member I'll help out with that when the time comes.
If I know that folks are submitting patches based on Adobe IP, I will not
trust any reports from folks who don't seem to care and will feel compelled
to look myself. 

> 
>> Here's an example:  Suppose we have to remove playerproductinstall from the
>> template for legal reasons and some patch which was made against a version
>> that had it accidentally adds it back in.
> I don't see that as being an issue.
> 
> Even assuming the change is not discussed on list and is just submitted by a
> committer without "warning". CTR is the policy for small low risk changes. The
> SVN diffs would be emailed to the list and someone will notice the change. It
> would be discussed on the list and if it was decided there was a issue the
> change would be reverted.
> 
> The process does allow for mistakes to be made but that's OK as they can be
> easily and simply corrected by the community.
I was hoping we'd review commits for technical merit, not legality.  And I
was hoping not to have to review every commit or watch for certain files to
be changed.

I am basically saying that I think it is a bad practice to be making
modifications to files containing IP that isn't cleared because you are then
taking a chance that something that is never cleared gets back in.

> 
> Are you really suggesting that we hold off making changes (including bug
> fixes) until after graduation?
Of course not, just wait until you see the Adobe-cleared version get checked
in and make your changes off that copy.

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui