Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Happy birthday Gaia! <gifts>Smoke Tests / Branches / Good Practices</gifts>
47 views
Skip to first unread message
Vivien
Sep 14, 2012, 3:36:49 PM9/14/12
to dev-...@lists.mozilla.org
Hello Gaia developers!
What the hell! Gaia will be one year old on Sunday and there is no gift
for it? No way. Here comes the new |nightly| branch.
The policy to land patches on Gaia master branch has been very relax
since the start of the Gaia project the 16th of September last year. The
project begun with only a few people hacking on it and imo there was no
reasons to have a strict policy but then more and more people starts
hacking on it and it slowly (relatively to the age of the project)
became a squadron of Gaia hackers and a rainfall of patches and pull
requests. The project has evolved and there was a shift at some point
where it has been decided to used for the release. There is much more
people looking at Gaia now and dogfooders are lurking around to try our
product.
At the same time, a huge amount of bugs have bloomed and more will come
with the v1 spring coming - it's like a whac-a-mole game. IMHO the flow
of patches should not be stopped at this time but how can we ensure the
a basic set of functionality (making a call, surfing the web, receiving
an sms, etc...) working for users and keeping the same amount of
productivity people have demonstrated in the past few months?
"Tests!"
This is the obvious response but the reality comes back and kick our
head. There is no automated integration tests right now for Gaia that
can guarantee us a working set of devices features.
I can already heard the Mocha! Marionette! Mochitests! Monkey Runner!
thread this assumption can potentially generate. Again my head hurts but
this is a reality, there is nothing right now and it needs an answer.
An automated solution will be provided at some point that resolve those
integrations test case on the device. But in the meantime it needs to be
something, and this something should be extendable once automated tests
will come in play.
As much as I dislike it this something is manual *Smoke Tests* - our own
manual tbpl (https://tbpl.mozilla.org/) runs by human. The list of tests
can be found here: https://wiki.mozilla.org/images/c/c8/PatchSmokeTests.pdf
Those tests are pretty basic but manually running all of them is a
incredible lost of time. And this is a nightmare when you start to think
about reviews and back and forth, incremental changes, timezone
differences, merging issues, broken applications that does not depends
on your changes, or even platform regression. Welcome to hell!
"But it needs to be an assurance that the product works!"
Right! In order to make sure Smoke Tests are green without killing the
development efforts and adding too much overhead on top of the hard work
the team is doing, a new branch has been added to the main Gaia
repository: |nightly|.
Starting by monday the |nightly| will receive changes from the |master|
branch only if all tests are passing.
"What does it means in a developer workflow?" Keep working as you did,
keep pushing patches and keep changing the world.
"What does it means the rest of the world?" A stable branch where Smoke
Tests are always green that you can enjoy safely.
"Is there really no changes for nobodies and only happiness in the
world?" No. That was a lie.
- For developers here the changes:
For this process to work (and so for easy backout on the master branch)
it implies some changes to the commit messages format. We're used on
Gaia to land tons of commits with every pull request, many of them are
named 'Nits' or 'Small changes', etc...
From now let's start to learn how to use |git rebase -i| (have a look
at
http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
squash your commits and format the commit message as: "[issue number]
super_clear_commit_message.". If you have issues with that, let's ask in
#gaia and we can share the pain alltogether.
- For dogfooders, contributors, localizers, QA, PM, fish&chips, ...:
You want something stable? Really? *git checkout nightly && make
production*. This can be automated but switching people branches without
their consent is not really fair so it is still a manual step for now.
This will pull the latest stable branch without any of the testing
applications and install them on your device like it is out of the box.
"But I don't see the changes that has been done one hour ago by bob!"
The |master| branch will be merged in the |nightly| branch a few times
per day. For the moment there will be one merge every day at *2p.m Paris
Time* (CEST UTC + 2).
It means the merge will happen at *8p.m in Taipei* (SGT UTC + 8) and
*5a.m in San Francisco* (PDT UTC - 7).
There is no reasons for not having more merge once the process is in
place (For example if Taipei wants to do a merge at 2p.m too they just
need to ensure the Smoke Tests are green and then they can merge, same
things with our TEF friends, etc...).
Merge will be done by sheriffs that runs smoketests themselves and
ensure the product keeps working. If something breaks Gaia it will be
back-outed and the 'Same player, play again' rule will apply for the
next merge.
"I have always dream of this golden star and I want to be a sheriff,
tell me how?" Do you have an Otoro handy? Do you like to be an ass and
to backout people's code? You're hired!
Happy birthday Gaia!
Vivien.
What the hell! Gaia will be one year old on Sunday and there is no gift
for it? No way. Here comes the new |nightly| branch.
The policy to land patches on Gaia master branch has been very relax
since the start of the Gaia project the 16th of September last year. The
project begun with only a few people hacking on it and imo there was no
reasons to have a strict policy but then more and more people starts
hacking on it and it slowly (relatively to the age of the project)
became a squadron of Gaia hackers and a rainfall of patches and pull
requests. The project has evolved and there was a shift at some point
where it has been decided to used for the release. There is much more
people looking at Gaia now and dogfooders are lurking around to try our
product.
At the same time, a huge amount of bugs have bloomed and more will come
with the v1 spring coming - it's like a whac-a-mole game. IMHO the flow
of patches should not be stopped at this time but how can we ensure the
a basic set of functionality (making a call, surfing the web, receiving
an sms, etc...) working for users and keeping the same amount of
productivity people have demonstrated in the past few months?
"Tests!"
This is the obvious response but the reality comes back and kick our
head. There is no automated integration tests right now for Gaia that
can guarantee us a working set of devices features.
I can already heard the Mocha! Marionette! Mochitests! Monkey Runner!
thread this assumption can potentially generate. Again my head hurts but
this is a reality, there is nothing right now and it needs an answer.
An automated solution will be provided at some point that resolve those
integrations test case on the device. But in the meantime it needs to be
something, and this something should be extendable once automated tests
will come in play.
As much as I dislike it this something is manual *Smoke Tests* - our own
manual tbpl (https://tbpl.mozilla.org/) runs by human. The list of tests
can be found here: https://wiki.mozilla.org/images/c/c8/PatchSmokeTests.pdf
Those tests are pretty basic but manually running all of them is a
incredible lost of time. And this is a nightmare when you start to think
about reviews and back and forth, incremental changes, timezone
differences, merging issues, broken applications that does not depends
on your changes, or even platform regression. Welcome to hell!
"But it needs to be an assurance that the product works!"
Right! In order to make sure Smoke Tests are green without killing the
development efforts and adding too much overhead on top of the hard work
the team is doing, a new branch has been added to the main Gaia
repository: |nightly|.
Starting by monday the |nightly| will receive changes from the |master|
branch only if all tests are passing.
"What does it means in a developer workflow?" Keep working as you did,
keep pushing patches and keep changing the world.
"What does it means the rest of the world?" A stable branch where Smoke
Tests are always green that you can enjoy safely.
"Is there really no changes for nobodies and only happiness in the
world?" No. That was a lie.
- For developers here the changes:
For this process to work (and so for easy backout on the master branch)
it implies some changes to the commit messages format. We're used on
Gaia to land tons of commits with every pull request, many of them are
named 'Nits' or 'Small changes', etc...
From now let's start to learn how to use |git rebase -i| (have a look
at
http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
squash your commits and format the commit message as: "[issue number]
super_clear_commit_message.". If you have issues with that, let's ask in
#gaia and we can share the pain alltogether.
- For dogfooders, contributors, localizers, QA, PM, fish&chips, ...:
You want something stable? Really? *git checkout nightly && make
production*. This can be automated but switching people branches without
their consent is not really fair so it is still a manual step for now.
This will pull the latest stable branch without any of the testing
applications and install them on your device like it is out of the box.
"But I don't see the changes that has been done one hour ago by bob!"
The |master| branch will be merged in the |nightly| branch a few times
per day. For the moment there will be one merge every day at *2p.m Paris
Time* (CEST UTC + 2).
It means the merge will happen at *8p.m in Taipei* (SGT UTC + 8) and
*5a.m in San Francisco* (PDT UTC - 7).
There is no reasons for not having more merge once the process is in
place (For example if Taipei wants to do a merge at 2p.m too they just
need to ensure the Smoke Tests are green and then they can merge, same
things with our TEF friends, etc...).
Merge will be done by sheriffs that runs smoketests themselves and
ensure the product keeps working. If something breaks Gaia it will be
back-outed and the 'Same player, play again' rule will apply for the
next merge.
"I have always dream of this golden star and I want to be a sheriff,
tell me how?" Do you have an Otoro handy? Do you like to be an ass and
to backout people's code? You're hired!
Happy birthday Gaia!
Vivien.
Nicolas B. Pierron
Sep 14, 2012, 4:12:11 PM9/14/12
to mozilla-...@lists.mozilla.org
On 09/14/2012 12:36 PM, Vivien wrote:
> - For developers here the changes:
>
> - For developers here the changes:
>
> From now let's start to learn how to use |git rebase -i| (have a look at
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
> squash your commits and format the commit message as: "[issue number]
> super_clear_commit_message.". If you have issues with that, let's ask in
> #gaia and we can share the pain alltogether.
FYI, �git rebase -i� only works for people who are used to develop with
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
> squash your commits and format the commit message as: "[issue number]
> super_clear_commit_message.". If you have issues with that, let's ask in
> #gaia and we can share the pain alltogether.
rebase. Rebase can be difficult to handle if you are doing merges, which
might be more practical than rebase in a few cases. Don't worry, you can
still clean-up the history of your branch to submit it for a pull request:
git diff upstream/master my-dirty-branch > my-branch.patch
git co -b clean-branch upstream/master
patch -p1 < my-branch.patch
git commit -am "My Nice looking commit message."
Otherwise, you might want to have a look at top-git, which is exporting
commits from a dirty branch into one nice commit.
> - For dogfooders, contributors, localizers, QA, PM, fish&chips, ...:
>
> You want something stable? Really? *git checkout nightly && make
> production*. This can be automated but switching people branches without
> their consent is not really fair so it is still a manual step for now.
frequently as I can, and currently the process has been simple.
--
Nicolas B. Pierron
Andrew Sutherland
Sep 14, 2012, 5:56:42 PM9/14/12
to dev-...@lists.mozilla.org
On 09/14/2012 12:36 PM, Vivien wrote:
> For this process to work (and so for easy backout on the master
> branch) it implies some changes to the commit messages format. We're
> used on Gaia to land tons of commits with every pull request, many of
> them are named 'Nits' or 'Small changes', etc...
>
> branch) it implies some changes to the commit messages format. We're
> used on Gaia to land tons of commits with every pull request, many of
> them are named 'Nits' or 'Small changes', etc...
>
> From now let's start to learn how to use |git rebase -i| (have a look
> at
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
> squash your commits and format the commit message as: "[issue number]
> super_clear_commit_message.". If you have issues with that, let's ask
> in #gaia and we can share the pain alltogether.
Should we be trying to push things to 'master' as fast-forward merges by
> at
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
> squash your commits and format the commit message as: "[issue number]
> super_clear_commit_message.". If you have issues with that, let's ask
> in #gaia and we can share the pain alltogether.
locally rebasing the pull requests, or is it okay to still just hit the
"merge" button on the github pull request web UI?
Also, this sounds like a great improvement over the alternative of
everyone manually running all the smoke tests on every commit. Thank you!
Andrew
Tim Guan-tin Chien
Sep 15, 2012, 3:22:14 PM9/15/12
to Vivien, John Shih, dev-...@lists.mozilla.org
This is a great news!
On 9/15/12 3:36 AM, Vivien wrote:
> There is no reasons for not having more merge once the process is in
> place (For example if Taipei wants to do a merge at 2p.m too they just
> need to ensure the Smoke Tests are green and then they can merge, same
> things with our TEF friends, etc...).
>
Just to response to this part. So who is doing the actual master ->
nightly merging? If this should be done by QA, I am happy to let John do
it if he likes.
--
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
On 9/15/12 3:36 AM, Vivien wrote:
> There is no reasons for not having more merge once the process is in
> place (For example if Taipei wants to do a merge at 2p.m too they just
> need to ensure the Smoke Tests are green and then they can merge, same
> things with our TEF friends, etc...).
>
nightly merging? If this should be done by QA, I am happy to let John do
it if he likes.
--
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
Vivien
Sep 17, 2012, 7:22:55 AM9/17/12
to Andrew Sutherland, dev-...@lists.mozilla.org
On 14/09/2012 23:56, Andrew Sutherland wrote:
> On 09/14/2012 12:36 PM, Vivien wrote:
>> For this process to work (and so for easy backout on the master
>> branch) it implies some changes to the commit messages format. We're
>> used on Gaia to land tons of commits with every pull request, many of
>> them are named 'Nits' or 'Small changes', etc...
>>
>> From now let's start to learn how to use |git rebase -i| (have a look
>> at
>> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
>> squash your commits and format the commit message as: "[issue number]
>> super_clear_commit_message.". If you have issues with that, let's ask
>> in #gaia and we can share the pain alltogether.
>
> Should we be trying to push things to 'master' as fast-forward merges
> by locally rebasing the pull requests, or is it okay to still just hit
> the "merge" button on the github pull request web UI?
It seems OK to me to push the green button. My hope with this solution
> On 09/14/2012 12:36 PM, Vivien wrote:
>> For this process to work (and so for easy backout on the master
>> branch) it implies some changes to the commit messages format. We're
>> used on Gaia to land tons of commits with every pull request, many of
>> them are named 'Nits' or 'Small changes', etc...
>>
>> From now let's start to learn how to use |git rebase -i| (have a look
>> at
>> http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages),
>> squash your commits and format the commit message as: "[issue number]
>> super_clear_commit_message.". If you have issues with that, let's ask
>> in #gaia and we can share the pain alltogether.
>
> Should we be trying to push things to 'master' as fast-forward merges
> by locally rebasing the pull requests, or is it okay to still just hit
> the "merge" button on the github pull request web UI?
is to make it as transparent as possible.
>
> Also, this sounds like a great improvement over the alternative of
> everyone manually running all the smoke tests on every commit. Thank you!
>
> Andrew
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Vivien
Sep 17, 2012, 7:26:35 AM9/17/12
to Tim Guan-tin Chien, John Shih, dev-...@lists.mozilla.org
On 15/09/2012 21:22, Tim Guan-tin Chien wrote:
> This is a great news!
>
> On 9/15/12 3:36 AM, Vivien wrote:
>> There is no reasons for not having more merge once the process is in
>> place (For example if Taipei wants to do a merge at 2p.m too they
>> just need to ensure the Smoke Tests are green and then they can
>> merge, same things with our TEF friends, etc...).
>>
> Just to response to this part. So who is doing the actual master ->
> nightly merging? If this should be done by QA, I am happy to let John
> do it if he likes.
Today I will do it but things can be improved in the future to create a
> This is a great news!
>
> On 9/15/12 3:36 AM, Vivien wrote:
>> There is no reasons for not having more merge once the process is in
>> place (For example if Taipei wants to do a merge at 2p.m too they
>> just need to ensure the Smoke Tests are green and then they can
>> merge, same things with our TEF friends, etc...).
>>
> Just to response to this part. So who is doing the actual master ->
> nightly merging? If this should be done by QA, I am happy to let John
> do it if he likes.
script that does that automatically when someone says that the tests are
OK! QA is not involve in that at the moment but 'Sheriffs' will be
people that volunteer to do it. The only require skills is to be able to
runs the tests, do backouts if necessary and merge the 2 branches (and
have an otoro). If John has the skill for it that sounds great!
John Shih
Sep 17, 2012, 9:20:07 AM9/17/12
to Vivien, dev-...@lists.mozilla.org, Tim Guan-tin Chien
I can do this if there is enough information for me
And I'll talk to Tim about it this week
best regards,
John Shih
Intern of Mozilla Taiwan
And I'll talk to Tim about it this week
best regards,
John Shih
Intern of Mozilla Taiwan
sagork...@gmail.com
Oct 7, 2013, 4:19:57 AM10/7/13
to
Bdayo.Com is a website that offers freebies for birthday celebrations on you and your friends’ birthdays. Download our Bdayo.Com mobile app off iTunes or use the website to gain instant access to a variety of freebies for birthday celebrations.
The Bdayo.Com( http://www.bdayo.com/ ) mobile app on the iPhone can help you find local freebies and free stuff you can get on your birthday for birthday celebrations. Birthday celebrations can be planned ahead of time and fun with the Bdayo.Com app when it finds you Birthday Freebies in your local area.
When you look up locations on the Bdayo.Com website or mobile app for a franchise that offers freebies for birthday celebrations, you will also get a description of exactly what the deal is on your birthday. Certain franchises require you to sign up for a free e-mail club membership so you can get free stuff on your birthday celebration. Different things for your celebration include coupons, tickets, pass, etc.
Bdayo.Com has a variety of free prizes and freebies for your birthday celebration you can win if you sign up with us.
Did you ever wish you were VIP on your birthday? How about when you’re having a tough day at work and you’re broke on your birthday? Wouldn’t you like to treat yourself out to a free meal on your birthday if you could? There is an awesome new way to receive free gifts and prizes on your birthday using Bdayo.Com. The Bdayo.Com service is unique and versatile because users are able to gain free gifts and services through their friendly website or utilize the mobile application on the go.
With the Bdayo.Com mobile application, birthday planning is easy and fun. Bdayo.Com’s services are instantly accessible, fast, and efficient for looking up locations in your area where they offer various free prizes and gifts.
How often do you get to celebrate your birthday with a free meal or service at your disposal? Thanks to Bdayo.Com’s service, you can have a blast on your birthday by gaining free gifts. With the mobile app, on the go birthday planning on your way back from work is easy and fast. Just type in your area code and you’ll receive a bunch of locations nearby that offer freebies on your birthday!
The Bdayo.Com( http://www.bdayo.com/ ) mobile app on the iPhone can help you find local freebies and free stuff you can get on your birthday for birthday celebrations. Birthday celebrations can be planned ahead of time and fun with the Bdayo.Com app when it finds you Birthday Freebies in your local area.
When you look up locations on the Bdayo.Com website or mobile app for a franchise that offers freebies for birthday celebrations, you will also get a description of exactly what the deal is on your birthday. Certain franchises require you to sign up for a free e-mail club membership so you can get free stuff on your birthday celebration. Different things for your celebration include coupons, tickets, pass, etc.
Bdayo.Com has a variety of free prizes and freebies for your birthday celebration you can win if you sign up with us.
Did you ever wish you were VIP on your birthday? How about when you’re having a tough day at work and you’re broke on your birthday? Wouldn’t you like to treat yourself out to a free meal on your birthday if you could? There is an awesome new way to receive free gifts and prizes on your birthday using Bdayo.Com. The Bdayo.Com service is unique and versatile because users are able to gain free gifts and services through their friendly website or utilize the mobile application on the go.
With the Bdayo.Com mobile application, birthday planning is easy and fun. Bdayo.Com’s services are instantly accessible, fast, and efficient for looking up locations in your area where they offer various free prizes and gifts.
How often do you get to celebrate your birthday with a free meal or service at your disposal? Thanks to Bdayo.Com’s service, you can have a blast on your birthday by gaining free gifts. With the mobile app, on the go birthday planning on your way back from work is easy and fast. Just type in your area code and you’ll receive a bunch of locations nearby that offer freebies on your birthday!
willy martin aguirre rodriguez
Oct 7, 2013, 11:18:03 AM10/7/13
to sagork...@gmail.com, dev-...@lists.mozilla.org
sorry is spam ???
2013/10/7 <sagork...@gmail.com>
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Reps: https://reps.mozilla.org/u/Willy/
Mozilla Hispano -
Willyaguirre<https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre>
2013/10/7 <sagork...@gmail.com>
> _______________________________________________
> 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
>
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Reps: https://reps.mozilla.org/u/Willy/
Mozilla Hispano -
Willyaguirre<https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre>
sagork...@gmail.com
Oct 11, 2013, 3:40:27 AM10/11/13
to
0 new messages