bad feeling about releasing half
> > > baked
> > > project, technically we can create new RC candidate today and vote. From
> > > what I know all legal issues are already solved.
> > >
> > > On Tue, Mar 31, 2015 at 12:43 PM Christian Grobmeier
> > >
>> Didn't Ali create release docs? Can't find them on the Wave-wiki, not
>> sure if they actually exist
>>
>>
>> - Original message -
>> From: Yuri Z
>> To: wave-dev@incubator.apache.org
>> Subject: Re: Actions Items (was: Roadmap)
>> D
doing a release, I create a tag, get the release from that tag, and
> finally merge that into /master.
>
> Didn't Ali create release docs? Can't find them on the Wave-wiki, not
> sure if they actually exist
>
>
> - Original message -
> From: Yuri Z
>
merge that into /master.
Didn't Ali create release docs? Can't find them on the Wave-wiki, not
sure if they actually exist
- Original message -
From: Yuri Z
To: wave-dev@incubator.apache.org
Subject: Re: Actions Items (was: Roadmap)
Date: Tue, 31 Mar 2015 17:45:29 +
So, shoul
vote. From
> > what I know all legal issues are already solved.
> >
> > On Tue, Mar 31, 2015 at 12:43 PM Christian Grobmeier
> >
> > wrote:
> >
> > > Hi,
> > >
> > > from the huge thread "Roadmap" I took a way the following po
ally we can create new RC candidate today and vote. From
> what I know all legal issues are already solved.
>
> On Tue, Mar 31, 2015 at 12:43 PM Christian Grobmeier
>
> wrote:
>
> > Hi,
> >
> > from the huge thread "Roadmap" I took a way the f
ould like to have your company named on the webpages, I suggest
> > you open up a new mailing thread with this topic as it might not be seen
> > here.
> >
> > Please let me know if any more questions.
> >
> > Thanks!
> >
> > Christian
> >
> >
> &
new mailing thread with this topic as it might not be seen
> here.
>
> Please let me know if any more questions.
>
> Thanks!
>
> Christian
>
>
> >
> > On Tue, Mar 24, 2015 at 7:49 PM, Yuri Z wrote:
> >
> > > I can share my own roadmap - or things
today and vote. From
what I know all legal issues are already solved.
On Tue, Mar 31, 2015 at 12:43 PM Christian Grobmeier
wrote:
> Hi,
>
> from the huge thread "Roadmap" I took a way the following potential
> action items:
>
> - Client/Server split, maybe common
>
Hi,
from the huge thread "Roadmap" I took a way the following potential
action items:
- Client/Server split, maybe common
- Setup testing
- Setup CI
- Replace GXP templating system
- Improve buildsystem with using Maven, Gradle or SBT
- Replace custom configuration framework with
p a new mailing thread with this topic as it might not be seen
here.
Please let me know if any more questions.
Thanks!
Christian
>
> On Tue, Mar 24, 2015 at 7:49 PM, Yuri Z wrote:
>
> > I can share my own roadmap - or things I would do.
> >
> > 1. Modernization
Pablo , I might be interested in using your project as it gells with my own
project (arwave.org - we want to establish a system for selectively shared
geolocated content. Think collaboratively constructed and shared virtual
worlds, not tied
to any one company's server or even client).
Is your proje
I fully agree with Thomas,
You can split the client and sever without switching languages.
> This is common in GWT projects.
> You just have
> - client (gwt java)
> - sever (java)
> - common (gwt-subset of java, but not using any gwt specific things)
>
> Common can then be imported by any non-gwt
You can split the client and sever without switching languages.
This is common in GWT projects.
You just have
- client (gwt java)
- sever (java)
- common (gwt-subset of java, but not using any gwt specific things)
Common can then be imported by any non-gwt (but still Java) clients, such
as Android
Is there an implementable design anywhere for how a client/server split
would work?
It continually comes up as a blocking point preventing people from working
on Wave, though I'm not familiar with plans for fixing it that maintain all
required constraints.
e.g. sharing business logic between clien
El 25/03/15 a las 21:03, Andrew Kaplanov escribió:
>> I patched this review before
> I don't see your comments in the https://reviews.apache.org/r/22776/.
The review was closed. I patched here:
https://reviews.apache.org/r/28724/
> Could you create Jira issue about the problem with shortcuts?
Do
> I patched this review before
I don't see your comments in the https://reviews.apache.org/r/22776/.
Could you create Jira issue about the problem with shortcuts?
2015-03-26 0:45 GMT+05:00 Vicente J. Ruiz Jurado :
> El 25/03/15 a las 19:00, Andrew Kaplanov escribió:
> > - It seems that some edit
El 25/03/15 a las 19:00, Andrew Kaplanov escribió:
> - It seems that some edition shortcuts are broken since the akaplanov
>> Profiling functionality:
>> https://reviews.apache.org/r/22776/
>> (as a workaround I reverted FocusManager.java in my branch).
>
> Instead of having write this here you co
- It seems that some edition shortcuts are broken since the akaplanov
>Profiling functionality:
>https://reviews.apache.org/r/22776/
>(as a workaround I reverted FocusManager.java in my branch).
Instead of having write this here you could write your patch.
Or create Jira request.
In any case, the
impression from the other conversations in this
list over the years. Maybe my perception is skewed due to my own opinions.
I do think any roadmap should try to put forward the things that will get
more people involved as a priority.
Maybe to do that we need a more definitive measure of why people arnt
j
El 24/03/15 a las 12:12, Christian Grobmeier escribió:
> we have volunteers for the next months. Why not discussing what we
> should do?
>
> My first preference would be: craft a release.
> I forgot what was missing back then, but it would be great to find out
> from the mail archives and create j
I mainly agree with Yuri. I personally believe that the first steps should be
addressing the part that make I hard for new developers to come in and help.
Build System… replacing obscure technologies… developer docs. Separation of UI
from server… etc.
On 3/25/15, 3:08 AM, "Dave Ball" wrote
It might be a little out of date, but:
https://cwiki.apache.org/confluence/display/WAVE/Source+Code+Organization
might be a good start for anyone wanting to work on the client / server
/ common split. Anything with an x in both client and server columns
would obviously be common! ;-)
[Pablo: I
Liking what I am hearing.
My ten cents:
client/server/common model is good for libraries, yes, but need
well-defined client APIs to allow multiple apps to access common data
stores. Otherwise you get more balkanisation and the data model never takes
off.
federation required, preferably in a way
On 24 March 2015 at 16:32, Dave Ball wrote:
>
>> Might it be better to have three "parts"?
> - common
> - server
> - client
>
> Common would contain the document and concurrency model etc. Client and
> Server would both depend on Common. Common would compile to JS for the
> Client, but Server
development and we would commit
> more into the official repository.
>
> Does anybody have some plans? It would be nice to avoid duplicating our
> implementation efforts.
>
> On Tue, Mar 24, 2015 at 7:49 PM, Yuri Z wrote:
>
> > I can share my own roadmap - or things I wou
> For example, personally I am interested on building new collaborative apps
> with Wave's technology. But I don't need the conversation model and the
> current GWT client app. So I am building my own API on top of Wave.
I could have worked with the conversation model (though basically
wouldn't ha
Today we are trying to do Wave faster. This problem was trying to decide
Google, but did not. I believe that we can do it.
2015-03-24 22:14 GMT+05:00 Pablo Ojanguren :
> From a technical perspective I mostly agree with Yuri's roadmap, priorities
> apart and wiab.pro improvements
>From a technical perspective I mostly agree with Yuri's roadmap, priorities
apart and wiab.pro improvements are awesome.
But I think the big question is what can we do first to get new
contributors and foster the community? Do we know what developers want from
Wave?
For example, persona
On 24/03/15 13:49, Yuri Z wrote:
3. Re-think how we should solve the tight coupling/great complexity of
client-server protocol. Maybe we should split the Wiab project into two
parts server and client - where server will depend on compiled javascript
client.
Might it be better to have three "part
ld be nice to avoid duplicating our
implementation efforts.
On Tue, Mar 24, 2015 at 7:49 PM, Yuri Z wrote:
> I can share my own roadmap - or things I would do.
>
> 1. Modernization
> 1.1 Replace GXP templating system that is used to generate few front end
> HTMLs with some
I can share my own roadmap - or things I would do.
1. Modernization
1.1 Replace GXP templating system that is used to generate few front end
HTMLs with something that is main stream and well documented.
1.2 Replace ant scripts that are used to build the project/manage
dependencies with something
On 24/03/15 13:30, Thomas Wrobel wrote:
> On 24 March 2015 at 13:56, Francesco Rossi wrote:
>
>> Client - server split as much as possible :)
>>
>> +1
> I think the question is if that task can be subdivided into smaller steps?
>
I presume there's a proper test suite? And continuous integration
On 24 March 2015 at 13:56, Francesco Rossi wrote:
> Client - server split as much as possible :)
>
> +1
I think the question is if that task can be subdivided into smaller steps?
>
> On 3/24/2015 4:12 AM, Christian Grobmeier wrote:
>
>> we have volunteers for the next months. Why not discussing
Client - server split as much as possible :)
On 3/24/2015 4:12 AM, Christian Grobmeier wrote:
we have volunteers for the next months. Why not discussing what we
should do?
My first preference would be: craft a release.
I forgot what was missing back then, but it would be great to find out
from
we have volunteers for the next months. Why not discussing what we
should do?
My first preference would be: craft a release.
I forgot what was missing back then, but it would be great to find out
from the mail archives and create jira issues for the open things. Maybe
Ali could help here, as he wa
our developer wiki up and running first. Was
> there any specific questions you had regarding the road map?
>
> I'm interested in Wave (I've been following this list for a while),
> but since I don't know Java, I could help started with the
> documentation/roadmap. Is there anything I can get started on?
loper wiki up and running first. Was
there any specific questions you had regarding the road map?
I'm interested in Wave (I've been following this list for a while),
but since I don't know Java, I could help started with the
documentation/roadmap. Is there anything I can get started on?
7;s ok.
> I do not have any specific question, only curiosity. Also I just published a
> small article in my personal blog (see sig), and thought that any reader
> arriving at the website could end up at the roadmap and get a wrong idea
> about the real status of the project.
>
I understand. I suppose there's more pressing issues than that, so it's ok.
I do not have any specific question, only curiosity. Also I just published a
small article in my personal blog (see sig), and thought that any reader
arriving at the website could end up at the roadmap and get a
e any specific questions you had
regarding the road map?
~Michael
On Apr 28, 2011, at 3:03 AM, STenyaK wrote:
> The waveprotocol websitehas this roadmap [1], but it is outdated. Are there
> plans to update it, or has it moved somewhere else?
>
> [1] http://www.waveprotocol.org/w
The waveprotocol websitehas this roadmap [1], but it is outdated. Are there
plans to update it, or has it moved somewhere else?
[1] http://www.waveprotocol.org/wave-in-a-box/wiab-roadmap
--
Saludos,
Bruno González
___
Jabber: stenyak AT
42 matches
Mail list logo
