Hello Franz,
Thank you for your detailed answer!
Locally, I work with branches. I just thought about if I need a branch on
the remote Saros repository.
> You only have to decide whether you want your changes to be part of the
Saros project, or whether
> they are just for playing around/local user tests/the like.
Actually, I AM playing around with the feature, since there will be some
user tests. But the feature can be configured off, so that none will be
affected by a feature still being under development.
> If you want continuous feedback, the effective changes would be too big
for one patch, or the
> intermediate stages of your iterations do (potentially) provide benefits
for Saros users, and you want
> to be rather independent of the ongoing development, it is probably much
wiser to use a separate
> branch.
I want continuous feedback. I think my intermediate stages could be
interesting for other Saros users and I can get feedback, ideas or help if
needed. Therefore, I think I take the option of an independent branch :)
What about Change #1515? Shall I create a new change on the separate branch
for it (and then abandon #1515 from master)? We discussed about it after
the meeting, but it is still not clear for me and I had to leave the Saros
working room.
Best Regards,
Damla
2014-05-14 14:31 GMT+02:00 Zieris, Franz <franz.zie...@fu-berlin.de>:
> Hi Damla,
>
>
>
> > What is the convention in this group with features that can be adapted
> again and again?
>
>
>
> All of the “branching rules” you are referring to stem from the pre-Git
> era, i.e. the dark age of SVN.
>
> Since then, no big feature development has taken place, since the main
> effort was directed towards repaying technical debt.
>
> Hence, there is no “lived” convention.
>
>
>
> Anyway, we can shorten this discussion, because using Git, you can work on
> a branch if you want to work on a branch.
>
> You only have to decide whether you want your changes to be part of the
> Saros project, or whether they are just for playing around/local user
> tests/the like.
>
>
>
> You may create as many local branches as you need to structure your work.
>
> If you don’t need feedback on your work, these branches remain local, and
> as long as the effect on the Saros project is small, it is completely fine
> to create one final commit for Gerrit (one that contains all effective
> changes) after your iterations are complete.
>
> If you want continuous feedback, the effective changes would be too big
> for one patch, or the intermediate stages of your iterations do
> (potentially) provide benefits for Saros users, and you want to be rather
> independent of the ongoing development, it is probably much wiser to use a
> separate branch.
>
>
>
> If you want, I can create a branch in Gerrit.
>
> This one would be in the “development” namespace (e.g.
> “development/actionAwareness”), patches then need to be pushed to
> “refs/for/development/actionAwareness” (or
> “refs/drafts/development/actionAwareness”), and Jenkins will automatically
> build and test any new patches.
>
> Please note that the STF tests will only be performed on the master branch.
>
> Finally, you are the one who is responsible to merge your branch back into
> the master (and resolve all conflicts) once your work is finished –
> otherwise your work won’t be part of the Saros project.
>
>
>
> Best Regards,
>
> Franz
>
>
>
> *From:* Damla Durmaz [mailto:ddurma...@gmail.com]
> *Sent:* Wednesday, May 14, 2014 1:39 PM
> *To:* dpp-devel@lists.sourceforge.net
> *Subject:* [DPP-Devel] New branch or master branch for user tested
> feature development
>
>
>
> Hello Saros-devs,
>
>
>
> In my master thesis I'm working (as some already know) on the feature to
> display action awareness information, for example if the dialog was opened,
> which view was activated, what was refactort etc. The first attempts of
> this are already in change in 1515 [1] .
>
>
>
> Currently, this feature is configurable, it can be managed in the
> "saros.properties" file, since it is still under development. Now I want to
> extend this implementation through usability-tests, thus work in the user's
> feedback or adapting already existing code. This would mean that already
> existing changes in Gerrit, which are/were being reviewed (or merged), must
> permanently be adapted/extended.
>
>
>
> In [2], it says that (as expected) the master-branch ist for
> feature-development, and no matter how often I adapt my feature to user
> feedback, it is still a feature development. But in [3], it is explained
> that for "larger development efforts (e.g. a new feature, large-scale
> re-engineering)" a new branch can be created.
>
>
>
> My question is, if it would make sense to create a new branch in my case.
> What is the convention in this group with features that can be adapted
> again and again? Does creating a new branch makes more sense in my case?
>
>
>
> Kindly Regards,
>
>
>
> Damla Durmaz
>
>
>
> [1] http://saros-build.imp.fu-berlin.de/gerrit/#/c/1515/
>
> [2] http://www.saros-project.org/ReleaseProcess/#How_to_merge
>
> [3] http://www.saros-project.org/contribution#developing-in-a-branch
>
>
2014-05-14 14:31 GMT+02:00 Zieris, Franz <franz.zie...@fu-berlin.de>:
> Hi Damla,
>
>
>
> > What is the convention in this group with features that can be adapted
> again and again?
>
>
>
> All of the “branching rules” you are referring to stem from the pre-Git
> era, i.e. the dark age of SVN.
>
> Since then, no big feature development has taken place, since the main
> effort was directed towards repaying technical debt.
>
> Hence, there is no “lived” convention.
>
>
>
> Anyway, we can shorten this discussion, because using Git, you can work on
> a branch if you want to work on a branch.
>
> You only have to decide whether you want your changes to be part of the
> Saros project, or whether they are just for playing around/local user
> tests/the like.
>
>
>
> You may create as many local branches as you need to structure your work.
>
> If you don’t need feedback on your work, these branches remain local, and
> as long as the effect on the Saros project is small, it is completely fine
> to create one final commit for Gerrit (one that contains all effective
> changes) after your iterations are complete.
>
> If you want continuous feedback, the effective changes would be too big
> for one patch, or the intermediate stages of your iterations do
> (potentially) provide benefits for Saros users, and you want to be rather
> independent of the ongoing development, it is probably much wiser to use a
> separate branch.
>
>
>
> If you want, I can create a branch in Gerrit.
>
> This one would be in the “development” namespace (e.g.
> “development/actionAwareness”), patches then need to be pushed to
> “refs/for/development/actionAwareness” (or
> “refs/drafts/development/actionAwareness”), and Jenkins will automatically
> build and test any new patches.
>
> Please note that the STF tests will only be performed on the master branch.
>
> Finally, you are the one who is responsible to merge your branch back into
> the master (and resolve all conflicts) once your work is finished –
> otherwise your work won’t be part of the Saros project.
>
>
>
> Best Regards,
>
> Franz
>
>
>
> *From:* Damla Durmaz [mailto:ddurma...@gmail.com]
> *Sent:* Wednesday, May 14, 2014 1:39 PM
> *To:* dpp-devel@lists.sourceforge.net
> *Subject:* [DPP-Devel] New branch or master branch for user tested
> feature development
>
>
>
> Hello Saros-devs,
>
>
>
> In my master thesis I'm working (as some already know) on the feature to
> display action awareness information, for example if the dialog was opened,
> which view was activated, what was refactort etc. The first attempts of
> this are already in change in 1515 [1] .
>
>
>
> Currently, this feature is configurable, it can be managed in the
> "saros.properties" file, since it is still under development. Now I want to
> extend this implementation through usability-tests, thus work in the user's
> feedback or adapting already existing code. This would mean that already
> existing changes in Gerrit, which are/were being reviewed (or merged), must
> permanently be adapted/extended.
>
>
>
> In [2], it says that (as expected) the master-branch ist for
> feature-development, and no matter how often I adapt my feature to user
> feedback, it is still a feature development. But in [3], it is explained
> that for "larger development efforts (e.g. a new feature, large-scale
> re-engineering)" a new branch can be created.
>
>
>
> My question is, if it would make sense to create a new branch in my case.
> What is the convention in this group with features that can be adapted
> again and again? Does creating a new branch makes more sense in my case?
>
>
>
> Kindly Regards,
>
>
>
> Damla Durmaz
>
>
>
> [1] http://saros-build.imp.fu-berlin.de/gerrit/#/c/1515/
>
> [2] http://www.saros-project.org/ReleaseProcess/#How_to_merge
>
> [3] http://www.saros-project.org/contribution#developing-in-a-branch
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
