Re: [DISCUSS] How do we want to handle Whiteboard?
Thanks Mark, you are a good man :-) Om On Sun, Apr 14, 2013 at 5:31 AM, Mark Kessler kesslerconsult...@gmail.comwrote: I ended up creating a GITHub account... however, I will probably redo the repo on it since I uploaded a clone of the Flex-SDK with my changes already in it. This means the work I've done already doesn't stand out. so give me about 20 mins and I'll have Logistically speaking that would be least cumbersome process. ... but developers aren't logical lol :p -Mark On Sun, Apr 14, 2013 at 3:34 AM, OmPrakash Muppirala bigosma...@gmail.comwrote: On Apr 13, 2013 11:44 PM, Alex Harui aha...@adobe.com wrote: Is the Git whiteboard read-write? Are there any issues with opening it if we do end up going to Github? If not, can you request that it be opened? I'm not sure how you were going about that for the other repos. Thanks, -Alex Mark, maybe you can create a public GitHub project for now to share your code? Then you will have to manually check it into wherever we decide to host the whiteboard. Logistically speaking that would be least cumbersome process. Thanks, Om
RE: [DISCUSS] How do we want to handle Whiteboard?
Oops, I posted the link [1] in my user page, but not in the dev list. [1] https://github.com/KesslerConsulting/example -Mark -Original Message- From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of OmPrakash Muppirala Sent: Monday, April 15, 2013 4:16 AM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Thanks Mark, you are a good man :-) Om smime.p7s Description: S/MIME cryptographic signature
Re: [DISCUSS] How do we want to handle Whiteboard?
Reviving: Mark Kessler has some stuff that should be on a whiteboard. Can we make the git whiteboard read-write while a couple of you experiment with Github? -Alex On 4/9/13 12:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Apr 9, 2013 at 8:23 AM, Dave Fisher dave2w...@comcast.net wrote: ...The gist is that this PMC is responsible for keeping the IP in shape and doing the work in the open I'd also add that whoever commits (or pushes, in the Git model) to the Apache repository (where all releases must be cut from) takes responsibility for what they commit, under the iCLA that they signed. So it's ultimately up to that committer to make sure they have the right to commit what they're committing, and that the provenance of every line of code can be clearly established. Backing a contribution with an https://issues.apache.org issue where the contributor clearly expresses their intention to donate the code to Apache Flex is helpful, and having an iCLA for that contributor helps put the burden on them for checking that it's their own code that they are contributing. -Bertrand -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
On Apr 13, 2013 11:13 PM, Alex Harui aha...@adobe.com wrote: Reviving: Mark Kessler has some stuff that should be on a whiteboard. Can we make the git whiteboard read-write while a couple of you experiment with Github? -Alex I have been experimenting with GitHub for the past couple of days. Close to something viable. I also tried to get in touch with GitHub support, still waiting for a response from them. Feel free to do what needs to be done in the meantime. Thanks, Om On 4/9/13 12:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Apr 9, 2013 at 8:23 AM, Dave Fisher dave2w...@comcast.net wrote: ...The gist is that this PMC is responsible for keeping the IP in shape and doing the work in the open I'd also add that whoever commits (or pushes, in the Git model) to the Apache repository (where all releases must be cut from) takes responsibility for what they commit, under the iCLA that they signed. So it's ultimately up to that committer to make sure they have the right to commit what they're committing, and that the provenance of every line of code can be clearly established. Backing a contribution with an https://issues.apache.org issue where the contributor clearly expresses their intention to donate the code to Apache Flex is helpful, and having an iCLA for that contributor helps put the burden on them for checking that it's their own code that they are contributing. -Bertrand -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
On Apr 13, 2013 11:44 PM, Alex Harui aha...@adobe.com wrote: Is the Git whiteboard read-write? Are there any issues with opening it if we do end up going to Github? If not, can you request that it be opened? I'm not sure how you were going about that for the other repos. Thanks, -Alex Mark, maybe you can create a public GitHub project for now to share your code? Then you will have to manually check it into wherever we decide to host the whiteboard. Logistically speaking that would be least cumbersome process. Thanks, Om On 4/13/13 11:37 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: On Apr 13, 2013 11:13 PM, Alex Harui aha...@adobe.com wrote: Reviving: Mark Kessler has some stuff that should be on a whiteboard. Can we make the git whiteboard read-write while a couple of you experiment with Github? -Alex I have been experimenting with GitHub for the past couple of days. Close to something viable. I also tried to get in touch with GitHub support, still waiting for a response from them. Feel free to do what needs to be done in the meantime. Thanks, Om On 4/9/13 12:58 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Apr 9, 2013 at 8:23 AM, Dave Fisher dave2w...@comcast.net wrote: ...The gist is that this PMC is responsible for keeping the IP in shape and doing the work in the open I'd also add that whoever commits (or pushes, in the Git model) to the Apache repository (where all releases must be cut from) takes responsibility for what they commit, under the iCLA that they signed. So it's ultimately up to that committer to make sure they have the right to commit what they're committing, and that the provenance of every line of code can be clearly established. Backing a contribution with an https://issues.apache.org issue where the contributor clearly expresses their intention to donate the code to Apache Flex is helpful, and having an iCLA for that contributor helps put the burden on them for checking that it's their own code that they are contributing. -Bertrand -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
I ended up creating a GITHub account... however, I will probably redo the repo on it since I uploaded a clone of the Flex-SDK with my changes already in it. This means the work I've done already doesn't stand out. so give me about 20 mins and I'll have Logistically speaking that would be least cumbersome process. ... but developers aren't logical lol :p -Mark On Sun, Apr 14, 2013 at 3:34 AM, OmPrakash Muppirala bigosma...@gmail.comwrote: On Apr 13, 2013 11:44 PM, Alex Harui aha...@adobe.com wrote: Is the Git whiteboard read-write? Are there any issues with opening it if we do end up going to Github? If not, can you request that it be opened? I'm not sure how you were going about that for the other repos. Thanks, -Alex Mark, maybe you can create a public GitHub project for now to share your code? Then you will have to manually check it into wherever we decide to host the whiteboard. Logistically speaking that would be least cumbersome process. Thanks, Om
Re: [DISCUSS] How do we want to handle Whiteboard?
On Apr 8, 2013, at 10:17 PM, Om wrote: On Mon, Apr 8, 2013 at 9:31 PM, Dave Fisher w...@apache.org wrote: This discussion seems familiar. Justin has the ASF viewpoint for the most part. Talk to infra and David Nalley about the issues in expanding out to github. Regards, Dave Before I bother Infra about this, do you think you can point me to some past discussion about this? The discussion was many months ago on the infra lists. I don't recall if it was public or private. The gist is that this PMC is responsible for keeping the IP in shape and doing the work in the open. The support of GIT has come a long way by Infra. You should ask because there may or may not yet be a document that discusses how far to go. If github is broken then please go to Infra to ask how the project can help. Regards, Dave Thanks, Om Sent from my iPhone On Apr 8, 2013, at 4:35 PM, Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 4:26 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. We will experiment with the organization settings to see if all this is doable. Thanks, Om Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? Before to think about the legal point of re-integrating the contributor work to ApacheFlex, I would like to remind you the technical problem to do it, until we work on Github only, that will be fine but if we want to make fit a one project per repo structure (github) into a multi-project per repo structure (our current per committer repo whiteboard), I can't figure out how to do that. Someone knows ? -Fred -Message d'origine- From: Om Sent: Tuesday, April 09, 2013 1:35 AM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? On Mon, Apr 8, 2013 at 4:26 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. We will experiment with the organization settings to see if all this is doable. Thanks, Om Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
Hi, I would like to remind you the technical problem to do it If the whiteboard is in SVN, Git or Github we have the same issue - the white board area doesn't have to mirror the current SDK structure. Answer is basically patch files in JIRA or branch existing SDK copy files over and see if you can merge and commit/push. The main difference is it easier to check out part of a repo in SVN so with Git or Github we may want a repo/committer rather than a single repo. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
copy files over and see if you can merge and commit/push What would mean deleting the current tree and copy the new one over and not only copy over the existing tree as it would be a problem if parts of the tree have been renamed or moved, right ? The main difference is it easier to check out part of a repo in SVN so with Git or Github we may want a repo/committer rather than a single repo. It's not really the github way and would mean that a github contributor would be able to send pull requests touching files in a project is not initially contributing and has not the agreement of the committer, so to make it work, it would imply more checks for the committer reviewing the pull request before to integrate it but it should be possible I think. -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, April 09, 2013 8:45 AM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Hi, I would like to remind you the technical problem to do it If the whiteboard is in SVN, Git or Github we have the same issue - the white board area doesn't have to mirror the current SDK structure. Answer is basically patch files in JIRA or branch existing SDK copy files over and see if you can merge and commit/push. The main difference is it easier to check out part of a repo in SVN so with Git or Github we may want a repo/committer rather than a single repo. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
On Tue, Apr 9, 2013 at 8:23 AM, Dave Fisher dave2w...@comcast.net wrote: ...The gist is that this PMC is responsible for keeping the IP in shape and doing the work in the open I'd also add that whoever commits (or pushes, in the Git model) to the Apache repository (where all releases must be cut from) takes responsibility for what they commit, under the iCLA that they signed. So it's ultimately up to that committer to make sure they have the right to commit what they're committing, and that the provenance of every line of code can be clearly established. Backing a contribution with an https://issues.apache.org issue where the contributor clearly expresses their intention to donate the code to Apache Flex is helpful, and having an iCLA for that contributor helps put the burden on them for checking that it's their own code that they are contributing. -Bertrand
RE: [DISCUSS] How do we want to handle Whiteboard?
I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike
Re: [DISCUSS] How do we want to handle Whiteboard?
Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). I guess you meant: to create a repo per committer's project (github model). -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, April 08, 2013 6:49 PM To: dev@flex.apache.org Subject: RE: [DISCUSS] How do we want to handle Whiteboard? I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike
Re: [DISCUSS] How do we want to handle Whiteboard?
On 4/8/13 9:49 AM, Michael A. Labriola labri...@digitalprimates.net wrote: I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike I think Greg's point about working in the open is the critical factor. How can we find out what other committers are doing if we use GitHub? Can we get change notifications on the dev list? Otherwise, I think the boundary is at the committer/non-committer level. As a committer you will be working in Git on an Apache Server and you should always be careful about what you are doing, if you are not a committer, you can work with the Git mirrors and do whatever you want and generate a pull request and then a committer has to review. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
The way I would do it is to create an Organization account on GitHub, share the login details with priv...@flex.apache.org. Then, any committer who wants to create a whiteboard can send an email on private@flex.a.o. We add the committer's github id as part of our organization account. We both can perhaps play with the settings to see how best we can get this done. Sounds good. For the Apache V2 licencse agreement an the projects already mavenized, that shouldn't be problem because there's a maven plugin to set it up, for the others, yes, it could be, github has apparently an open API but I never had a look http://developer.github.com/v3/ -Fred -Message d'origine- From: Om Sent: Monday, April 08, 2013 8:50 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? On Mon, Apr 8, 2013 at 11:30 AM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Hi Om, Actually, that seems good. I just wonder if it will be possible to configure the email to send directly in the commit@f.a.o So, it would mean you would open this account, give us the password and then we would add our rsa and finally each one can create it's repo ? -Fred The way I would do it is to create an Organization account on GitHub, share the login details with priv...@flex.apache.org. Then, any committer who wants to create a whiteboard can send an email on private@flex.a.o. We add the committer's github id as part of our organization account. We both can perhaps play with the settings to see how best we can get this done. And another thing I want to try to do is to put a Apache V2 licencse agreement gate before someone can send a 'Pull request' to an official whiteboard github project. I am not sure if GitHub supports such functionality, but given their support for third-party APIs, I imagine we can write a script for this ourselves. Thanks, Om -Message d'origine- From: Om Sent: Monday, April 08, 2013 8:13 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Maybe we can try the whiteboard@github option for a few months and see how it works out? Like the move from SVN to Git, there are always going to be some issues and we cannot think of all of them upfront and have documentation ready. The only way to find out of this will work is to just do it and squash issues as they come along. We timecap the effort and see if we can solve issues to the satisfaction of the PMC, Infra, etc. I think a poll/vote would be more useful at the end of the experiment, not before. We dont want another round of github-supporters-need-to-**answer-this-question-**immediately after we decide to use github and start facing issues. Thanks, Om On Mon, Apr 8, 2013 at 11:00 AM, Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 10:47 AM, Alex Harui aha...@adobe.com wrote: On 4/8/13 9:49 AM, Michael A. Labriola labri...@digitalprimates.net wrote: I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike I think Greg's point about working in the open is the critical factor. How can we find out what other committers are doing if we use GitHub? Can we get change notifications on the dev list? GitHub supports organizations (free for open source orgs) using which we can configure notifications to be sent to any email alias/list we choose. Otherwise, I think the boundary is at the committer/non-committer level. As a committer you will be working in Git on an Apache Server and you should always be careful about what you are doing, if you are not a committer, you can work with the Git mirrors and do whatever you want and generate a pull request and then a committer has to review.
Re: [DISCUSS] How do we want to handle Whiteboard?
On Apr 8, 2013 12:00 PM, Alex Harui aha...@adobe.com wrote: I'm ok with a couple of folks trying it in order to see if it can satisfy everyone and Apache. I'm not sure we need a gate but maybe I'm missing something. I meant the contributor licence agreement. How do we do this for JIRA patches today? Is it an implicit agreement? I am wondering if adding a note in the main Github page would be sufficient? Thanks, Om Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 11:30 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Om, Actually, that seems good. I just wonder if it will be possible to configure the email to send directly in the commit@f.a.o So, it would mean you would open this account, give us the password and then we would add our rsa and finally each one can create it's repo ? -Fred The way I would do it is to create an Organization account on GitHub, share the login details with priv...@flex.apache.org. Then, any committer who wants to create a whiteboard can send an email on private@flex.a.o. We add the committer's github id as part of our organization account. We both can perhaps play with the settings to see how best we can get this done. And another thing I want to try to do is to put a Apache V2 licencse agreement gate before someone can send a 'Pull request' to an official whiteboard github project. I am not sure if GitHub supports such functionality, but given their support for third-party APIs, I imagine we can write a script for this ourselves. Thanks, Om -Message d'origine- From: Om Sent: Monday, April 08, 2013 8:13 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Maybe we can try the whiteboard@github option for a few months and see how it works out? Like the move from SVN to Git, there are always going to be some issues and we cannot think of all of them upfront and have documentation ready. The only way to find out of this will work is to just do it and squash issues as they come along. We timecap the effort and see if we can solve issues to the satisfaction of the PMC, Infra, etc. I think a poll/vote would be more useful at the end of the experiment, not before. We dont want another round of github-supporters-need-to-**answer-this-question-**immediately after we decide to use github and start facing issues. Thanks, Om On Mon, Apr 8, 2013 at 11:00 AM, Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 10:47 AM, Alex Harui aha...@adobe.com wrote: On 4/8/13 9:49 AM, Michael A. Labriola labri...@digitalprimates.net wrote: I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike I think Greg's point about working in the open is the critical factor. How can we find out what other committers are doing if we use GitHub? Can we get change notifications on the dev list? GitHub supports organizations (free for open source orgs) using which we can configure notifications to be sent to any email alias/list we choose. Otherwise, I think the boundary is at the committer/non-committer level. As a committer you will be working in Git on an Apache Server and you should always be careful about what you are doing, if you are not a committer, you can work with the Git mirrors and do whatever you want and generate a pull request and then a committer has to review.
Re: [DISCUSS] How do we want to handle Whiteboard?
I would say, at the moment they want to contribute, it means they accept the contributor license agreement, maybe indicating it in the README would be sufficient but I'm not sure. -Fred -Message d'origine- From: Om Sent: Monday, April 08, 2013 10:31 PM To: Alex Harui Cc: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? On Apr 8, 2013 12:00 PM, Alex Harui aha...@adobe.com wrote: I'm ok with a couple of folks trying it in order to see if it can satisfy everyone and Apache. I'm not sure we need a gate but maybe I'm missing something. I meant the contributor licence agreement. How do we do this for JIRA patches today? Is it an implicit agreement? I am wondering if adding a note in the main Github page would be sufficient? Thanks, Om Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 11:30 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Hi Om, Actually, that seems good. I just wonder if it will be possible to configure the email to send directly in the commit@f.a.o So, it would mean you would open this account, give us the password and then we would add our rsa and finally each one can create it's repo ? -Fred The way I would do it is to create an Organization account on GitHub, share the login details with priv...@flex.apache.org. Then, any committer who wants to create a whiteboard can send an email on private@flex.a.o. We add the committer's github id as part of our organization account. We both can perhaps play with the settings to see how best we can get this done. And another thing I want to try to do is to put a Apache V2 licencse agreement gate before someone can send a 'Pull request' to an official whiteboard github project. I am not sure if GitHub supports such functionality, but given their support for third-party APIs, I imagine we can write a script for this ourselves. Thanks, Om -Message d'origine- From: Om Sent: Monday, April 08, 2013 8:13 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Maybe we can try the whiteboard@github option for a few months and see how it works out? Like the move from SVN to Git, there are always going to be some issues and we cannot think of all of them upfront and have documentation ready. The only way to find out of this will work is to just do it and squash issues as they come along. We timecap the effort and see if we can solve issues to the satisfaction of the PMC, Infra, etc. I think a poll/vote would be more useful at the end of the experiment, not before. We dont want another round of github-supporters-need-to-**answer-this-question-**immediately after we decide to use github and start facing issues. Thanks, Om On Mon, Apr 8, 2013 at 11:00 AM, Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 10:47 AM, Alex Harui aha...@adobe.com wrote: On 4/8/13 9:49 AM, Michael A. Labriola labri...@digitalprimates.net wrote: I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Ultimately I think github is the way to go. If that can't work, the other choice is for infra to create a repo per committer (github model). Git's strength is that of a distributed version control system. We keep trying to centralize it. The whiteboard don't belong in the same repo as the core code in the git model IMO. Regarding official whiteboards and github, its interesting. In some ways, IMO, it's better for the ASF. In this way nothing enters an ASF repo until it officially becomes part of the project and its better for me as I can quickly play and just commit code without worrying about headers, etc. Then we deal with those things prior to an import. Mike I think Greg's point about working in the open is the critical factor. How can we find out what other committers are doing if we use GitHub? Can we get change notifications on the dev list? GitHub supports organizations (free for open source orgs) using which we can configure notifications to be sent to any email alias/list we choose. Otherwise, I think the boundary is at the committer/non-committer level. As a committer you will be working in Git on an Apache Server and you should always be careful about what you are doing, if you are not a committer, you can work with the Git mirrors and do whatever you want and generate a pull request and then a committer has to review.
RE: [DISCUSS] How do we want to handle Whiteboard?
I meant the contributor licence agreement. How do we do this for JIRA patches today? Is it an implicit agreement? I am wondering if adding a note in the main Github page would be sufficient? I was curious about the same thing. Specifically Jira patches.
Re: [DISCUSS] How do we want to handle Whiteboard?
Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
+1 So in git hub are all contributors easily identified and contactable? Each github contributor has an email address since he has a github account -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, April 09, 2013 1:26 AM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
On Mon, Apr 8, 2013 at 4:26 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. We will experiment with the organization settings to see if all this is doable. Thanks, Om Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
HI, Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. How do we know if the pull request is legally allowed to be applied? If a patch is submitted via JIRA at least there's some process and understanding that it's related to Apache and Flex ie they had to create an account in Apache JIRA We will experiment with the organization settings to see if all this is doable. Sounds like the way forward. Can you disable commenting etc on git hub and redirect discussion towards the developer list? Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
On 4/8/13 5:32 PM, Justin Mclean jus...@classsoftware.com wrote: HI, Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. How do we know if the pull request is legally allowed to be applied? If a patch is submitted via JIRA at least there's some process and understanding that it's related to Apache and Flex ie they had to create an account in Apache JIRA Maybe Pull Requests must have a matching JIRA issue? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
This discussion seems familiar. Justin has the ASF viewpoint for the most part. Talk to infra and David Nalley about the issues in expanding out to github. Regards, Dave Sent from my iPhone On Apr 8, 2013, at 4:35 PM, Om bigosma...@gmail.com wrote: On Mon, Apr 8, 2013 at 4:26 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Think we may be missing the point here there's nothing to stop a committer from using github for their own experiments now, but if that code is eventually donated into the Flex project it would need to: 1) Any contributors who have a made a large contribution have signed a ICLA and agree to this code being donated. Just having an ICLA signed may not be enough as it may not been clear that the intent was to move the code to Apache Flex. So in git hub are all contributors easily identified and contactable? Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. 2) Development should be in the open and all current committers notified of progress. At the very least discussion about the code need to take place on the development list (and not elsewhere ie in github) and all changes/diffs to the code need to mailed to commit mailing list. We will experiment with the organization settings to see if all this is doable. Thanks, Om Having the whiteboards in git hub would be no different. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
Sounds good to me as well. Redirecting comments sounds like a good idea. On Apr 9, 2013, at 3:32 AM, Justin Mclean wrote: HI, Notifying the contributer when they send a pull request to a committer's whiteboard project should serve exactly this purpose. How do we know if the pull request is legally allowed to be applied? If a patch is submitted via JIRA at least there's some process and understanding that it's related to Apache and Flex ie they had to create an account in Apache JIRA We will experiment with the organization settings to see if all this is doable. Sounds like the way forward. Can you disable commenting etc on git hub and redirect discussion towards the developer list? Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
A lot of the people who currently have whiteboards have copies of the SDK in there... Would it still be possible to work on a private copy of the SDK in the whiteboard? The way I see it happening would be that you would fork the main SDK, and work on it in your own fork rather than the whiteboard... The other issue would be to bring the code back to the asf repo -- I could see that as problematic as well. -Nick On Fri, Apr 5, 2013 at 2:23 AM, Justin Mclean jus...@classsoftware.comwrote: Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 11:23 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Assuming we get the git hub mirrors up and working there nothing stopping anyone from using github to supply patches and diff in the usual way. A git hub pull request can be converted directly into a patch file and applied easily. There's one outstanding issue in how do we close pull requests, I asked this before but no one seem to know the answer. I am confused, how is this related to the current topic under discussion? I don't think it would be possible to use github for the official whiteboards as it brings up a number of issues for infra and the ASF ie knowing who contributed, licensing issues etc etc basically the normal issues for bit of donated code. GitHub keeps track of everything. Code that goes into the whiteboard is generally unstructured, experimental code. Only the committer decides when that goes into an official repo. This has to be done manually and the commit comments should have all the information about who contributed to this piece of code. Which means that we cannot bring the GitHub history with us as well. I dont see the need for that. If someone wants to see the history, they can always go to the relevant GitHub repo and look at it. Thanks, Om Thanks, Justin
Re: [DISCUSS] How do we want to handle Whiteboard?
Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 12:44 PM, Om bigosma...@gmail.com wrote: Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. I like the idea of the whiteboard being github based. Stops all the discussion of what a non-committer can/cannot do. -- Jonathan Campos
Re: [DISCUSS] How do we want to handle Whiteboard?
Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain? Harbs On Apr 4, 2013, at 8:44 PM, Om wrote: Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 11:41 AM, Harbs harbs.li...@gmail.com wrote: Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain? Harbs To be clear, we are talking only about moving the Whiteboard repo to GitHub. There are no plans to move all the other repos to GitHub any time soon. Thanks, Om On Apr 4, 2013, at 8:44 PM, Om wrote: Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
Released source code must be stored on Apache servers. Did we get approval to use github. I would imagine there would be concerns about ownership of pulled code. Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Harbs harbs.li...@gmail.com wrote: Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain? Harbs On Apr 4, 2013, at 8:44 PM, Om wrote: Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
On Thu, Apr 4, 2013 at 11:49 AM, Alex Harui aha...@adobe.com wrote: Released source code must be stored on Apache servers. Did we get approval to use github. I would imagine there would be concerns about ownership of pulled code. I am not sure if we need approval for this. How is it different than someone contributing the same code as a patch via JIRA? In both cases, the committer has to actively take steps to check the code in question into the official git repo. Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Harbs harbs.li...@gmail.com wrote: Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain? Harbs On Apr 4, 2013, at 8:44 PM, Om wrote: Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
Hi, I see another point, how to conserve the history of what has been done in github, I mean, is there a way to apply a patch if the parent commit of the patch hasn't got the same hash in the Apache whiteboard repo than the github one ? -Fred -Message d'origine- From: Greg Reddin Sent: Thursday, April 04, 2013 8:59 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? On Thu, Apr 4, 2013 at 12:44 PM, Om bigosma...@gmail.com wrote: Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. I like the idea of using Github for all the reasons mentioned. But I think there are three issues that need some discussion before we go forward with it. First, how will we ensure that we are developing software in community? If everything is worked in our repo or submitted patches, then I can follow the development by subscribing to the commits list. If it's at Github, then I have to know about it and I have to subscribe to an external feed for updates. So, for it to work in the Apache Way, the dev list needs to know where and how to watch it or contribute to it. This seems doable, but it's not automatic. One thing we want to avoid is one or more people working on something externally for a long period of time, then bringing it to the project as a large chunk. The second issue is ensuring provenance. If a committer commits something or a contributor submits a patch in Jira we know where it came from and who contributed it. Does a Github whiteboard give us the same traceability of contributions? Granted, it's possible for someone to contribute something they don't have rights to even in the current model, but would we still have the traceability at Github? Thirdly, how will we identify folks who should be nominated as committers? We'd need to know all the places at Github to keep track of and we'd need a way to be made aware of someone's contributions. Again, I think these are doable, but I think we need to consider how and what. Greg
Re: [DISCUSS] How do we want to handle Whiteboard?
Yes. Of course we're not discussing release code. I don't think there's work being done on release code in the whiteboards. Is there? This brings up a question in my mind: What happens when code in a whiteboard is added to the official development branch? I assume it's removed from the whiteboard. Right? Would that be a workable situation using Github? What happens if someone forks the work? Harbs On Apr 4, 2013, at 9:54 PM, Om wrote: On Thu, Apr 4, 2013 at 11:49 AM, Alex Harui aha...@adobe.com wrote: Released source code must be stored on Apache servers. Did we get approval to use github. I would imagine there would be concerns about ownership of pulled code. I am not sure if we need approval for this. How is it different than someone contributing the same code as a patch via JIRA? In both cases, the committer has to actively take steps to check the code in question into the official git repo. Sent via the PANTECH Discover, an ATT 4G LTE smartphone. Harbs harbs.li...@gmail.com wrote: Github definitely simplifies things. Are there any advantages to keeping content on Apache's domain? Harbs On Apr 4, 2013, at 8:44 PM, Om wrote: Any more thoughts on how to manage the whiteboard repo? If its okay with everyone, I will go ahead and start a VOTE thread soon. Personally, I like the option of working on GitHub for the whiteboard. In a way it levels the playing field of committer vs. non-committer. This could foster more community involvement. Going back to my first days of contributing to Apache Flex, I did all my Installer related work on GitHub and just posted the link on the dev forum here. After a lot of discussion, Justin (who was a committer by then) and a couple of non-committers forked my project and started sending me Pull requests. This gave me a more flexibility in how I contributed as a non-committer. The fork that Justin did on GitHub can be considered as a whiteboard area, except that it let him foster community participation (like me and the other non-committers) And of course, working with GitHub is a breeze. Once you create your own space, you can create unlimited projects and branches. Thanks, Om On Thu, Mar 21, 2013 at 1:54 PM, Alex Harui aha...@adobe.com wrote: The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [DISCUSS] How do we want to handle Whiteboard?
4. Let whiteboards remain in SVN +1 -Fred -Message d'origine- From: Om Sent: Thursday, March 21, 2013 9:34 PM To: dev@flex.apache.org Subject: [DISCUSS] How do we want to handle Whiteboard? Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred
Re: [DISCUSS] How do we want to handle Whiteboard?
Just to make it clear, this is not the VOTE thread. We usually discuss pros and cons of each item in a DISCUSS thread before calling a vote. Thanks, Om On Thu, Mar 21, 2013 at 1:37 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: 4. Let whiteboards remain in SVN +1 -Fred -Message d'origine- From: Om Sent: Thursday, March 21, 2013 9:34 PM To: dev@flex.apache.org Subject: [DISCUSS] How do we want to handle Whiteboard? Sorry, I have not been tracking the votes. Let me start up a new vote with these options: ==**= What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/**dg7hplezkzwiroeshttp://markmail.org/message/dg7hplezkzwiroes ) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN ==**= If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.com **wrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred
Re: [DISCUSS] How do we want to handle Whiteboard?
Ok :) A branch (and generaly the main branch of a repo) should belong to a project (a directory structure) and not shared by force (it can be a local branch only), the point is that, even with what INFRA is proposing us, as soon as we will want to do a branch, we'll have to incorporate every whiteboard inside of it because there's only one master for everybody, so, that's not good, create a branch per user in the whiteboard is almost the same problematic, instead of being horizontal problem (shared file structure), it is a vertical one (shared branches), moving to github, yes, only if there's a repo per committer but I'm not sure it is the apache way and finally staying on svn allows us to use svn or git-svn (which takes a lot of time to initialize) for those who want to use git. Finally, I guess the 2 last ones are close to what I need and really the last one let me the possibility to have a repo per project (even if there are inside the same svn repo) if I go by git-svn. -Fred -Message d'origine- From: Om Sent: Thursday, March 21, 2013 9:40 PM To: dev@flex.apache.org Subject: Re: [DISCUSS] How do we want to handle Whiteboard? Just to make it clear, this is not the VOTE thread. We usually discuss pros and cons of each item in a DISCUSS thread before calling a vote. Thanks, Om On Thu, Mar 21, 2013 at 1:37 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: 4. Let whiteboards remain in SVN +1 -Fred -Message d'origine- From: Om Sent: Thursday, March 21, 2013 9:34 PM To: dev@flex.apache.org Subject: [DISCUSS] How do we want to handle Whiteboard? Sorry, I have not been tracking the votes. Let me start up a new vote with these options: ==**= What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/**dg7hplezkzwiroeshttp://markmail.org/message/dg7hplezkzwiroes ) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN ==**= If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.com **wrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred
Re: [DISCUSS] How do we want to handle Whiteboard?
The way I see it: #1 Pros: Uses Git. Therefore you only need to know one SCM. Any work with a rich branching history retains that history when landing in the main repos. #1 Cons: 240MB initial download. It took several hours for some folks. #2 Pros: Not sure. #2 Cons: I think it would be hard to switch between branches when you have changes pending if you want to help out on someone else's whiteboard? Fred seemed to have other concerns. #3 Pros: Much easier to set up repos, I think. #3 Cons: Unclear about Apache approval. Have to be careful about who else contributes to your code. #4 Pros: Smaller initial download #4 Cons: Might be more work to transfer source from SVN to Git with history? For me, retaining history is way more important than waiting 2.5 hours once for the initial download. On 3/21/13 1:34 PM, Om bigosma...@gmail.com wrote: Sorry, I have not been tracking the votes. Let me start up a new vote with these options: === What to do with Whiteboard? 1. Use the sparse checkout option as described here ( http://markmail.org/message/dg7hplezkzwiroes) 2. Create a branch per user in the whiteboard 3. Move to github for whiteboards 4. Let whiteboards remain in SVN === If there are more options, please add it to the discussion here. I will give some time for discussion before starting an official VOTE thread. Thanks, Om On Thu, Mar 21, 2013 at 1:30 PM, Frédéric THOMAS webdoubl...@hotmail.comwrote: Om, Btw, I remove my vote of 3.1 and give my +1 to the 3.4 (stay on svn), that's a lazy vote, I can change my mind ? -Fred -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
