does the UX branch still need to exist now that "master" is open again?

[Andrew Sutherland]

I think the rationale for the UX branch was that since UX work was
effectively forbidden when the master branch was locked down, it
provided a place to do that work. But now that the "master" branch is
open, it seems like UX work should happen just like all other
development work with explicitly reviewed pull requests tracked to bugs,
etc.

Andrew

[Jason Smith]

I think I mentioned this to Naoki a while back and we agreed that branch
should disappear, but it apparently is still being used. Can we kill
that uxbranch and just use master? Josh?

Sincerely,
Jason Smith

Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Naoki Hirata]

The UX Branch QAing is currently inactive AFAIK. I'm no longer
verifying bugs on the branch, since things should be able to land on
master and I need to concentrate on other things.

Gordon and Sam should be included in this discussion as well as they
were the ones maintaining the branch.

If master is the branch to remain open and we just pick based on which
ever version we come out with, then there won't be a reason or need for
the uxbranch at all any more.

Having said that, I believe it's more important now to get some
automation tests so we catch regressions faster for master/inbound. UX
branch had a QA person testing around fixes to catch regressions prior
to it going into master and it helped.

Another question I have is after 1.0 and 1.0.1 are done, how are we
branching out v2 and everything else? Are we going to keep branching by
version number? Or are we going to do something similar to what we do
for desktop firefox and firefox for android? I believe that keeping
track of these branches will become a nightmare if it hasn't been already.

Regards,
Naoki

[Mª ANGELES OTEO MARTINEZ]

Hi,

I also think that branch does not make sense at this point of time.
However, there are some important bugs that have been landed there (in the
UX branch) and they are not yet in master. E.g.

Bug 835768 that is UX-P1 and marked as RESOLVED but afaik it is not
available in master.
Bug 815609 that fixes an important issue in the header Building Block,
was marked as a target for Berlin WW and it has been available in
UX-Branch since 14th January but not in master yet.

Is someone going to check the bugs landed in UX branch but not in master?
For us, it is really urgent if we do a cherry picking of UX-P1 asap.

Thanks


El 13/02/13 22:25, "Jason Smith" <jsm...@mozilla.com> escribió:

>I think I mentioned this to Naoki a while back and we agreed that branch
>should disappear, but it apparently is still being used. Can we kill
>that uxbranch and just use master? Josh?
>
>Sincerely,
>Jason Smith
>
>Desktop QA Engineer
>Mozilla Corporation
>https://quality.mozilla.com
>
>On 2/13/2013 1:20 PM, Andrew Sutherland wrote:
>> I think the rationale for the UX branch was that since UX work was
>> effectively forbidden when the master branch was locked down, it
>> provided a place to do that work. But now that the "master" branch is
>> open, it seems like UX work should happen just like all other
>> development work with explicitly reviewed pull requests tracked to
>> bugs, etc.
>>
>> Andrew
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>
>_______________________________________________
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Andrew Sutherland]

I don't think the loop ever got closed on this. Everyone who replied on
the thread seemed to agree that the UX branch should go away, but no one
with the power to stop people from using it ever replied.

There is currently 1 recently landed e-mail UI fix against the UX branch
with no clear path to landing on gaia/master, and many more outstanding
requests against the UX branch, so this is a resurgent issue for me.

Josh, could you provide some explicit guidance, which if it's not
"everybody stop using the UX branch and cherry-pick any landed commits
from the UX branch back to gaia/master", then please include an explicit
rationale and landing strategy to gaia/master for patches involving the
UX branch?

Thanks!
Andrew

[Josh Carpenter]

Shall we consolidate this conversation into the parallel "does the UX branch still need to exist now that "master" is open again?" thread? It's confusing having the same conversation in two places. Both Patryk and I have chimed in with thoughts there in the last 24 hours. I'll add dev-gaia to that thread.

—
Josh Carpenter
UX, Firefox OS
Mozilla

[Josh Carpenter]

[+devgaia]

—
Josh Carpenter
UX, Firefox OS
Mozilla

On Mar 4, 2013, at 11:04 PM, Josh Carpenter <jcarp...@mozilla.com> wrote:

> This is a good conversation to have. Thank you for nudging it along, Maria.
>
> Perhaps we can step back and separate the needs from the solution. Per Patryk's email, it seems important that:
>
> 1.) There is a funneling and review process for incoming UX changes.
> 2.) There is a reliable mechanism for making high-volume / low-risk primarily-visual changes.
>
> So long as we can be assured of the ability to fulfill those two requirements, I'm sure other solutions are acceptable. Perhaps continuation of the UX branch, perhaps new processes?
>
> We may also want to clarify the new processes for future 1.x releases, especially WRT to the end of the dev cycle where fear of regressions is highest. I've seen many emails go back and forth on this topic in the past few days.

