Gerrit 2.9 plans
777 views
Skip to first unread message
Shawn Pearce
Dec 6, 2013, 12:23:47 PM12/6/13
to repo-discuss
Now that 2.8 has been released, here is my plan for 2.9:
- Finish forklifting the old change screen onto the new REST API.
This is a hack. A quick and dirty hack to let me delete the old
service handlers. It will be slower, as the old UI has to gather a lot
of data from several different REST APIs before it can display.
- Build an "intro to new change screen" somehow into the UI.
The first few times a user opens the new change screen, I want to show
something in the top menu area to welcome them to the new UI and link
to the new change screen documentation, and a link to settings where
they can set the preference. They can dismiss this by setting the user
preference to either old or new change screen.
- 2.9-rc0
The 2.9 series will have the site level and user level preference for
old change screen vs. new change screen. The default is the new change
screen.
I want to hit 2.9-rc0 just before Christmas.
I think this means 2.9 final around Feb 1st.
- master will delete old change screen code.
- master will delete the new "enable new features" variable I hacked
in last night.
- 2.10 will ship after 2.9, obviously, with only the new change screen.
- Finish forklifting the old change screen onto the new REST API.
This is a hack. A quick and dirty hack to let me delete the old
service handlers. It will be slower, as the old UI has to gather a lot
of data from several different REST APIs before it can display.
- Build an "intro to new change screen" somehow into the UI.
The first few times a user opens the new change screen, I want to show
something in the top menu area to welcome them to the new UI and link
to the new change screen documentation, and a link to settings where
they can set the preference. They can dismiss this by setting the user
preference to either old or new change screen.
- 2.9-rc0
The 2.9 series will have the site level and user level preference for
old change screen vs. new change screen. The default is the new change
screen.
I want to hit 2.9-rc0 just before Christmas.
I think this means 2.9 final around Feb 1st.
- master will delete old change screen code.
- master will delete the new "enable new features" variable I hacked
in last night.
- 2.10 will ship after 2.9, obviously, with only the new change screen.
Remy Bohmer
Dec 6, 2013, 1:04:56 PM12/6/13
to Shawn Pearce, repo-discuss
Hi,
This looks very interesting. The new UI looks way better than the old UI.
We noticed however that the new UI runs really bad on Internet Explorer browsers 9 and 10. (not to speak about IE8). It is unusable there...
This prevented us from setting it as default view in 2.8
Is that something you know that is being worked at already? Or that we can fix otherwise?
Kind regards,
Remy
Op 6 dec. 2013 18:24 schreef "Shawn Pearce" <s...@google.com>:
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Shawn Pearce
Dec 6, 2013, 1:14:05 PM12/6/13
to Remy Bohmer, repo-discuss
On Fri, Dec 6, 2013 at 10:04 AM, Remy Bohmer <li...@bohmer.net> wrote:
> This looks very interesting. The new UI looks way better than the old UI.
>
> We noticed however that the new UI runs really bad on Internet Explorer
> browsers 9 and 10. (not to speak about IE8). It is unusable there...
> This prevented us from setting it as default view in 2.8
:-(
> This looks very interesting. The new UI looks way better than the old UI.
>
> We noticed however that the new UI runs really bad on Internet Explorer
> browsers 9 and 10. (not to speak about IE8). It is unusable there...
> This prevented us from setting it as default view in 2.8
> Is that something you know that is being worked at already? Or that we can
> fix otherwise?
Unfortunately I just don't use IE at Google. Chrome/Firefox/Safari are
much more prevalent for our users, so this is where the bulk of our
development and testing winds up going.
Unfortunately this also seems to be true across most of the Gerrit
contributors. Few (if any) use IE, or support teams that use IE with
Gerrit, so its incredibly hard for us to get adequate testing and bug
fixing around that browser.
David Ostrovsky
Dec 6, 2013, 1:16:28 PM12/6/13
to repo-d...@googlegroups.com, repo-discuss
Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
Now that 2.8 has been released, here is my plan for 2.9:
- Finish forklifting the old change screen onto the new REST API.
Why? Since we are going to delete the old change screen with old style RPC
anyway, why to touch it at all?
[...]
- 2.10 will ship after 2.9, obviously, with only the new change screen.
name it 3.0?
Shawn Pearce
Dec 6, 2013, 1:31:15 PM12/6/13
to David Ostrovsky, repo-discuss
On Fri, Dec 6, 2013 at 10:16 AM, David Ostrovsky
<david.o...@gmail.com> wrote:
>
> Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
>>
>> Now that 2.8 has been released, here is my plan for 2.9:
>>
>> - Finish forklifting the old change screen onto the new REST API.
>>
>
> Why? Since we are going to delete the old change screen with old style RPC
> anyway, why to touch it at all?
I need to continue to run the old UI on top of modern servers. So I am
<david.o...@gmail.com> wrote:
>
> Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
>>
>> Now that 2.8 has been released, here is my plan for 2.9:
>>
>> - Finish forklifting the old change screen onto the new REST API.
>>
>
> Why? Since we are going to delete the old change screen with old style RPC
> anyway, why to touch it at all?
trying to create a frozen version that is capable of doing that. Might
as well call that 2.9 since 2.9's plan was always to offer both
screens, with the new one as the default.
>> - 2.10 will ship after 2.9, obviously, with only the new change screen.
>
>
> name it 3.0?
3.0 will probably be used when the change is completely in Git and we
no longer have a change database. I expect us to get there in late
2014. 2.10 will almost certainly happen before.
Patrick Renaud
Dec 6, 2013, 2:11:51 PM12/6/13
to Shawn Pearce, David Ostrovsky, repo-discuss
Makes sense calling it 3.0 when the DB has been evacuated out.
/Patrick
Dave Borowitz
Dec 6, 2013, 3:32:39 PM12/6/13
to Shawn Pearce, David Ostrovsky, repo-discuss
On Fri, Dec 6, 2013 at 10:31 AM, Shawn Pearce <s...@google.com> wrote:
On Fri, Dec 6, 2013 at 10:16 AM, David OstrovskyI need to continue to run the old UI on top of modern servers. So I am
<david.o...@gmail.com> wrote:
>
> Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
>>
>> Now that 2.8 has been released, here is my plan for 2.9:
>>
>> - Finish forklifting the old change screen onto the new REST API.
>>
>
> Why? Since we are going to delete the old change screen with old style RPC
> anyway, why to touch it at all?
trying to create a frozen version that is capable of doing that. Might
as well call that 2.9 since 2.9's plan was always to offer both
screens, with the new one as the default.
Were you planning on also stripping out all the old RPC code (including the gwtjsonrpc dependency) for 2.9?
>> - 2.10 will ship after 2.9, obviously, with only the new change screen.Probably not? Depends?
>
>
> name it 3.0?
3.0 will probably be used when the change is completely in Git and we
no longer have a change database.
+1
2.9+ will be previews of what we will see in 3.0 and chunks of new functionality. We just can't get them all out the door at once. (And we're pretty good about backwards compatibility.)
I expect us to get there in late
2014. 2.10 will almost certainly happen before.
Shawn Pearce
Dec 6, 2013, 3:34:55 PM12/6/13
to Dave Borowitz, David Ostrovsky, repo-discuss
On Fri, Dec 6, 2013 at 12:32 PM, Dave Borowitz <dbor...@google.com> wrote:
> On Fri, Dec 6, 2013 at 10:31 AM, Shawn Pearce <s...@google.com> wrote:
>>
>> On Fri, Dec 6, 2013 at 10:16 AM, David Ostrovsky
>> <david.o...@gmail.com> wrote:
>> >
>> > Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
>> >>
>> >> Now that 2.8 has been released, here is my plan for 2.9:
>> >>
>> >> - Finish forklifting the old change screen onto the new REST API.
>> >>
>> >
>> > Why? Since we are going to delete the old change screen with old style
>> > RPC
>> > anyway, why to touch it at all?
>>
>> I need to continue to run the old UI on top of modern servers. So I am
>> trying to create a frozen version that is capable of doing that. Might
>> as well call that 2.9 since 2.9's plan was always to offer both
>> screens, with the new one as the default.
>
>
> Were you planning on also stripping out all the old RPC code (including the
> gwtjsonrpc dependency) for 2.9?
As much as possible. The project access editor might stick with the
> On Fri, Dec 6, 2013 at 10:31 AM, Shawn Pearce <s...@google.com> wrote:
>>
>> On Fri, Dec 6, 2013 at 10:16 AM, David Ostrovsky
>> <david.o...@gmail.com> wrote:
>> >
>> > Am Freitag, 6. Dezember 2013 18:23:47 UTC+1 schrieb Shawn Pearce:
>> >>
>> >> Now that 2.8 has been released, here is my plan for 2.9:
>> >>
>> >> - Finish forklifting the old change screen onto the new REST API.
>> >>
>> >
>> > Why? Since we are going to delete the old change screen with old style
>> > RPC
>> > anyway, why to touch it at all?
>>
>> I need to continue to run the old UI on top of modern servers. So I am
>> trying to create a frozen version that is capable of doing that. Might
>> as well call that 2.9 since 2.9's plan was always to offer both
>> screens, with the new one as the default.
>
>
> Were you planning on also stripping out all the old RPC code (including the
> gwtjsonrpc dependency) for 2.9?
old RPC code into 2.9, and maybe even 2.10. Its going to be some work
to replace it.
>> >> - 2.10 will ship after 2.9, obviously, with only the new change screen.
>> >
>> >
>> > name it 3.0?
>>
>> Probably not? Depends?
>>
>> 3.0 will probably be used when the change is completely in Git and we
>> no longer have a change database.
>
>
> +1
>
> 2.9+ will be previews of what we will see in 3.0 and chunks of new
> functionality. We just can't get them all out the door at once. (And we're
> pretty good about backwards compatibility.)
2.9 is a transition period between 2.8 and... whatever comes next.
Shawn Pearce
Dec 23, 2013, 10:42:41 PM12/23/13
to Sebastien Douche, repo-discuss
On Sun, Dec 22, 2013 at 8:17 PM, Sebastien Douche <sdo...@gmail.com> wrote:
> On Fri, Dec 6, 2013 at 6:23 PM, Shawn Pearce <s...@google.com> wrote:
> I have a request about the new change screen, sorry if it's not the
> good thread for that. A show-stopper to use Gerrit here is the lack of
> unified change of all commits on one screen and not commit by commit.
> Is it possible?
This is not supported in either the old UI or the new UI.
We have discussed it before on the mailing list. If you want to review
the squashed history, squash the commit before uploading it to Gerrit.
We show each commit individually to allow the reviewer to examine each
commit as it will show in the final project history. If the commits
aren't suitable to be reviewed individually, then they are not
suitable to remain in the long term project history, and should be
rewritten or squashed. If its suitable to stay in the long term
history, it should be reviewed individually.
> On Fri, Dec 6, 2013 at 6:23 PM, Shawn Pearce <s...@google.com> wrote:
> I have a request about the new change screen, sorry if it's not the
> good thread for that. A show-stopper to use Gerrit here is the lack of
> unified change of all commits on one screen and not commit by commit.
> Is it possible?
This is not supported in either the old UI or the new UI.
We have discussed it before on the mailing list. If you want to review
the squashed history, squash the commit before uploading it to Gerrit.
We show each commit individually to allow the reviewer to examine each
commit as it will show in the final project history. If the commits
aren't suitable to be reviewed individually, then they are not
suitable to remain in the long term project history, and should be
rewritten or squashed. If its suitable to stay in the long term
history, it should be reviewed individually.
Sebastien Douche
Dec 22, 2013, 11:17:50 PM12/22/13
to Shawn Pearce, repo-discuss
On Fri, Dec 6, 2013 at 6:23 PM, Shawn Pearce <s...@google.com> wrote:
> Now that 2.8 has been released, here is my plan for 2.9:
>
> - Finish forklifting the old change screen onto the new REST API.
>
> This is a hack. A quick and dirty hack to let me delete the old
> service handlers. It will be slower, as the old UI has to gather a lot
> of data from several different REST APIs before it can display.
>
> - Build an "intro to new change screen" somehow into the UI.
>
> The first few times a user opens the new change screen, I want to show
> something in the top menu area to welcome them to the new UI and link
> to the new change screen documentation, and a link to settings where
> they can set the preference. They can dismiss this by setting the user
> preference to either old or new change screen.
Hi Shawn,
>
> - Finish forklifting the old change screen onto the new REST API.
>
> This is a hack. A quick and dirty hack to let me delete the old
> service handlers. It will be slower, as the old UI has to gather a lot
> of data from several different REST APIs before it can display.
>
> - Build an "intro to new change screen" somehow into the UI.
>
> The first few times a user opens the new change screen, I want to show
> something in the top menu area to welcome them to the new UI and link
> to the new change screen documentation, and a link to settings where
> they can set the preference. They can dismiss this by setting the user
> preference to either old or new change screen.
I have a request about the new change screen, sorry if it's not the
good thread for that. A show-stopper to use Gerrit here is the lack of
unified change of all commits on one screen and not commit by commit.
Is it possible?
--
good thread for that. A show-stopper to use Gerrit here is the lack of
unified change of all commits on one screen and not commit by commit.
Is it possible?
Sebastien Douche <sdo...@gmail.com>
Twitter: @sdouche / G+: +sdouche
Martin Fick
Jan 10, 2014, 4:16:32 PM1/10/14
to repo-d...@googlegroups.com
I would like to release 2.9-rc0 early next week if that
seems fine. I am readying my new buck build skills (buck is
cool) and practicing the newer release procedures.
BTW, all the slow tests do not complete on my machine, do
the work for others? Some bomb out due to heap limits, is
there some jvm setting we should bump for these tests?
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
seems fine. I am readying my new buck build skills (buck is
cool) and practicing the newer release procedures.
BTW, all the slow tests do not complete on my machine, do
the work for others? Some bomb out due to heap limits, is
there some jvm setting we should bump for these tests?
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
Edwin Kempin
Jan 10, 2014, 5:03:29 PM1/10/14
to Martin Fick, Repo and Gerrit Discussion
I would like to release 2.9-rc0 early next week if that
seems fine. I am readying my new buck build skills (buck is
cool) and practicing the newer release procedures.
BTW, all the slow tests do not complete on my machine, do
the work for others? Some bomb out due to heap limits, is
there some jvm setting we should bump for these tests?
I'm currently seeing some OutOfMemoryErrors on my system for a new test which is introduced by [1].
David gave some good hints how to increase the heap. Unfortunately it didn't fix my problem yet, but
you may anyway want to check the discussion on [1].
For the existing tests I'm not seeing any OutOfMemoryErrors at the moment, but I have seen some
from time to time in the past.
you may anyway want to check the discussion on [1].
For the existing tests I'm not seeing any OutOfMemoryErrors at the moment, but I have seen some
from time to time in the past.
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
Edwin Kempin
Jan 10, 2014, 5:26:24 PM1/10/14
to Martin Fick, Repo and Gerrit Discussion
2014/1/10 Martin Fick <mf...@codeaurora.org>
I would like to release 2.9-rc0 early next week if that
seems fine. I am readying my new buck build skills (buck is
cool) and practicing the newer release procedures.
BTW, all the slow tests do not complete on my machine, do
the work for others? Some bomb out due to heap limits, is
there some jvm setting we should bump for these tests?I'm currently seeing some OutOfMemoryErrors on my system for a new test which is introduced by [1].David gave some good hints how to increase the heap. Unfortunately it didn't fix my problem yet, but
you may anyway want to check the discussion on [1].
For the existing tests I'm not seeing any OutOfMemoryErrors at the moment, but I have seen some
from time to time in the past.
David Ostrovsky
Feb 12, 2014, 3:23:41 AM2/12/14
to repo-d...@googlegroups.com
As mentioned in another thread I would like to suggest to wait for two
series + two changes being merged before cutting 2.9-rc.0:
1. Project documentation [1].
2. Inline editing [2] + De-externalization of change fabricator plugin [3].
3. WIP workflow, either as standalone [4] or as overloaded DRAFT workflow [5].
The series 2. above would enable us to support 100% browser based Gerrit
workflow and with combination with series 1. even make it possible to (ab-)use
Gerrit as a full fledged Wiki ;-)
Reply all
Reply to author
Forward
0 new messages