On Aug 12, 2013, at 10:06 PM, Andreas Gal wrote:
>
> Andreas: "and those cases we can handle with client-driven migration."
>> Lloyd: it seems like client managed upgrade is the way to go here, "
> Sounds like we are in agreement here, no?
The only difference is that if 100% of cases require cl
Andreas: "and those cases we can handle with client-driven migration."
Lloyd: it seems like client managed upgrade is the way to go here, "
Sounds like we are in agreement here, no?
Andreas
___
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail
- Original Message -
> More to the point, I assert that it is an explicit design requirement that
> there not be more than one user-visible flag day. If the only way to
> accomplish that were a zero-migration "burn it down, old clients just break,
> new client or bust" I would still prefe
On Aug 11, 2013, at 2:36 AM, Andreas Gal wrote:
> Ok, I guess we are conflating different kinds of flag days here. A major flag
> day is when you need user involvement to move forward, such as creating new
> Firefox accounts.
>
> What you are describing is an upgrade event, which can be solved
On Aug 12, 2013, at 5:05 AM, Andreas Gal wrote:
>
>
> Ryan Kelly wrote:
>>
>> On 12/08/2013 11:38 AM, Andreas Gal wrote:
>>> Ryan Kelly wrote:
On 11/08/2013 4:36 PM, Andreas Gal wrote:
> once we went
> through one flag day and have the data stored in cleartext we can do
> arbi
Ryan Kelly wrote:
On 12/08/2013 11:38 AM, Andreas Gal wrote:
Ryan Kelly wrote:
On 11/08/2013 4:36 PM, Andreas Gal wrote:
once we went
through one flag day and have the data stored in cleartext we can do
arbitrary storage format and wire protocol format changes.
Worst case we have to operate
On 12/08/2013 11:38 AM, Andreas Gal wrote:
> Ryan Kelly wrote:
>> On 11/08/2013 4:36 PM, Andreas Gal wrote:
>>> once we went
>>> through one flag day and have the data stored in cleartext we can do
>>> arbitrary storage format and wire protocol format changes.
>>>
>>> Worst case we have to operate
Ryan Kelly wrote:
On 11/08/2013 4:36 PM, Andreas Gal wrote:
once we went
through one flag day and have the data stored in cleartext we can do
arbitrary storage format and wire protocol format changes.
Worst case we have to operate two services against the same data store
(reving the wire form
On 11/08/2013 4:36 PM, Andreas Gal wrote:
> once we went
> through one flag day and have the data stored in cleartext we can do
> arbitrary storage format and wire protocol format changes.
>
> Worst case we have to operate two services against the same data store
> (reving the wire format), or the
- Original Message -
From: "Andreas Gal"
To: "Brian Warner"
Cc: sync-dev@mozilla.org
Sent: Friday, August 9, 2013 8:57:30 PM
Subject: Re: The Sync 1.1 elephant^H^H^H^H^H^H option
Help me understand why we need a second flag day when changing wire
formats or storage format
I cannot answer all of these questions, but here's the bulk of them.
On Aug 10, 2013, at 8:07 PM, Mark Finkle wrote:
> 1. In my early discussions with the old Services team, Sync 2.0 was termed:
> (Sync 1.1 + bug fixes) + pluggable Auth. This that a reasonable definition?
Yes, plus taking what
- Original Message -
From: "Andreas Gal"
To: "Brian Warner"
Cc: sync-dev@mozilla.org
Sent: Friday, August 9, 2013 8:57:30 PM
Subject: Re: The Sync 1.1 elephant^H^H^H^H^H^H option
Help me understand why we need a second flag day when changing wire
formats or storage form
- Original Message -
> I am having a hard time parsing your double negatives here to be
> honest. We can go the 1.1 route without two flag days. If you
> disagree, please speak up. If not, lets move on.
If we can avoid two flag days, that would be great. I'm not qualified to answer
that,
I am having a hard time parsing your double negatives here to be
honest. We can go the 1.1 route without two flag days. If you
disagree, please speak up. If not, lets move on.
Andreas
Sent from Mobile.
On Aug 10, 2013, at 17:04, Nick Alexander wrote:
> On 13-08-09 9:55 PM, Andreas Gal wrote:
>
On 13-08-09 9:55 PM, Andreas Gal wrote:
I didn't say 0. I said that the 2 flag day argument is bogus. We will
have 1 flag day. Do we agree now?
I agree that we will have at least 1 flag day.
Re-reading this thread, I see nothing to suggest that you agree that
there are two independent changes
I didn't say 0. I said that the 2 flag day argument is bogus. We will
have 1 flag day. Do we agree now?
Andreas
Sent from Mobile.
On Aug 9, 2013, at 21:45, Nick Alexander wrote:
> On 13-08-09 9:33 PM, Andreas Gal wrote:
>> Ok. So neither require a flag day. Changing data formats might require
On 13-08-09 9:33 PM, Andreas Gal wrote:
Ok. So neither require a flag day. Changing data formats might require
a flag day. But that would require a flag day in the couchdb world as
well. In other words the two flag day scenario is a red herring. Do
you agree?
No.
The picl-idp-backed auth story
Ok. So neither require a flag day. Changing data formats might require
a flag day. But that would require a flag day in the couchdb world as
well. In other words the two flag day scenario is a red herring. Do
you agree?
Andreas
Sent from Mobile.
On Aug 9, 2013, at 21:28, Toby Elliott wrote:
>
On Aug 9, 2013, at 8:57 PM, Andreas Gal wrote:
> Help me understand why we need a second flag day when changing wire
> formats or storage formats.
Auth changeover wouldn't (necessarily) require a flag day. We could set the old
servers to accept both auth types.
Where it gets tricky is when so
Help me understand why we need a second flag day when changing wire
formats or storage formats.
Andreas
Sent from Mobile.
On Aug 9, 2013, at 18:02, Brian Warner wrote:
> On 8/9/13 4:37 PM, Lloyd Hilaiel wrote:
>
>> So I'd like to open a venting thread here. Let's capture once and for
>> all th
On 8/9/13 4:37 PM, Lloyd Hilaiel wrote:
> So I'd like to open a venting thread here. Let's capture once and for
> all the real, actual, user facing or implementation complexity
> downsides of implementing a new authentication flow and grafting it
> onto Sync 1.1.
I expect rnewman will express thi
On Aug 9, 2013, at 4:37 PM, Lloyd Hilaiel wrote:
> Grafting a better sign up onto sync 1.1 has been talked about as a way to
> address usability problems in sync without having to deal with the complexity
> of the current implementation. A way to release a fix to sync faster.
>
> Talking abo
Grafting a better sign up onto sync 1.1 has been talked about as a way to
address usability problems in sync without having to deal with the complexity
of the current implementation. A way to release a fix to sync faster.
Talking about this as a real option makes people really uncomfortable. I
23 matches
Mail list logo
