wicket pull request: fixed typo in ioc dep
Github user michaelmosmann closed the pull request at https://github.com/apache/wicket/pull/4
wicket pull request: fixed typo in ioc dep
Github user michaelmosmann closed the pull request at https://github.com/apache/wicket/pull/4
Re: More experimental code happening at Apache
While I do agree with you that we could put experimental code in modules in Wicket, I do not agree with you that all development should take place on Apache Git servers. We no longer live in a centralized world. With Git, development is a decentralized process, taking place on many locations by many people at the same time. I do understand the need for ip-clearance, but moving all development to a central server defeats the purpose of using Git on most points. Git allows open development, where everybody can contribute. Not so long ago, the board asked if Git changed our community dynamics. I think that's exactly what is happening right now. Git is changing our community for the better, and forcing all development back to the central servers will kill that process. Mainline Wicket develoment will still take place on the central Apache repository, because that's where our code lives. Code will have to be integrated into our main repository before it can become part of a release. If code from non-committers needs to be flaged, you can always aks the person to export the commits to mbox with format-patch and attach them to a ticket (the good-old email workflow). But IMHO the PMC should come up with a way to flag git commits without the need to attach them to a ticket. Best regards, Emond On Monday 02 April 2012 14:49:49 Martijn Dashorst wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core - no need to explain to the board why we have zero commits at apache's git and everything happening outside the purview of the PMC at external servers Martijn
Re: More experimental code happening at Apache
After a good discussion with Martijn Dashorst, we agreed that Github (or any other open repository) probably is a good thing, but not yet. The board needs to come up with a way to integrate this into the 'Apache way' of development. Until then, it's probably best to always push your code to the Apache server first, after which you can also push it to Github (it's open source after all). This should keep everone happy. So expect a wicket-atmosphere sandbox branch soon :) Best regards, Emond On Monday 02 April 2012 15:11:45 Emond Papegaaij wrote: While I do agree with you that we could put experimental code in modules in Wicket, I do not agree with you that all development should take place on Apache Git servers. We no longer live in a centralized world. With Git, development is a decentralized process, taking place on many locations by many people at the same time. I do understand the need for ip-clearance, but moving all development to a central server defeats the purpose of using Git on most points. Git allows open development, where everybody can contribute. Not so long ago, the board asked if Git changed our community dynamics. I think that's exactly what is happening right now. Git is changing our community for the better, and forcing all development back to the central servers will kill that process. Mainline Wicket develoment will still take place on the central Apache repository, because that's where our code lives. Code will have to be integrated into our main repository before it can become part of a release. If code from non-committers needs to be flaged, you can always aks the person to export the commits to mbox with format-patch and attach them to a ticket (the good-old email workflow). But IMHO the PMC should come up with a way to flag git commits without the need to attach them to a ticket. Best regards, Emond On Monday 02 April 2012 14:49:49 Martijn Dashorst wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core - no need to explain to the board why we have zero commits at apache's git and everything happening outside the purview of the PMC at external servers Martijn
Wicket Stuff commit access
Hello, I am currently working on getting the examples of openlayers running again. I want to contribute back. Please give me (datazuul github name) commit access to wicketstuff. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Stuff-commit-access-tp4526321p4526321.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Wicket Stuff commit access
Done On Mon, Apr 2, 2012 at 5:19 PM, datazuul ralf.eichin...@pixotec.de wrote: Hello, I am currently working on getting the examples of openlayers running again. I want to contribute back. Please give me (datazuul github name) commit access to wicketstuff. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Stuff-commit-access-tp4526321p4526321.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: More experimental code happening at Apache
What about one (or more) separate apache-hosted repository for experimental projects? Maybe completely separate, maybe a clone just to host the experimental branches. This would - keep the main repository cleaner - ease experimentation, since there will be no subconscious fear of committing junk to the main rep - make some good use of git's distributed features Since a git clone holds the whole history of the repository, including all branches, it makes sense to try to keep it somewhat clean. On Mon, Apr 2, 2012 at 11:35 AM, Emond Papegaaij emond.papega...@topicus.nl wrote: After a good discussion with Martijn Dashorst, we agreed that Github (or any other open repository) probably is a good thing, but not yet. The board needs to come up with a way to integrate this into the 'Apache way' of development. Until then, it's probably best to always push your code to the Apache server first, after which you can also push it to Github (it's open source after all). This should keep everone happy. So expect a wicket-atmosphere sandbox branch soon :) Best regards, Emond On Monday 02 April 2012 15:11:45 Emond Papegaaij wrote: While I do agree with you that we could put experimental code in modules in Wicket, I do not agree with you that all development should take place on Apache Git servers. We no longer live in a centralized world. With Git, development is a decentralized process, taking place on many locations by many people at the same time. I do understand the need for ip-clearance, but moving all development to a central server defeats the purpose of using Git on most points. Git allows open development, where everybody can contribute. Not so long ago, the board asked if Git changed our community dynamics. I think that's exactly what is happening right now. Git is changing our community for the better, and forcing all development back to the central servers will kill that process. Mainline Wicket develoment will still take place on the central Apache repository, because that's where our code lives. Code will have to be integrated into our main repository before it can become part of a release. If code from non-committers needs to be flaged, you can always aks the person to export the commits to mbox with format-patch and attach them to a ticket (the good-old email workflow). But IMHO the PMC should come up with a way to flag git commits without the need to attach them to a ticket. Best regards, Emond On Monday 02 April 2012 14:49:49 Martijn Dashorst wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core - no need to explain to the board why we have zero commits at apache's git and everything happening outside the purview of the PMC at external servers Martijn
Re: More experimental code happening at Apache
from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master or different branches? obviously the big problem is that not everyone has access to the apache git repo, so projects will still pop up on github, etc, if they require collaboration from non-committers. if, this is directed at committers, there are a couple of issues that need to be discussed. 1) sometimes its not possible to release the code, ie wicket-cdi which lacks necessary maven dependencies in central. what do we do in those cases? 2) sometimes a project is just an idea to play with. once we release it as a 0.1 module we have to at least somewhat maintain it. and what if the idea doesnt pan out, is it ok to just drop the module? what happens with the dropped code if someone outside wicket wants to work on it, does it move back to github? -igor On Mon, Apr 2, 2012 at 5:49 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core - no need to explain to the board why we have zero commits at apache's git and everything happening outside the purview of the PMC at external servers Martijn
Re: More experimental code happening at Apache
Martijn and I want to release experimental things in different modules. For that, they need to be stable enough to release, and it needs to be certain that they will be continue to be supported for some time to come, but the code does not need to be finished. For example, the code I'm currently working on integrating Atmosphere with Wicket will meet these conditions. I do understand Martijn's concerns regarding IP-clearance, but I do think the current vission of some members of the board is a little short minded. I read (most of) a discussion about what should be done when an Apache developer develops code at Github and wants to move it to Apache. Although they did not seem to agree entirely, the concenses was that 'large' pieces of code needed to be cleared before moving it to Apache. IMHO, this severely limits the freedom of Apache developers. This also means, your wicket-cdi project will need to be cleared before moving it to the main Wicket repo, even though you and I are the only persons that have committed on the project. Best regards, Emond On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote: from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master or different branches? obviously the big problem is that not everyone has access to the apache git repo, so projects will still pop up on github, etc, if they require collaboration from non-committers. if, this is directed at committers, there are a couple of issues that need to be discussed. 1) sometimes its not possible to release the code, ie wicket-cdi which lacks necessary maven dependencies in central. what do we do in those cases? 2) sometimes a project is just an idea to play with. once we release it as a 0.1 module we have to at least somewhat maintain it. and what if the idea doesnt pan out, is it ok to just drop the module? what happens with the dropped code if someone outside wicket wants to work on it, does it move back to github? -igor On Mon, Apr 2, 2012 at 5:49 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core - no need to explain to the board why we have zero commits at apache's git and everything happening outside the purview of the PMC at external servers Martijn
RE: More experimental code happening at Apache
I know I'm not an Apache committer or even a regular on these discussions. But it seems to me this whole conversation is a little weird. It seems your trying to make culture into policy, or more directly policy that is potentially counter to the current development culture. If the community is developing experimental code elsewhere and then contributing it back, shouldn't that be a Good Thing (tm) and encouraged, it seems to me that restricting to Apache Servers would stifle creativity hamper development, which are both anathema to Open Source in general. Instead of forcing a private experimental server, why not just come up with a procedure to easily incorporate finished modules into Wicket. Also Maybe I'm missing the point, but what's Wrong with starting code in github and/or WicketStuff? Isn't that part of the point of their existence? Is it a loss of history issue once the code is imported into Wicket Proper? Trying to better understand the discussion, Tom Burton -Original Message- From: Emond Papegaaij [mailto:emond.papega...@topicus.nl] Sent: Monday, April 02, 2012 10:25 AM To: dev@wicket.apache.org Subject: Re: More experimental code happening at Apache Martijn and I want to release experimental things in different modules. For that, they need to be stable enough to release, and it needs to be certain that they will be continue to be supported for some time to come, but the code does not need to be finished. For example, the code I'm currently working on integrating Atmosphere with Wicket will meet these conditions. I do understand Martijn's concerns regarding IP-clearance, but I do think the current vission of some members of the board is a little short minded. I read (most of) a discussion about what should be done when an Apache developer develops code at Github and wants to move it to Apache. Although they did not seem to agree entirely, the concenses was that 'large' pieces of code needed to be cleared before moving it to Apache. IMHO, this severely limits the freedom of Apache developers. This also means, your wicket-cdi project will need to be cleared before moving it to the main Wicket repo, even though you and I are the only persons that have committed on the project. Best regards, Emond On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote: from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master or different branches? obviously the big problem is that not everyone has access to the apache git repo, so projects will still pop up on github, etc, if they require collaboration from non-committers. if, this is directed at committers, there are a couple of issues that need to be discussed. 1) sometimes its not possible to release the code, ie wicket-cdi which lacks necessary maven dependencies in central. what do we do in those cases? 2) sometimes a project is just an idea to play with. once we release it as a 0.1 module we have to at least somewhat maintain it. and what if the idea doesnt pan out, is it ok to just drop the module? what happens with the dropped code if someone outside wicket wants to work on it, does it move back to github? -igor On Mon, Apr 2, 2012 at 5:49 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The trend seems to be to do experimental things at wicketstuff or personal github accounts with the intention of bringing that back to Wicket at a later time. IMO this is the wrong way. The Apache Way should be (IMO): also do experimental stuff at Apache, within the purview of the PMC. When things are not mature enough for a 1.0 release, we can either mark it @Experimental or @Beta, or deliver the code in a side project with a version number of 1.0 until the code is mature enough to be included in Wicket proper. In the mean time, the experimental projects will be released with the wicket proper releases, but with a release version 1.0, marking them as unfinished. So for example, a Wicket Push/Comet/Atmosphere project would reside in: wicket/ core/ extensions/ .../ push/ With a pom that specifies the version as 0.1-SNAPSHOT. When released it will released as 0.1, and the next version will become 0.2-SNAPSHOT. Iterate ad nauseam, and when the code base is mature enough, reversion to be on par with the proper Wicket release version (e.g. 6.1). The benefits of this are: - no need to go project hopping, there is one central place where we can find Wicket code, proper and experimental - better visibility of the project within Wicket and the wicket community - easier to attract new core developers to Wicket - no need for software grants and 'white washing' of code through the http://incubator.apache.org/ip-clearance/index.html - clearly defined trajectory for code bases developed by Wicket committers to go into core
Re: More experimental code happening at Apache
Apache has policies that try to keep legal issues (IP ownership, copyright, licensing, patents) in check. I don't know the specifics, but I think any 'big' chunk of contributed code must be checked before accepted. But, if the incremental development is all done on Apache infrastructure, by official committers, it's probably considered safe. The Apache Foundation doesn't exist just to give a big name to random projects. It exists exactly to handle those legal issues, and shield users from them. The process does cause some inconveniences to developers, but it also protects them from themselves. It is very easy for an individual developer to accept into his github repo contributed code that is tainted with patents and copyright. It probably doesn't cause problems most of the time, because github projects are almost always non-relevant (it's not worth it to sue a project with a single user), but don't you think Apache httpd or tomcat could be potential targets to patent trolls if they didn't have the proper safeguards in place? The Apache Software Foundation provides organizational, legal, and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors potential legal exposure. -- http://apache.org/foundation/ The iBatis project folks didn't adapt to the process, so they moved away (the iBatis brand, however, was kept with the Foundation, so they renamed it to MyBatis). In my opinion, they lost most of their relevance with this move, and I sincerely don't want Wicket to go the same route. So, guys, please don't get too upset with the old geezers from the board :) They have pretty good reasons to require most of these little inconveniences. And I'm sure there is some way to use the modern tools we have at our disposal effectively, in a manner compatible to the process. On Mon, Apr 2, 2012 at 3:49 PM, Burton, Tom F (DOR) tom.bur...@alaska.gov wrote: I know I'm not an Apache committer or even a regular on these discussions. But it seems to me this whole conversation is a little weird. It seems your trying to make culture into policy, or more directly policy that is potentially counter to the current development culture. If the community is developing experimental code elsewhere and then contributing it back, shouldn't that be a Good Thing (tm) and encouraged, it seems to me that restricting to Apache Servers would stifle creativity hamper development, which are both anathema to Open Source in general. Instead of forcing a private experimental server, why not just come up with a procedure to easily incorporate finished modules into Wicket. Also Maybe I'm missing the point, but what's Wrong with starting code in github and/or WicketStuff? Isn't that part of the point of their existence? Is it a loss of history issue once the code is imported into Wicket Proper? Trying to better understand the discussion, Tom Burton -Original Message- From: Emond Papegaaij [mailto:emond.papega...@topicus.nl] Sent: Monday, April 02, 2012 10:25 AM To: dev@wicket.apache.org Subject: Re: More experimental code happening at Apache Martijn and I want to release experimental things in different modules. For that, they need to be stable enough to release, and it needs to be certain that they will be continue to be supported for some time to come, but the code does not need to be finished. For example, the code I'm currently working on integrating Atmosphere with Wicket will meet these conditions. I do understand Martijn's concerns regarding IP-clearance, but I do think the current vission of some members of the board is a little short minded. I read (most of) a discussion about what should be done when an Apache developer develops code at Github and wants to move it to Apache. Although they did not seem to agree entirely, the concenses was that 'large' pieces of code needed to be cleared before moving it to Apache. IMHO, this severely limits the freedom of Apache developers. This also means, your wicket-cdi project will need to be cleared before moving it to the main Wicket repo, even though you and I are the only persons that have committed on the project. Best regards, Emond On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote: from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master or different branches? obviously the big problem is that not everyone has access to the apache git repo, so projects will still pop up on github, etc, if they require collaboration from non-committers. if, this is directed at committers, there are a couple of issues that need to be discussed. 1) sometimes its not possible to release the code, ie wicket-cdi which lacks necessary maven dependencies in central. what do we do in those
RE: More experimental code happening at Apache
Thanks, that makes more sense. Sounds like you're looking for a way to do github ..err Apache pull-requests, with an email vote for acceptance? If I've grossly over simplified I apologize, Tom Burton -Original Message- From: tetsuo [mailto:ronald.tet...@gmail.com] Sent: Monday, April 02, 2012 11:46 AM To: dev@wicket.apache.org Subject: Re: More experimental code happening at Apache Apache has policies that try to keep legal issues (IP ownership, copyright, licensing, patents) in check. I don't know the specifics, but I think any 'big' chunk of contributed code must be checked before accepted. But, if the incremental development is all done on Apache infrastructure, by official committers, it's probably considered safe. The Apache Foundation doesn't exist just to give a big name to random projects. It exists exactly to handle those legal issues, and shield users from them. The process does cause some inconveniences to developers, but it also protects them from themselves. It is very easy for an individual developer to accept into his github repo contributed code that is tainted with patents and copyright. It probably doesn't cause problems most of the time, because github projects are almost always non-relevant (it's not worth it to sue a project with a single user), but don't you think Apache httpd or tomcat could be potential targets to patent trolls if they didn't have the proper safeguards in place? The Apache Software Foundation provides organizational, legal, and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors potential legal exposure. -- http://apache.org/foundation/ The iBatis project folks didn't adapt to the process, so they moved away (the iBatis brand, however, was kept with the Foundation, so they renamed it to MyBatis). In my opinion, they lost most of their relevance with this move, and I sincerely don't want Wicket to go the same route. So, guys, please don't get too upset with the old geezers from the board :) They have pretty good reasons to require most of these little inconveniences. And I'm sure there is some way to use the modern tools we have at our disposal effectively, in a manner compatible to the process. On Mon, Apr 2, 2012 at 3:49 PM, Burton, Tom F (DOR) tom.bur...@alaska.gov wrote: I know I'm not an Apache committer or even a regular on these discussions. But it seems to me this whole conversation is a little weird. It seems your trying to make culture into policy, or more directly policy that is potentially counter to the current development culture. If the community is developing experimental code elsewhere and then contributing it back, shouldn't that be a Good Thing (tm) and encouraged, it seems to me that restricting to Apache Servers would stifle creativity hamper development, which are both anathema to Open Source in general. Instead of forcing a private experimental server, why not just come up with a procedure to easily incorporate finished modules into Wicket. Also Maybe I'm missing the point, but what's Wrong with starting code in github and/or WicketStuff? Isn't that part of the point of their existence? Is it a loss of history issue once the code is imported into Wicket Proper? Trying to better understand the discussion, Tom Burton -Original Message- From: Emond Papegaaij [mailto:emond.papega...@topicus.nl] Sent: Monday, April 02, 2012 10:25 AM To: dev@wicket.apache.org Subject: Re: More experimental code happening at Apache Martijn and I want to release experimental things in different modules. For that, they need to be stable enough to release, and it needs to be certain that they will be continue to be supported for some time to come, but the code does not need to be finished. For example, the code I'm currently working on integrating Atmosphere with Wicket will meet these conditions. I do understand Martijn's concerns regarding IP-clearance, but I do think the current vission of some members of the board is a little short minded. I read (most of) a discussion about what should be done when an Apache developer develops code at Github and wants to move it to Apache. Although they did not seem to agree entirely, the concenses was that 'large' pieces of code needed to be cleared before moving it to Apache. IMHO, this severely limits the freedom of Apache developers. This also means, your wicket-cdi project will need to be cleared before moving it to the main Wicket repo, even though you and I are the only persons that have committed on the project. Best regards, Emond On Monday 02 April 2012 10:03:04 Igor Vaynberg wrote: from a couple of replies to this thread i am a little confused. are we talking about keeping experimental things in different modules on master
GitHub Pull Requests
After I saw the pull request below [1] I realized that our GitHub mirror wasn't ever switched to pull from our Git@ASF repo. I requested that it be changed. Jukka apparently updated it because it is now in sync. This means future pull requests should automatically close themselves once the commit hashes from the pull request appear in the requested branch. [1] https://github.com/apache/wicket/pull/4 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: GitHub Pull Requests
also, a quick way to apply a pull request is to format it as a patch and run it through git's mailbox support: curl https://github.com/apache/wicket/pull/4.patch | git am -s (notice .patch appending to pull request url) -igor On Mon, Apr 2, 2012 at 2:56 PM, Jeremy Thomerson jer...@wickettraining.com wrote: After I saw the pull request below [1] I realized that our GitHub mirror wasn't ever switched to pull from our Git@ASF repo. I requested that it be changed. Jukka apparently updated it because it is now in sync. This means future pull requests should automatically close themselves once the commit hashes from the pull request appear in the requested branch. [1] https://github.com/apache/wicket/pull/4 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
