368163 - in the major update snippets that we give to 1.5.0.x users, include the channel attribute

Status: RESOLVED WONTFIX

(AUS Graveyard :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

in the major update snippets that we give to 1.5.0.x users, include the channel attribute

For the gory details, see https://bugzilla.mozilla.org/show_bug.cgi?id=368082#c9

Comment 1

[Jay Patel [:jay]]

mike: Is this something we can safely test on the server side if we can get the build team to create test snippets for us?  Does it require a server change to AUS itself or just a config file change that build can do on their end?

Comment 2

[Michael Morgan [:morgamic]]

So far channels have been something used only to determine what update AUS2 would offer the clicent.  I believe build knows the channels because they have to write snippets to the correct directory.

A change like this would require us to either add the info to our snippets or deduce channel from the path of the snippet.  Then, AUS would have to be updated to change its XML output.

Comment 3

[(not reading, please use [e-mail] instead)]

it seems like adding this to the snippets would be better than changing AUS.  or am I missing something?

Comment 4

[Michael Morgan [:morgamic]]

It depends.  If we stayed consistent with how we delivered build data to AUS2 so it can build the XML file, then putting the channel in the snippets would make sense for consistency's sake.

If we want a quick fix, then we could explore simply using AUS2 itself (the PHP part) to echo back the channel in an XML element.  It already knows the current client's channel because it is passed in via the app.update.url.  So if all you really need is that to be echo'd back, that is another way to do it that doesn't require editing of the build data files.

Comment 5

[Robert Helmer [:rhelmer]]

AUS constructs the XML at runtime based on the snippet .txt files. The path to
the text files already has the channel name in it, so unless we wanted this
attribute to not match the channel name I don't think there is any reason to
have it configurable in the snippet.

In either case we'd need to change the AUS source code to handle this new
attribute, since that's where the XML is generated.

Comment 6

[(not reading, please use [e-mail] instead)]

echoing back sounds good to me.  it would solve the problem and not require any snippet changes:

but, something to consider (and discuss at the 3pm meeting):

is it worth changing aus right now just to fix this bug?  or should we let 1.5.0.9 -> 2.0.0.x major update have this bug (#368082), and we'll fix it client side for 1.5.0.10?

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to comment #6)
> echoing back sounds good to me.  it would solve the problem and not require any
> snippet changes:
> 
> but, something to consider (and discuss at the 3pm meeting):
> 
> is it worth changing aus right now just to fix this bug?  or should we let
> 1.5.0.9 -> 2.0.0.x major update have this bug (#368082), and we'll fix it
> client side for 1.5.0.10?

The only thing I am unclear about is, is this a one-time hack to work around a bug in the client code, or is this now a required attribute?

If it's a one-time hack, we could special-case it so it only works under these  specific circumstances. 

From bug 368082 comment 9 it sounds like this will be a new required attribute, which allows the channel to be changed via the update.. is that correct?

Comment 8

[(not reading, please use [e-mail] instead)]

if we fix this client side for 1.5.0.10, then it would only be necessary when providing major updates to 1.5.0.9.

if we don't fix this client side for 1.5.0.10+, we'd need it for all 1.5.0.x -> major.

> From bug 368082 comment 9 it sounds like this will be a new required attribute,
> which allows the channel to be changed via the update.. is that correct?

I'm not sure I understand.  can you elaborate?

but, it is not required for 1.5.0.x - > 1.5.0.x, or for 2.0.0.x -> 2.0.0.x (or 2 -> 3, as both use channel).

just for 1.5 -> 2 (and eventually, 1.5 -> 3, if we do that.)

Comment 9

[Robert Helmer [:rhelmer]]

(In reply to comment #8)
> if we fix this client side for 1.5.0.10, then it would only be necessary when
> providing major updates to 1.5.0.9.
> 
> if we don't fix this client side for 1.5.0.10+, we'd need it for all 1.5.0.x ->
> major.
> 
> > From bug 368082 comment 9 it sounds like this will be a new required attribute,
> > which allows the channel to be changed via the update.. is that correct?
> 
> I'm not sure I understand.  can you elaborate?


Not sure I understand either, but I'll try :)
I am wondering what the "channel" attribute is for, and why we need it for major update. I think the answer to that might help us to decide which way to proceed.

Comment 10

[(not reading, please use [e-mail] instead)]

wontfix, per the meeting today.  we're going to leave patcher and AUS alone, and fix this on the client side for 1.5.0.10.

see bug #368082