incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yuri Z <vega...@gmail.com>
Subject Re: Discuss: Release (was: Fwd: Re: Actions Items (was: Roadmap))
Date Tue, 31 Mar 2015 20:00:51 GMT
Ok, I ll start working on a fresh RC.

On Tue, Mar 31, 2015 at 11:00 PM Yuri Z <vega113@gmail.com> wrote:

> Currently we work directly on master. For release we create an RC branch
> that is merged back to master.
> The release docs are here:
> https://cwiki.apache.org/confluence/display/WAVE/Release+Procedure
> The release procedure is under Home -> Contributing -> Release Procedure.
>
> On Tue, Mar 31, 2015 at 10:03 PM Christian Grobmeier <grobmeier@apache.org>
> wrote:
>
>> Yes, I think we should do that RC now.
>>
>> It's a positive signal in many directions, even when we label that
>> alpha.
>>
>> I have no idea how Wave currently manages it's branches. personally I
>> work on /develop.
>> When 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 <vega113@gmail.com>
>> To: wave-dev@incubator.apache.org
>> Subject: Re: Actions Items (was: Roadmap)
>> Date: Tue, 31 Mar 2015 17:45:29 +0000
>>
>> So, should I prepare a new RC from the master branch?
>>
>> On Tue, Mar 31, 2015 at 6:05 PM Christian Grobmeier
>> <grobmeier@apache.org>
>> wrote:
>>
>> > OK, understood.
>> >
>> > I think it's a psychological important step to release the code, even
>> > when its half-baked and early. If necessary, give it an alpha label.
>> > This is enough warning for most devs.
>> >
>> > I don't understand too much on the current codebase, so I can't judge
>> > what is the best first step. Separating between Commons/Client sounds
>> > horrible awful task. Can you give an overview of what would be the
>> > actual steps here? I imagine it's critical, but is it possible to have
>> > multiple hands working on it?
>> >
>> > Thanks!
>> >
>> >
>> > On Tue, Mar 31, 2015, at 11:55, Yuri Z wrote:
>> > > Build system - Actually things like GWT compilation and protobuff
>> > > generation make it harder to move to another build system. Also,
>> > > restructuring wave project into more standard form that maven likes to
>> > > work
>> > > with is imho hard. I think first we should just split Wiab into
>> separated
>> > > projects - Client/Common/Server or Client/ Common + Server and
>> preferably
>> > > with more elastic build system than maven -than can be more easily
>> made
>> > > to
>> > > work with current folder structure.
>> > > Release - imho what stops us is just 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
>> > > <grobmeier@apache.org>
>> > > wrote:
>> > >
>> > > > 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 something more
>> > conveniant
>> > > >  - Rewrite of the concurrency handling.
>> > > >  - Make Wave work with modern browsers
>> > > >  - Shortcuts are broken
>> > > >  - Inbox search is needs improvments
>> > > >  - GWT superdev mode is broken
>> > > >  - Upgrade to GWT
>> > > >  - GWT-tests broken
>> > > >  - Gadgets broken
>> > > >  - Bonus: understand the changes from wiab.pro and discuss if they
>> > > >  should be upstreamed
>> > > >
>> > > > It seems we have some infra, some architectural and some frontend
>> > > > issues.
>> > > > From the Frontend it seems we have no conclusion if GWT is the right
>> > > > track or not.
>> > > >
>> > > > What I understood is that most people agree that we need to have
>> some
>> > > > kind of Client/Server/Common split.
>> > > >
>> > > > We have some issues in the backlog also, which makes refactoring
>> hard
>> > > > like build system, broken tests or CI not being setup.
>> > > >
>> > > > This is quite a bunch of work.
>> > > >
>> > > > I have two questions:
>> > > >
>> > > >  1. why did we went stuck with the first release? Sorry Ali to ask
>> > > >  again, I forgot and couldn't find it in my mails quickly. Could we
>> > > >  solve this right now and get it done?
>> > > >
>> > > >  2. What would be the next, small step? In my opinion it actually
>> > should
>> > > >  be the build system. Once this is done, it can be explained how
>> "easy"
>> > > >  it is to setup Wave, which might help to attract approaching devs.
>> > > >
>> > > > Both items are small enough to be resolved with in April. Volunteers
>> > > > should learn how to make releases at Apache, also learn and improve
>> the
>> > > > build process. I think this is a great step for new volunteers.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > Christian
>> > > >
>> > > >
>> > > >
>> > > > ----- Original message -----
>> > > > From: Christian Grobmeier <grobmeier@apache.org>
>> > > > To: "wave-dev" <wave-dev@incubator.apache.org>
>> > > > Subject: Roadmap
>> > > > Date: Tue, 24 Mar 2015 12:12:32 +0100
>> > > >
>> > > > 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 was the RM for the last try.
>> > > >
>> > > > The next thing would maybe be more technical. Can you throw in some
>> > > > concrete ideas what could be achieved in small steps?
>> > > > I guess "refactoring everything" is not a good start :)
>> > > >
>> > > > Regards,
>> > > >
>> > > > Christian
>> > > >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message