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
