Re: [VOTE] release deltacloud 0.4.1, rc1
+1 On Oct 4, 2011, at 1:00 PM, David Lutterkort wrote: Hi all, I just uploaded the first release candidate for Deltacloud 0.4.1. The rc is available from http://people.apache.org/~lutter/deltacloud/0.4.1/rc1/ Please vote on the release candidate by Saturday, 2011-10-07 15:00 PDT KEYS: http://www.apache.org/dist/incubator/deltacloud/KEYS svn tag: https://svn.apache.org/repos/asf/incubator/deltacloud/tags/release-0.4.1-rc1 This release is mostly a bug fix release. It also adds support for the Google Storage API. Detailed list of changes: * change how dependencies are managed: canonical deps are now in the gemspecs Server: * clarify how user_data injection should work; make sure all drivers accept base64 encoded data and make the decoded version available to instance * fix URL generation so that server works when run behind a reverse proxy * init script: honor defaults from sysconfig file * init script: fix 'status', properly background deltacloudd * deltacloudd: support verbose option * Drivers: + Condor - use UUIDTools instead of UUID to simplify deps + Google - new driver for Google storage API + RHEV-M - treat status as case-insensitive - inject data through a virtual floppy rather than modifying the instance storage directly + vSphere - report minimum of max memory across all hosts in a data center, so that instances can be placed on any host - user_data is placed in file 'deltacloud-user-data.txt' Client: * fix parsing of enums in HWP properties * fix handling of float value for number of vCPU in HWP I will update the website and docs to reflect those changes in time for the official release. David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[SITE] Split projects/index.html
The podling status sumnmary page currently contains details of all podlings, past and present. It's already quite long, and it is going to get longer and longer. Would it be sensible to split the page, perhaps into one page for each status? Or maybe current, graduated and other? If it's important to have a single page that contains all the podling names ever used for searching purposes, then we could create a simplified version of podlings.xml, with links to more detailed entries. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [SITE] Split projects/index.html
On Tue, Oct 11, 2011 at 4:50 PM, sebb seb...@gmail.com wrote: The podling status sumnmary page currently contains details of all podlings, past and present. It's already quite long, and it is going to get longer and longer. Would it be sensible to split the page, perhaps into one page for each status? Or maybe current, graduated and other? I have no problem with the length of the size, but I am also not opposed to this change. If you would change it, then I would prefer current, graduate and other, b/c retired and dormant are pretty similar. If it's important to have a single page that contains all the podling names ever used for searching purposes, then we could create a simplified version of podlings.xml, with links to more detailed entries. If needed, the simplified version of podlings.xml should be generated with xslt too Cheers Christian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] release deltacloud 0.4.1, rc1
+1 On 10/11/2011 08:40 AM, Jim Jagielski wrote: +1 On Oct 4, 2011, at 1:00 PM, David Lutterkort wrote: Hi all, I just uploaded the first release candidate for Deltacloud 0.4.1. The rc is available from http://people.apache.org/~lutter/deltacloud/0.4.1/rc1/ Please vote on the release candidate by Saturday, 2011-10-07 15:00 PDT KEYS: http://www.apache.org/dist/incubator/deltacloud/KEYS svn tag: https://svn.apache.org/repos/asf/incubator/deltacloud/tags/release-0.4.1-rc1 This release is mostly a bug fix release. It also adds support for the Google Storage API. Detailed list of changes: * change how dependencies are managed: canonical deps are now in the gemspecs Server: * clarify how user_data injection should work; make sure all drivers accept base64 encoded data and make the decoded version available to instance * fix URL generation so that server works when run behind a reverse proxy * init script: honor defaults from sysconfig file * init script: fix 'status', properly background deltacloudd * deltacloudd: support verbose option * Drivers: + Condor - use UUIDTools instead of UUID to simplify deps + Google - new driver for Google storage API + RHEV-M - treat status as case-insensitive - inject data through a virtual floppy rather than modifying the instance storage directly + vSphere - report minimum of max memory across all hosts in a data center, so that instances can be placed on any host - user_data is placed in file 'deltacloud-user-data.txt' Client: * fix parsing of enums in HWP properties * fix handling of float value for number of vCPU in HWP I will update the website and docs to reflect those changes in time for the official release. David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [SITE] Split projects/index.html
On Tue, Oct 11, 2011 at 10:50 AM, sebb seb...@gmail.com wrote: If it's important to have a single page that contains all the podling names ever used for searching purposes, then we could create a simplified version of podlings.xml, with links to more detailed entries. Does it make sense for the details such as description and mentors to be pushed out to site-author/projects/podling.xml, and pages to be generated from time to time from a compilation of the podling files and a simplified podlings.xml? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Clutch blue-green background colour obscures entries
Clutch uses a blue-green background colour for satisfactory entries. However, many entries include clickable blue links which are not very distinct from the background. I suggest changing the background to light green (#90EE90) which works much better for me. See the sample lines for Ace and Airavata at http://people.apache.org/~sebb/clutch.html#clutch OK to change that? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [SITE] Split projects/index.html
On 11 October 2011 18:09, Donald Whytock dwhyt...@gmail.com wrote: On Tue, Oct 11, 2011 at 10:50 AM, sebb seb...@gmail.com wrote: If it's important to have a single page that contains all the podling names ever used for searching purposes, then we could create a simplified version of podlings.xml, with links to more detailed entries. Does it make sense for the details such as description and mentors to be pushed out to site-author/projects/podling.xml, and pages to be generated from time to time from a compilation of the podling files and a simplified podlings.xml? Not at present, because the podling.xml files don't have a totally predictable structure; they are a mixture of data and markup. One of the reasons for moving to podlings.xml was to simplify editting and processing of the data. If podling.xml ever migrates to an XML file with a DTD, we could then consider fetching some data from it. However, I think we still need the central podlings.xml file. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
New bootstrap CSS messes up display of all internal name definitions
The new CSS changes the default setting for links, by removing underlines unless the mouse hovers over the link. However, this has broken all the internal name definitions. These now look like links - they are blue, and get underlined when hovered over. See for example [1] where the table headings are blue (they should be black). But just about every file also has similar headings that are now broken. I've no idea whether it is possible for CSS to distinguish between a href=#xxx and a name=xyz. One way to fix this would be to change the site generation Anakia stylesheet to use: h3 id='incubator' 1. Incubation /h3 rather than: h3 a name=incubator1. Incubation/a /h3 However, this will affect nearly every single html file, so before I commit this change and flood the commits list with e-mails, is there a CSS-expert who can confirm whether or not it's possible to change the behaviour of a href without affecting a name ? [I realise that the name attribute is deprecated, but the id attribute behaves exactly the same.] [1] http://incubator.apache.org/projects/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
Should be possible as described here: http://www.w3.org/TR/CSS2/selector.html#attribute-selectors not sure on browser compatibility though On Tue, Oct 11, 2011 at 9:50 PM, sebb seb...@gmail.com wrote: The new CSS changes the default setting for links, by removing underlines unless the mouse hovers over the link. However, this has broken all the internal name definitions. These now look like links - they are blue, and get underlined when hovered over. See for example [1] where the table headings are blue (they should be black). But just about every file also has similar headings that are now broken. I've no idea whether it is possible for CSS to distinguish between a href=#xxx and a name=xyz. One way to fix this would be to change the site generation Anakia stylesheet to use: h3 id='incubator' 1. Incubation /h3 rather than: h3 a name=incubator1. Incubation/a /h3 However, this will affect nearly every single html file, so before I commit this change and flood the commits list with e-mails, is there a CSS-expert who can confirm whether or not it's possible to change the behaviour of a href without affecting a name ? [I realise that the name attribute is deprecated, but the id attribute behaves exactly the same.] [1] http://incubator.apache.org/projects/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Interest in Apache beanshell incubation?
(Sorry for crossposting for this time, please redirect any response only to general@incubator) Hello; As some advocacy related to Apache OpenOffice.org, I asked the beanshell.org guys to adopt the Apache License 2. Not only did Patrick Niemeyer and Daniel Leuck agree to this, they were willing to transfer beanshell to the ASF. They are willing to sign a SGA, hand over a mirror of their SVN server and a dump of their CWiki. They are busy in their own projects though, so in general they would want to spend time in an incubation process themselves. http://www.beanshell.org/ I see there are several Apache projects (BSF, Camel, Script, AOOo) using Beanshell so I think this would be beneficial to the ASF. Perhaps someone already used to Apache ways, would like to take the lead in an incubation process? best regards, Pedro. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
On 11 October 2011 20:59, Francis De Brabandere franci...@gmail.com wrote: Should be possible as described here: http://www.w3.org/TR/CSS2/selector.html#attribute-selectors not sure on browser compatibility though Thanks very much! Works for me with FireFox, Opera, Chrome, IE. I'll update the CSS accordingly. We can reserve changing the Anakia style in case there are complaints from other browsers. On Tue, Oct 11, 2011 at 9:50 PM, sebb seb...@gmail.com wrote: The new CSS changes the default setting for links, by removing underlines unless the mouse hovers over the link. However, this has broken all the internal name definitions. These now look like links - they are blue, and get underlined when hovered over. See for example [1] where the table headings are blue (they should be black). But just about every file also has similar headings that are now broken. I've no idea whether it is possible for CSS to distinguish between a href=#xxx and a name=xyz. One way to fix this would be to change the site generation Anakia stylesheet to use: h3 id='incubator' 1. Incubation /h3 rather than: h3 a name=incubator1. Incubation/a /h3 However, this will affect nearly every single html file, so before I commit this change and flood the commits list with e-mails, is there a CSS-expert who can confirm whether or not it's possible to change the behaviour of a href without affecting a name ? [I realise that the name attribute is deprecated, but the id attribute behaves exactly the same.] [1] http://incubator.apache.org/projects/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
On Tue, Oct 11, 2011 at 9:50 PM, sebb seb...@gmail.com wrote:
The new CSS changes the default setting for links, by removing
underlines unless the mouse hovers over the link.
However, this has broken all the internal name definitions.
These now look like links - they are blue, and get underlined when hovered
over.
See for example [1] where the table headings are blue (they should be black).
But just about every file also has similar headings that are now broken.
I've no idea whether it is possible for CSS to distinguish between a
href=#xxx and a name=xyz.
One way to fix this would be to change the site generation Anakia
stylesheet to use:
h3 id='incubator'
1. Incubation
/h3
rather than:
h3
a name=incubator1. Incubation/a
/h3
However, this will affect nearly every single html file, so before I
commit this change and flood the commits list with e-mails, is there a
CSS-expert who can confirm whether or not it's possible to change the
behaviour of a href without affecting a name ?
Is there any reason why we should not format:
h2 a {
text-decoration: none;
color: black;
}
[I realise that the name attribute is deprecated, but the id attribute
behaves exactly the same.]
[1] http://incubator.apache.org/projects/index.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
On Tue, Oct 11, 2011 at 10:39 PM, sebb seb...@gmail.com wrote: On 11 October 2011 20:59, Francis De Brabandere franci...@gmail.com wrote: Should be possible as described here: http://www.w3.org/TR/CSS2/selector.html#attribute-selectors not sure on browser compatibility though Thanks very much! Works for me with FireFox, Opera, Chrome, IE. Tested with different versions? http://dev.l-c-n.com/CSS3-selectors/browser-support.php But would say looks according to this table. I'll update the CSS accordingly. We can reserve changing the Anakia style in case there are complaints from other browsers. On Tue, Oct 11, 2011 at 9:50 PM, sebb seb...@gmail.com wrote: The new CSS changes the default setting for links, by removing underlines unless the mouse hovers over the link. However, this has broken all the internal name definitions. These now look like links - they are blue, and get underlined when hovered over. See for example [1] where the table headings are blue (they should be black). But just about every file also has similar headings that are now broken. I've no idea whether it is possible for CSS to distinguish between a href=#xxx and a name=xyz. One way to fix this would be to change the site generation Anakia stylesheet to use: h3 id='incubator' 1. Incubation /h3 rather than: h3 a name=incubator1. Incubation/a /h3 However, this will affect nearly every single html file, so before I commit this change and flood the commits list with e-mails, is there a CSS-expert who can confirm whether or not it's possible to change the behaviour of a href without affecting a name ? [I realise that the name attribute is deprecated, but the id attribute behaves exactly the same.] [1] http://incubator.apache.org/projects/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
On 11 October 2011 21:40, Christian Grobmeier grobme...@gmail.com wrote:
On Tue, Oct 11, 2011 at 9:50 PM, sebb seb...@gmail.com wrote:
The new CSS changes the default setting for links, by removing
underlines unless the mouse hovers over the link.
However, this has broken all the internal name definitions.
These now look like links - they are blue, and get underlined when hovered
over.
See for example [1] where the table headings are blue (they should be black).
But just about every file also has similar headings that are now broken.
I've no idea whether it is possible for CSS to distinguish between a
href=#xxx and a name=xyz.
One way to fix this would be to change the site generation Anakia
stylesheet to use:
h3 id='incubator'
1. Incubation
/h3
rather than:
h3
a name=incubator1. Incubation/a
/h3
However, this will affect nearly every single html file, so before I
commit this change and flood the commits list with e-mails, is there a
CSS-expert who can confirm whether or not it's possible to change the
behaviour of a href without affecting a name ?
Is there any reason why we should not format:
h2 a {
text-decoration: none;
color: black;
}
Would need to be applied to h3 etc as well.
It would also hide links in headings (if there are any)
[I realise that the name attribute is deprecated, but the id attribute
behaves exactly the same.]
[1] http://incubator.apache.org/projects/index.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
Is there any reason why we should not format:
h2 a {
text-decoration: none;
color: black;
}
Would need to be applied to h3 etc as well.
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
It would also hide links in headings (if there are any)
Have not found a single one.
Besides, it would be really nasty to put links into headings imho
[I realise that the name attribute is deprecated, but the id attribute
behaves exactly the same.]
[1] http://incubator.apache.org/projects/index.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
On 11 October 2011 21:48, Christian Grobmeier grobme...@gmail.com wrote:
Is there any reason why we should not format:
h2 a {
text-decoration: none;
color: black;
}
Would need to be applied to h3 etc as well.
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
It would also hide links in headings (if there are any)
Have not found a single one.
Besides, it would be really nasty to put links into headings imho
It's not just ones in headings that are affected; any instance of a
name will be affected.
The ones I noticed were in headings, but there could now (or in the
future) be other instances that are not in headings.
We should use the fix suggested above in combination with the selector.
If the browser does not support the selector, at least headings will
still look OK.
I'm working on a JIRA to document this; I'll attach my site.vsl patch
in case we later have to (or want to) use ids in header tags instead.
[I realise that the name attribute is deprecated, but the id attribute
behaves exactly the same.]
[1] http://incubator.apache.org/projects/index.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: New bootstrap CSS messes up display of all internal name definitions
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
It would also hide links in headings (if there are any)
Have not found a single one.
Besides, it would be really nasty to put links into headings imho
It's not just ones in headings that are affected; any instance of a
name will be affected.
The ones I noticed were in headings, but there could now (or in the
future) be other instances that are not in headings.
well, I *hope* this will not be the case. Otherwise there will be
exceptions on the page which finally leads into chaos.
We should use the fix suggested above in combination with the selector.
If the browser does not support the selector, at least headings will
still look OK.
+1
I'm working on a JIRA to document this; I'll attach my site.vsl patch
in case we later have to (or want to) use ids in header tags instead.
Sounds good
Cheers
[I realise that the name attribute is deprecated, but the id attribute
behaves exactly the same.]
[1] http://incubator.apache.org/projects/index.html
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
--
http://www.grobmeier.de
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Created] (INCUBATOR-117) Bootstrap CSS messes up display of a name internal link definitions
Bootstrap CSS messes up display of a name internal link definitions
-
Key: INCUBATOR-117
URL: https://issues.apache.org/jira/browse/INCUBATOR-117
Project: Incubator
Issue Type: Bug
Components: site
Environment:
http://mail-archives.apache.org/mod_mbox/incubator-general/201110.mbox/%3CCAOGo0VbK1Cdqd=bx-cs1rdxxxj6andzalrlu7zwx1e6zbpg...@mail.gmail.com%3E
Reporter: Sebb
Attachments: INCUBATOR-117.patch
[This is to document the fix applied, and a further possible solution]
The new Bootstrap CSS changes the default setting for links, by removing
underlines unless the mouse hovers over the link.
However, this has broken all the internal name definitions. These now look like
links - they are blue, and get underlined when hovered over.
One possible solution to this (thanks Francis!) is to use a Selector, i.e.
a[href] to limit the underline changes.
However this may not be supported by all browsers.
Another is to use
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
This would affect real links in headers, but Incubator does not use them.
It would also be possible to change the Anakia stylesheet to use
h3 id='incubator'1. Incubation/h3
rather than:
h3a name=incubator1. Incubation/a/h3
This is arguably how the links should have been generated originally.
However this would generate a lot of changes.
Also, it would not stop problems with a name tags appearing in the XML source.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
[jira] [Updated] (INCUBATOR-117) Bootstrap CSS messes up display of a name internal link definitions
[
https://issues.apache.org/jira/browse/INCUBATOR-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated INCUBATOR-117:
---
Attachment: INCUBATOR-117.patch
Patch for site.vsl
Bootstrap CSS messes up display of a name internal link definitions
-
Key: INCUBATOR-117
URL: https://issues.apache.org/jira/browse/INCUBATOR-117
Project: Incubator
Issue Type: Bug
Components: site
Environment:
http://mail-archives.apache.org/mod_mbox/incubator-general/201110.mbox/%3CCAOGo0VbK1Cdqd=bx-cs1rdxxxj6andzalrlu7zwx1e6zbpg...@mail.gmail.com%3E
Reporter: Sebb
Attachments: INCUBATOR-117.patch
[This is to document the fix applied, and a further possible solution]
The new Bootstrap CSS changes the default setting for links, by removing
underlines unless the mouse hovers over the link.
However, this has broken all the internal name definitions. These now look
like links - they are blue, and get underlined when hovered over.
One possible solution to this (thanks Francis!) is to use a Selector, i.e.
a[href] to limit the underline changes.
However this may not be supported by all browsers.
Another is to use
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
This would affect real links in headers, but Incubator does not use them.
It would also be possible to change the Anakia stylesheet to use
h3 id='incubator'1. Incubation/h3
rather than:
h3a name=incubator1. Incubation/a/h3
This is arguably how the links should have been generated originally.
However this would generate a lot of changes.
Also, it would not stop problems with a name tags appearing in the XML
source.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Apache Callback for incubation
Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread of web development binding them all. In terms of contribution, excluding Nitobi Software employees, the Callback project has 70 contributors. In terms of user adoption, precise
Re: New bootstrap CSS messes up display of all internal name definitions
On 11 October 2011 22:03, Christian Grobmeier grobme...@gmail.com wrote:
h2 a, h3 a, h4 a, h5 a {
text-decoration: none;
color: black;
}
It would also hide links in headings (if there are any)
Have not found a single one.
Besides, it would be really nasty to put links into headings imho
It's not just ones in headings that are affected; any instance of a
name will be affected.
The ones I noticed were in headings, but there could now (or in the
future) be other instances that are not in headings.
well, I *hope* this will not be the case. Otherwise there will be
exceptions on the page which finally leads into chaos.
Not sure I follow.
What exceptions?
a name=xyz used to be the standard way to create anchors in HTML
files, so why should that cause an exception?
We should use the fix suggested above in combination with the selector.
If the browser does not support the selector, at least headings will
still look OK.
+1
I'm working on a JIRA to document this; I'll attach my site.vsl patch
in case we later have to (or want to) use ids in header tags instead.
Sounds good
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 (non-binding) On Oct 11, 2011 11:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread
Re: New bootstrap CSS messes up display of all internal name definitions
The ones I noticed were in headings, but there could now (or in the future) be other instances that are not in headings. well, I *hope* this will not be the case. Otherwise there will be exceptions on the page which finally leads into chaos. Not sure I follow. No worries, my comment was not so important What exceptions? a name=xyz used to be the standard way to create anchors in HTML files, so why should that cause an exception? I meant, we use tocs which lead to h2 anchors only. If somebody would start to make anchors without putting it into a heading, that would be an exception to what we have now. If it is only one, ok, but if there are many... We should use the fix suggested above in combination with the selector. If the browser does not support the selector, at least headings will still look OK. +1 I'm working on a JIRA to document this; I'll attach my site.vsl patch in case we later have to (or want to) use ids in header tags instead. Sounds good - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 Sent from my iPhone On Oct 11, 2011, at 5:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in
Re: [VOTE] Accept Apache Callback for incubation
+1 (binding) Thanks Jukka! On Tue, Oct 11, 2011 at 11:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software
[jira] [Created] (INCUBATOR-118) Are the altrmi files still needed? If so, should they be moved elsewhere?
Are the altrmi files still needed? If so, should they be moved elsewhere? - Key: INCUBATOR-118 URL: https://issues.apache.org/jira/browse/INCUBATOR-118 Project: Incubator Issue Type: Bug Components: site Reporter: Sebb There is a large directory tree in the Incubator-public SVN containing the site for the podling AltRMI which is no longer with the ASF. See http://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/projects/altrmi and http://incubator.apache.org/projects/altrmi/ Seems to me the only AltRMI file we should keep is the podling status, i.e. http://incubator.apache.org/projects/altrmi.html However, if the files are still to be kept, do they really belong on the Incubator public website? Would it not be more appropriate to store them elsewhere and make them read-only? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 On Tue, Oct 11, 2011 at 2:15 PM, Christian Grobmeier grobme...@gmail.com wrote: +1 (binding) Thanks Jukka! On Tue, Oct 11, 2011 at 11:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast,
[VOTE] [RESULT] Release deltacloud 0.4.1 rc1
The vote resulted in 6 +1, no 0's or -1's; three +1 votes were cast by mentors (Carl Trieloff, Jim Jagielski, and Davanum Srinivas) With that, the release of Deltacloud 0.4.1 RC1 is approved and I'll move the artifacts to the proper place to make them the GA. David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[ANNOUNCE] Apache Deltacloud 0.4.1 (incubating)
I am pleased to announce the availability of Apache Deltacloud 0.4.1. Apache Deltacloud is a RESTful cloud abstraction API. The release consists both of the API server and a Ruby client. The release can be found at http://www.apache.org/dist/incubator/deltacloud/0.4.1/ Gems and RPM's for Fedora will become available shortly. Many thanks to all those who contributed patches, reported bugs, and asked for features. It's great to see that the list of committers and patch contributors is steadily increasing. Overview of the changes for this release: * change how dependencies are managed: canonical deps are now in the gemspecs Server: * clarify how user_data injection should work; make sure all drivers accept base64 encoded data and make the decoded version available to instance * fix URL generation so that server works when run behind a reverse proxy * init script: honor defaults from sysconfig file * init script: fix 'status', properly background deltacloudd * deltacloudd: support verbose option * Drivers: + Condor - use UUIDTools instead of UUID to simplify deps + Google - new driver for Google storage API + RHEV-M - treat status as case-insensitive - inject data through a virtual floppy rather than modifying the instance storage directly + vSphere - report minimum of max memory across all hosts in a data center, so that instances can be placed on any host - user_data is placed in file 'deltacloud-user-data.txt' Client: * fix parsing of enums in HWP properties * fix handling of float value for number of vCPU in HWP David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 (not binding) On Tue, Oct 11, 2011 at 11:09 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common
Re: [VOTE] Accept Apache Callback for incubation
+1 Sent from my mobile device, so please excuse typos and brevity. Maurizio Cucchiara
Re: [VOTE] Accept Apache Callback for incubation
+1 On 10/11/2011 11:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread of web development binding them all. In terms of contribution, excluding Nitobi Software employees, the Callback project has
Re: [VOTE] Accept Apache Callback for incubation
On Tue, Oct 11, 2011 at 2:09 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... +1 (binding) -- Gianugo Rabellino - gianugo at rabellino dot it Blog: http://boldlyopen.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 On Oct 11, 2011 5:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread of web
Re: Clutch blue-green background colour obscures entries
sebb wrote: Clutch uses a blue-green background colour for satisfactory entries. However, many entries include clickable blue links which are not very distinct from the background. I suggest changing the background to light green (#90EE90) which works much better for me. See the sample lines for Ace and Airavata at http://people.apache.org/~sebb/clutch.html#clutch OK to change that? This colour scheme was carefully chosen to assist with colour-blindness. I have been meaning to find the old discussion and development here about that, and add to Clutch notes. It used to have decent contrast for the links. Now the new bootsrap CSS has changed link colour to be a lighter blue. It has also changed the visited link colour to be the same (which is poor design). I started yesterday to develop some CSS to fix that for this table, but really it is an overall site issue. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clutch blue-green background colour obscures entries
On 12 October 2011 03:14, David Crossley cross...@apache.org wrote: sebb wrote: Clutch uses a blue-green background colour for satisfactory entries. However, many entries include clickable blue links which are not very distinct from the background. I suggest changing the background to light green (#90EE90) which works much better for me. See the sample lines for Ace and Airavata at http://people.apache.org/~sebb/clutch.html#clutch OK to change that? This colour scheme was carefully chosen to assist with colour-blindness. I have been meaning to find the old discussion and development here about that, and add to Clutch notes. +1 It used to have decent contrast for the links. Sorry, should have checked that out. I've already rebuilt the original site to check the strange header behaviour, and indeed the table used to display very well. Now the new bootsrap CSS has changed link colour to be a lighter blue. It has also changed the visited link colour to be the same (which is poor design). I started yesterday to develop some CSS to fix that for this table, but really it is an overall site issue. Indeed. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1, binding, awesome guys, good luck! Cheers, Chris On Oct 11, 2011, at 2:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency
Re: [VOTE] Accept Apache Callback for incubation
+1 (binding) Looks great D. On Wed, Oct 12, 2011 at 4:55 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: +1, binding, awesome guys, good luck! Cheers, Chris On Oct 11, 2011, at 2:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The
Re: [VOTE] Accept Apache Callback for incubation
+1 On Wednesday, October 12, 2011, Ate Douma a...@douma.nu wrote: +1 On 10/11/2011 11:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to m -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Accept Apache Callback for incubation
+1 Regards, Alan On Oct 11, 2011, at 2:09 PM, Jukka Zitting wrote: As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding.
Re: [VOTE] Accept Apache Callback for incubation
+1 (binding) Regards JB On 10/11/2011 11:09 PM, Jukka Zitting wrote: Hi, As discussed, the PhoneGap project would like to enter the Incubator under the Apache Callback name (potential alternative names to be discussed during incubation). The initial proposal has been well received and there are no major open issues, so it's time to vote! Thus I'm now calling a formal VOTE on the Apache Callback proposal as included below. The proposal is also available at http://wiki.phonegap.com/w/page/46311152/apache-callback-proposal on the PhoneGap wiki, and I'll place a copy for our archives on the Incubator wiki as soon as it stops giving me internal server errors. Please VOTE: [ ] +1 Accept Apache Callback for incubation [ ] -1 Don't accept Apache Callback for incubation because... This vote is open for the next 72 hours. Everyone is welcome to participate, but only votes from the Incubator PMC members are binding. Thanks! My vote is +1. Best regards, Jukka Zitting Apache Callback Proposal Abstract Apache Callback is a platform for building native mobile applications using HTML, CSS and JavaScript. Proposal Apache Callback allows web developers to natively target Apple iOS, Google Android, RIM BlackBerry, Microsoft Windows Phone 7, HP webOS, Nokia Symbian and Samsung Bada with a single codebase. The Callback APIs are based on open web standards. The Callback bridge technology enables access to native device capabilities. Utilizing the Callback bridge native plugins allow for any type of native access from the embedded webview. Background -- Apache Callback is the free software evolution of the popular PhoneGap project. PhoneGap evolved from a hack that enabled a FFI (Foreign Function Interface) to an embedded WebView on iOS to a complete suite of tools for tackling parity across many mobile device and desktop platforms. PhoneGap has always focused on two complementary goals. Our first goal, is to see the web as a first class development platform. Not a sandbox without a filesystem but a real first class platform that includes access to the local system apis, sensors and data, in addition to first class tooling such as system debuggers. The second goal of PhoneGap is for the project to cease to exist. This is not a nihilistic sentiment, rather we at the PhoneGap project are providing a reference implementation for web browsers to assist and guide the standardization process of browser APIs. The name and trademark of PhoneGap will become the commercial entity for the project. The source, code, documentation and related assets will all be contributed to the Apache Foundation as Callback. The Callback name comes from the event of the same name that is fired when the FFI bridge is established. Rationale - The dominate window to the web is quickly becoming devices, mostly phones. The manufacturers of devices, creators of mobile operating systems, and authors of web browsers are consolidating. (In many cases these are all already the same company.) Those stakeholders may see a future for the web but their bottom line is not necessarily motivated to participate in an open web. It is especially clear that while many of these platforms have been seeing some level of strategic neglect in favor of enhanced experiences at the price locking developers into their respective platforms. The Callback project exists to bring the focus back to an open and accessible web. Initial Goals - * License all PhoneGap source code and documentation to the Apache Software Foundation. (We already name the Apache license in our CLA.) * Setup and standardize the open governance of the Callback project. * Rename all assets from PhoneGap to Callback in project src, docs, tests and related infrastructure. Current Status -- Callback is a mature software project recently shipping 1.0 on July 29, 2011. Meritocracy --- Callback has always been a project driven by merit and, in a sense, our solution is brute force requiring many collaborating developers to solve our goals. It would be far easier, and perhaps more correct, for the Callback project to port a single web browser codebase, and API bindings, across platforms but our executable size would be appreciably larger, unacceptably so for mobile, and our target abstraction would be only tertiary to maintaining a codebase of that size. By relying on the platform browser, exposed by the platform SDK, we get a quick win to the browser and only have to focus on our bridge. This means the project requires developers with proficiency on each platform: collaboration is a natural side effect. Community - The community surrounding Callback is vast, diverse, distributed globally, and with all levels of proficiency in software development---the common thread of web development binding them all. In terms of contribution, excluding Nitobi Software employees, the