>
> —
> Josh Carpenter
> UX, Firefox OS
> Mozilla
>

> On Mar 4, 2013, at 5:39 PM, Patryk Adamczyk <pada...@mozilla.com> wrote:
>
>> UX issues, specifically visual design issues should still be going through the UX branch. These would be changes made by visual designers and I'd like Sam to have a quick look before merging them into master as we want the most stable and performant code going in. Currently only Mozilla designers, Pavel and Sam land patches there I believe.
>>
>> The UX branch gets merged into master atleast once a week, but Sam can comment further.
>>
>> But depending on the change, if it does need dev support they should land into master. As we lock down the amount of changes going into master I suspect the UX branch may become more useful.
>>
>> If there is a better method to streamline the integration of POLISH bugs after feature complete, then please let Sam and I know.
>> Thanks!
>>
>> --
>> Patryk Adamczyk, R.G.D.
>> Senior User Experience Designer, Visual Design
>> Visual Design Lead on Firefox OS
>> Mozilla Corporation
>> On Monday, 4 March, 2013 at 8:30 AM, Mª ANGELES OTEO MARTINEZ wrote:
>>
>>> Hi all,
>>>
>>> Sorry for disturbing you again with this issue but as you can see nobody
>>> answered my questions and no other official communication about the UX
>>> branch has been sent yet.
>>>
>>> I've just seen a bug landing in UX branch right now so it reminded me this
>>> issue again (I raised the question in last b2g meeting too).
>>>
>>> Last landing on master from UX branch was last 2/18 after freezing the
>>> v1.0.1 branch. For many of the fixes in the UX branch we didn't have the
>>> opportunity of uplifting them in v1-train and v1.0.1.
>>>
>>> I would like to avoid this to happen again, because after the freezing of
>>> a branch, all this is more complex to handle.
>>>
>>> So my questions are again:
>>>
>>> 1) Does it make sense to maintain the UX branch when now in master we can
>>> land anything with just r+?
>>> 2) In case you decide it's better to maintain it, how often will it be
>>> merged with master? We need to know this so we can try the uplift (through
>>> the revision/triages flow) the bugs we consider are interesting to land in
>>> a concrete branch.
>>>
>>> Please, if you could be so kind to clarify
>>> Thanks and best regards
>>> Maria
>>>
>>> El 14/02/13 16:05, "Mª Ángeles Oteo" <ot...@tid.es> escribió:
>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> Any update about this?
>>>> We are in hurry with v1.0.1 branch, so if there is no plans to update the
>>>> master with the UX branch asap, at least we should ask developers to land
>>>> these important UX bugs today in master so we have the opportunity to
>>>> request gaia-approval-v1 and land them in v1.0.1.
>>>>
>>>> Please, let me know
>>>> Cheers
>>>> Maria
>>>>
>>>>
>>>> El 13/02/13 23:04, "Mª ANGELES OTEO MARTINEZ" <ot...@tid.es> escribió:

>>>>
>>>>> Hi,
>>>>>
>>>>> I also think that branch does not make sense at this point of time.
>>>>> However, there are some important bugs that have been landed there (in
>>>>> the
>>>>> UX branch) and they are not yet in master. E.g.
>>>>>
>>>>> Bug 835768 that is UX-P1 and marked as RESOLVED but afaik it is not
>>>>> available in master.
>>>>> Bug 815609 that fixes an important issue in the header Building Block,
>>>>> was marked as a target for Berlin WW and it has been available in
>>>>> UX-Branch since 14th January but not in master yet.
>>>>>
>>>>> Is someone going to check the bugs landed in UX branch but not in
>>>>> master?
>>>>> For us, it is really urgent if we do a cherry picking of UX-P1 asap.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> El 13/02/13 22:25, "Jason Smith" <jsm...@mozilla.com> escribió:
>>>>>
>>>>>> I think I mentioned this to Naoki a while back and we agreed that branch
>>>>>> should disappear, but it apparently is still being used. Can we kill
>>>>>> that uxbranch and just use master? Josh?
>>>>>>
>>>>>> Sincerely,
>>>>>> Jason Smith
>>>>>>
>>>>>> Desktop QA Engineer
>>>>>> Mozilla Corporation
>>>>>> https://quality.mozilla.com
>>>>>>

