Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Gaia's use of git / github
30 views
Skip to first unread message
Jeff Griffiths
Jul 26, 2012, 4:01:10 PM7/26/12
to dev-...@lists.mozilla.org
Hi gang!
** DISCLAIMER ** No, I'm not proposing you switch to CVS. Nor do I
suggest that, at the current rate of development on basecamp goals, we
change anyone's working process.
I would like to provide some feedback that I think the gaia project
could be more accessible to outsiders / potential contributors if you
eventually adopted a git-flow style branch strategy for development. I
think we should consider moving to something like this *after* basecamp.
Currently, gaia is a river of changes, with 1 branch ( master ) and only
2 tags, the most recent from a month ago.
Once basecamp is done, you should seriously consider something like how
jetpack uses github, with master, stabilization and release branches:
https://wiki.mozilla.org/Jetpack/Development_Process#Branches
Additionally, all SDK releases are given a tag. Currently there are no
real releases, but as you hit milestones or QA has a change level that
passes tests, creating tags and reporting back to the list would be
really appreciated.
Finally, if I look at the history of changes in gaia I see many people
merging from the master branch of their own Github fork. This is not
ideal, and in Jetpack we tend to instead create specific feature
branches to implement something or fix a bug. One positive aspect of
this is that, if you name your feature branch in an explanatory way, it
is much easier for people to browser the master branch history list and
get a sense of what is going on.
$0.02, Jeff
** DISCLAIMER ** No, I'm not proposing you switch to CVS. Nor do I
suggest that, at the current rate of development on basecamp goals, we
change anyone's working process.
I would like to provide some feedback that I think the gaia project
could be more accessible to outsiders / potential contributors if you
eventually adopted a git-flow style branch strategy for development. I
think we should consider moving to something like this *after* basecamp.
Currently, gaia is a river of changes, with 1 branch ( master ) and only
2 tags, the most recent from a month ago.
Once basecamp is done, you should seriously consider something like how
jetpack uses github, with master, stabilization and release branches:
https://wiki.mozilla.org/Jetpack/Development_Process#Branches
Additionally, all SDK releases are given a tag. Currently there are no
real releases, but as you hit milestones or QA has a change level that
passes tests, creating tags and reporting back to the list would be
really appreciated.
Finally, if I look at the history of changes in gaia I see many people
merging from the master branch of their own Github fork. This is not
ideal, and in Jetpack we tend to instead create specific feature
branches to implement something or fix a bug. One positive aspect of
this is that, if you name your feature branch in an explanatory way, it
is much easier for people to browser the master branch history list and
get a sense of what is going on.
$0.02, Jeff
JOSE MANUEL CANTERA FONSECA
Jul 27, 2012, 7:04:58 AM7/27/12
to Jeff Griffiths, dev-...@lists.mozilla.org
+1
El 26/07/12 22:01, "Jeff Griffiths" <jgrif...@mozilla.com> escribió:
>_______________________________________________
>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
El 26/07/12 22:01, "Jeff Griffiths" <jgrif...@mozilla.com> escribió:
>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
Martin de Keijzer
Jul 27, 2012, 7:46:36 AM7/27/12
to JOSE MANUEL CANTERA FONSECA, Jeff Griffiths, dev-...@lists.mozilla.org
I'd like to encourage this idea as well, it gives the community a good starting point to contribute.
Tim Guan-tin Chien
Jul 27, 2012, 5:28:11 PM7/27/12
to dev-...@lists.mozilla.org
I am being asked by Dietrich to reply this thread.
During an offine conversation of the same topic, we covered the gitflow
and some of the minimal requirements for the stable branch (i.e. stable
as in QA-verified stable). I think besides that we should have a
definite set of requirements written on what we expect for the stable
branch, e.g.,
1. Is the new branching scheme can be transparent to devs, or we can
invent something what complete overwritten our current ops, e.g. pull
req, etc?
2. Do we allow features to be "skip ahead" and be merged into stable
first, or the stable can just follow the dev branch in a linear faction?
3. Do we have other requirement like being able to tag a release version?
In the prefect world I would love to have a dedicate stable branch
maintainer, which tests and merge every pull reqs *manually*, so we can
keep working with the current Github flow.
As of gitflow, if the benefit out-weight the disruption to the dev
process (I think it does not work with pull requests, correct me if I am
wrong), then it's a viable option.
Tim
--
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
During an offine conversation of the same topic, we covered the gitflow
and some of the minimal requirements for the stable branch (i.e. stable
as in QA-verified stable). I think besides that we should have a
definite set of requirements written on what we expect for the stable
branch, e.g.,
1. Is the new branching scheme can be transparent to devs, or we can
invent something what complete overwritten our current ops, e.g. pull
req, etc?
2. Do we allow features to be "skip ahead" and be merged into stable
first, or the stable can just follow the dev branch in a linear faction?
3. Do we have other requirement like being able to tag a release version?
In the prefect world I would love to have a dedicate stable branch
maintainer, which tests and merge every pull reqs *manually*, so we can
keep working with the current Github flow.
As of gitflow, if the benefit out-weight the disruption to the dev
process (I think it does not work with pull requests, correct me if I am
wrong), then it's a viable option.
Tim
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
Axel Hecht
Jul 27, 2012, 5:31:50 PM7/27/12
to mozilla-...@lists.mozilla.org
On 27.07.12 23:28, Tim Guan-tin Chien wrote:
> I am being asked by Dietrich to reply this thread.
>
> During an offine conversation of the same topic, we covered the gitflow
> and some of the minimal requirements for the stable branch (i.e. stable
> as in QA-verified stable). I think besides that we should have a
> definite set of requirements written on what we expect for the stable
> branch, e.g.,
>
> 1. Is the new branching scheme can be transparent to devs, or we can
> invent something what complete overwritten our current ops, e.g. pull
> req, etc?
> 2. Do we allow features to be "skip ahead" and be merged into stable
> first, or the stable can just follow the dev branch in a linear faction?
> 3. Do we have other requirement like being able to tag a release version?
>
> In the prefect world I would love to have a dedicate stable branch
> maintainer, which tests and merge every pull reqs *manually*, so we can
> keep working with the current Github flow.
>
> As of gitflow, if the benefit out-weight the disruption to the dev
> process (I think it does not work with pull requests, correct me if I am
> wrong), then it's a viable option.
I think you can edit pull requests to be against develop instead of master.
> I am being asked by Dietrich to reply this thread.
>
> During an offine conversation of the same topic, we covered the gitflow
> and some of the minimal requirements for the stable branch (i.e. stable
> as in QA-verified stable). I think besides that we should have a
> definite set of requirements written on what we expect for the stable
> branch, e.g.,
>
> 1. Is the new branching scheme can be transparent to devs, or we can
> invent something what complete overwritten our current ops, e.g. pull
> req, etc?
> 2. Do we allow features to be "skip ahead" and be merged into stable
> first, or the stable can just follow the dev branch in a linear faction?
> 3. Do we have other requirement like being able to tag a release version?
>
> In the prefect world I would love to have a dedicate stable branch
> maintainer, which tests and merge every pull reqs *manually*, so we can
> keep working with the current Github flow.
>
> As of gitflow, if the benefit out-weight the disruption to the dev
> process (I think it does not work with pull requests, correct me if I am
> wrong), then it's a viable option.
The primary difference between gitflow and another "name your branches
consistently" scheme is that your default branch that people pull is
actually a somewhat stable integration branch instead of trunk.
Axel
Alex Keybl
Jul 27, 2012, 6:20:47 PM7/27/12
to Tim Guan-tin Chien, dev-...@lists.mozilla.org
Here's the way I see things playing out. Let me know what you all think.
* Master
** Focus of v1 developers until Stabilization branch created
** Becomes Gaia v2 after the underlying Gecko 17 moves off of m-c
* Stabilization
** Created after Gecko 17 moves off of m-c
** Focus of v1 developers until remaining critical bugs are fixed
** Gaia changes that will go into B2G v1 updates would be made here
* Release
** Created after B2G v1 code drop
So basically, v1.0 changes would be landed on Master until 8/28, on Stabilization until code drop, and on Release until v1.0 is declared complete. v1.1 changes would be made on Stabilization after the first code drop. And v2 changes would be made on Master in the meantime.
Stability/security/UX fixes should be merged from Stabilization to Master on a regular basis to make sure we don't regress from v1 to v2.
-Alex
On Jul 27, 2012, at 2:28 PM, Tim Guan-tin Chien <timd...@mozilla.com> wrote:
> I am being asked by Dietrich to reply this thread.
>
> During an offine conversation of the same topic, we covered the gitflow and some of the minimal requirements for the stable branch (i.e. stable as in QA-verified stable). I think besides that we should have a definite set of requirements written on what we expect for the stable branch, e.g.,
>
> 1. Is the new branching scheme can be transparent to devs, or we can invent something what complete overwritten our current ops, e.g. pull req, etc?
> 2. Do we allow features to be "skip ahead" and be merged into stable first, or the stable can just follow the dev branch in a linear faction?
> 3. Do we have other requirement like being able to tag a release version?
>
> In the prefect world I would love to have a dedicate stable branch maintainer, which tests and merge every pull reqs *manually*, so we can keep working with the current Github flow.
>
> As of gitflow, if the benefit out-weight the disruption to the dev process (I think it does not work with pull requests, correct me if I am wrong), then it's a viable option.
>
>
* Master
** Focus of v1 developers until Stabilization branch created
** Becomes Gaia v2 after the underlying Gecko 17 moves off of m-c
* Stabilization
** Created after Gecko 17 moves off of m-c
** Focus of v1 developers until remaining critical bugs are fixed
** Gaia changes that will go into B2G v1 updates would be made here
* Release
** Created after B2G v1 code drop
So basically, v1.0 changes would be landed on Master until 8/28, on Stabilization until code drop, and on Release until v1.0 is declared complete. v1.1 changes would be made on Stabilization after the first code drop. And v2 changes would be made on Master in the meantime.
Stability/security/UX fixes should be merged from Stabilization to Master on a regular basis to make sure we don't regress from v1 to v2.
-Alex
On Jul 27, 2012, at 2:28 PM, Tim Guan-tin Chien <timd...@mozilla.com> wrote:
> I am being asked by Dietrich to reply this thread.
>
> During an offine conversation of the same topic, we covered the gitflow and some of the minimal requirements for the stable branch (i.e. stable as in QA-verified stable). I think besides that we should have a definite set of requirements written on what we expect for the stable branch, e.g.,
>
> 1. Is the new branching scheme can be transparent to devs, or we can invent something what complete overwritten our current ops, e.g. pull req, etc?
> 2. Do we allow features to be "skip ahead" and be merged into stable first, or the stable can just follow the dev branch in a linear faction?
> 3. Do we have other requirement like being able to tag a release version?
>
> In the prefect world I would love to have a dedicate stable branch maintainer, which tests and merge every pull reqs *manually*, so we can keep working with the current Github flow.
>
> As of gitflow, if the benefit out-weight the disruption to the dev process (I think it does not work with pull requests, correct me if I am wrong), then it's a viable option.
>
>
> Tim
>
> On 7/26/12 1:01 PM, Jeff Griffiths wrote:
>> Hi gang!
>>
>> ** DISCLAIMER ** No, I'm not proposing you switch to CVS. Nor do I suggest that, at the current rate of development on basecamp goals, we change anyone's working process.
>>
>> I would like to provide some feedback that I think the gaia project could be more accessible to outsiders / potential contributors if you eventually adopted a git-flow style branch strategy for development. I think we should consider moving to something like this *after* basecamp.
>>
>> Currently, gaia is a river of changes, with 1 branch ( master ) and only 2 tags, the most recent from a month ago.
>>
>> Once basecamp is done, you should seriously consider something like how jetpack uses github, with master, stabilization and release branches:
>>
>> https://wiki.mozilla.org/Jetpack/Development_Process#Branches
>>
>> Additionally, all SDK releases are given a tag. Currently there are no real releases, but as you hit milestones or QA has a change level that passes tests, creating tags and reporting back to the list would be really appreciated.
>>
>> Finally, if I look at the history of changes in gaia I see many people merging from the master branch of their own Github fork. This is not ideal, and in Jetpack we tend to instead create specific feature branches to implement something or fix a bug. One positive aspect of this is that, if you name your feature branch in an explanatory way, it is much easier for people to browser the master branch history list and get a sense of what is going on.
>>
>> $0.02, Jeff
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>
>
> On 7/26/12 1:01 PM, Jeff Griffiths wrote:
>> Hi gang!
>>
>> ** DISCLAIMER ** No, I'm not proposing you switch to CVS. Nor do I suggest that, at the current rate of development on basecamp goals, we change anyone's working process.
>>
>> I would like to provide some feedback that I think the gaia project could be more accessible to outsiders / potential contributors if you eventually adopted a git-flow style branch strategy for development. I think we should consider moving to something like this *after* basecamp.
>>
>> Currently, gaia is a river of changes, with 1 branch ( master ) and only 2 tags, the most recent from a month ago.
>>
>> Once basecamp is done, you should seriously consider something like how jetpack uses github, with master, stabilization and release branches:
>>
>> https://wiki.mozilla.org/Jetpack/Development_Process#Branches
>>
>> Additionally, all SDK releases are given a tag. Currently there are no real releases, but as you hit milestones or QA has a change level that passes tests, creating tags and reporting back to the list would be really appreciated.
>>
>> Finally, if I look at the history of changes in gaia I see many people merging from the master branch of their own Github fork. This is not ideal, and in Jetpack we tend to instead create specific feature branches to implement something or fix a bug. One positive aspect of this is that, if you name your feature branch in an explanatory way, it is much easier for people to browser the master branch history list and get a sense of what is going on.
>>
>> $0.02, Jeff
>> _______________________________________________
>> dev-gaia mailing list
>> dev-...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>
> --
> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
>
> Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
>
0 new messages