>>>>>> On 2/13/2013 1:20 PM, Andrew Sutherland wrote:
>>>>>>> I think the rationale for the UX branch was that since UX work was
>>>>>>> effectively forbidden when the master branch was locked down, it
>>>>>>> provided a place to do that work. But now that the "master" branch is
>>>>>>> open, it seems like UX work should happen just like all other
>>>>>>> development work with explicitly reviewed pull requests tracked to
>>>>>>> bugs, etc.
>>>>>>>
>>>>>>> Andrew
>>>>>>> _______________________________________________
>>>>>>> dev-gaia mailing list
>>>>>>> dev-...@lists.mozilla.org
>>>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev-gaia mailing list
>>>>>> dev-...@lists.mozilla.org
>>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>>>
>>>>>

>>>>> ________________________________
>>>>>
>>>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
>>>>> nuestra política de envío y recepción de correo electrónico en el enlace
>>>>> situado más abajo.
>>>>> This message is intended exclusively for its addressee. We only send and
>>>>> receive email on the basis of the terms set out at:
>>>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

>>>>> _______________________________________________
>>>>> dev-gaia mailing list
>>>>> dev-...@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>>

>>> ________________________________
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
>>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

>>> Forwarded message:
>>>
>>>> From: Sam Joch <notifi...@github.com>
>>>> Reply To: mozilla-b2g/gaia <reply+i-11108383-77107b4fb5a7ec3...@reply.github.com>
>>>> To: mozilla-b2g/gaia <ga...@noreply.github.com>
>>>> Date: Monday, 18 February, 2013 4:43:54 AM
>>>> Subject: [gaia] Ux branch bugs cherry picked *not: qa-verified* (#8164)
>>>>
>>>> #804166 - [Settings] Device Storage Memory Usage Bar Needs Redesign
>>>> #815653 - [Settings] - remove :active for explanation items
>>>> #816067 - [FTU. UX VD] Change background.
>>>> #816135 - [Icons - Assets] Need assets for all the wifi icon scenarios.
>>>> #823414 - B2G browser gradient value does not match the gradient found in Settings
>>>> #823472 - [FTU UX VD] Replace "Hello" bubbles illustration asset in lenguage selection
>>>> #828908 - [Settings] Hints should not be treated as list items
>>>> #830111 - [Settings] - arrange Phone lock screen
>>>> #830127 - [BB][input_areas] - pointer-events is not correct
>>>> #834102 - [Browser] Too much padding to left of address in address bar
>>>> #834446 - [Browser] Truncated Bookmark Label
>>>>
>>>> You can merge this Pull Request by running
>>>>
>>>> git pull https://github.com/gordonbrander/gaia ux-cherry-picked
>>>> Or view, comment on, or merge it at:
>>>>
>>>> https://github.com/mozilla-b2g/gaia/pull/8164
>>>>
>>>> Commit Summary
>>>>
>>>> Bug 804166 - [Settings] Device Storage Memory Usage Bar Needs Redesign
>>>> Bug 815653 - [Settings] - remove :active for explanation items
>>>> Bug 816067 - Change FTU backgrounds
>>>> Bug 816135 - [Icons - Assets] Need assets for all the wifi icon scenarios.
>>>> Bug 823414 - B2G browser gradient value does not match the gradient found in Settings
>>>> Bug 823472 - Replace bubbles image
>>>> Bug 828908 - [Settings] Hints should not be treated as list items
>>>> Bug 830111 - [Settings] - arrange Phone lock screen
>>>> Bug 830127 - [BB][input_areas] - pointer-events is not correct
>>>> Bug 834102 - [Browser] Too much padding to left of address in address bar
>>>> Bug 834446 - [Browser] Truncated Bookmark Label
>>>> File Changes
>>>>
>>>> M apps/browser/style/browser.css (24)
>>>> M apps/browser/style/images/drawer-header-background.png (0)
>>>> D apps/communications/ftu/css/images/bg_1px.png (0)
>>>> D apps/communications/ftu/css/images/bg_bottom.png (0)
>>>> A apps/communications/ftu/css/images/bg_grey-noise.png (0)
>>>> A apps/communications/ftu/css/images/bg_light.png (0)
>>>> D apps/communications/ftu/css/images/bg_top.png (0)
>>>> M apps/communications/ftu/css/style.css (10)
>>>> M apps/settings/index.html (25)
>>>> M apps/settings/js/wifi.js (8)
>>>> M apps/settings/style/icons.css (90)
>>>> A apps/settings/style/icons/wifi.png (0)
>>>> M apps/settings/style/lists.css (16)
>>>> M apps/settings/style/phone_lock.css (33)
>>>> M apps/settings/style/settings.css (14)
>>>> M shared/style/input_areas.css (2)
>>>> Patch Links:
>>>>
>>>> https://github.com/mozilla-b2g/gaia/pull/8164.patch
>>>> https://github.com/mozilla-b2g/gaia/pull/8164.diff
>>
>

[Andrew Sutherland]

On 03/05/2013 09:58 AM, Josh Carpenter wrote:
>> On Mar 4, 2013, at 5:39 PM, Patryk Adamczyk <pada...@mozilla.com> wrote:
>>> UX issues, specifically visual design issues should still be going through the UX branch. These would be changes made by visual designers and I'd like Sam to have a quick look before merging them into master as we want the most stable and performant code going in. Currently only Mozilla designers, Pavel and Sam land patches there I believe.

I think Sam should be able to review the patches and land them on
gaia/master rather than the UX branch.

What specifically is being accomplished by landing them on the UX branch
first other than losing the relation to the original filing bug,
introducing the potential for accidental merge-related regressions, and
increasing the potential for bit-rot due to drift between gaia/master
and the UX branch?

Andrew

[Josh Carpenter]

> What specifically is being accomplished by landing them on the UX branch first other than losing the relation to the original filing bug, introducing the potential for accidental merge-related regressions, and increasing the potential for bit-rot due to drift between gaia/master and the UX branch?

Quoting myself earlier, UX branch was a means to the following ends:

…. a funneling and review process for incoming UX changes.
… a reliable mechanism for making high-volume / low-risk primarily-visual changes late in the release cycle.

As you say though, we may be able to replace it with a new system. Who is the best single person to work with on determining that? I know engineering processes are in flux right now. Is there one master gate keeper / planner we should talk to?

—
Josh Carpenter
UX, Firefox OS
Mozilla

[Jason Smith]

Talk to Alex Keybl about this.

Sincerely,
Jason Smith

Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com

[Josh Carpenter]

Thanks Jason

—
Josh Carpenter
UX, Firefox OS
Mozilla

[DANIEL JESUS COLOMA BAIGES]

Any conclusion with respect to the usage of the UX branch?

On 3/5/13 7:21 PM, "Josh Carpenter" <jcarp...@mozilla.com> wrote:

>Thanks Jason
>‹
>Josh Carpenter
>UX, Firefox OS
>Mozilla
>
>On Mar 5, 2013, at 7:17 PM, Jason Smith <jsm...@mozilla.com> wrote:
>
>> Talk to Alex Keybl about this.
>>
>> Sincerely,
>> Jason Smith
>>
>> Desktop QA Engineer
>> Mozilla Corporation
>> https://quality.mozilla.com
>>
>> On 3/5/2013 10:12 AM, Josh Carpenter wrote:
>>>> What specifically is being accomplished by landing them on the UX
>>>>branch first other than losing the relation to the original filing
>>>>bug, introducing the potential for accidental merge-related
>>>>regressions, and increasing the potential for bit-rot due to drift
>>>>between gaia/master and the UX branch?
>>> Quoting myself earlier, UX branch was a means to the following ends:
>>>

>>> Š. a funneling and review process for incoming UX changes.
>>> Š a reliable mechanism for making high-volume / low-risk

[Alex Keybl]

It's up to the UX team whether or not they'd like to use a UX branch. We don't have any builds coming from that branch, so builds would need to happen locally. As long as bugs are not marked as Resolved/Fixed when landed to the UX branch, and there's no expectation around an uplift from UX->master or UX->v1-train, we should be fine. Bugs that are waiting on some sort of review before landing to master can be flagged in bugzilla.

What concerns remain unaddressed?

-Alex

[DANIEL JESUS COLOMA BAIGES]

Thanks Alex! I agree that is not your call to decide what to do with that
branch. It was a open question to everyone in this list or at least to the
people that has expressed an opinion before.

Basically the concern is whether people working on visual bugs should land
those fixes directly in master or go through the UX-branch. Thoughts?

[Jason Smith]

Given the definition of what master has become (a 2.0 branch) and
knowing that regression control right now is more critical on b2g18 and
any partner branch, not necessarily master, I'd argue it's okay to
target initial landings on master rather than the UX branch. When they
land on master, any patches that are low risk can go through the typical
approval process and ask for QA involvement as needed to verify the
patches safety if need be.

This approach of removing the UX branch intermediary I think will help
reduce the complexity of our process overall that we don't necessarily
need anymore (it cuts off one additional step), eliminates the "always
needs qa verification for every single bug" requirement before landing
as approvals will help assess risk, etc.

Sincerely,
Jason Smith

Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com