On Wed, Dec 11, 2013 at 5:37 PM, Miroslav Anashkin
<manashkin@xxxxxxxxxxxx <mailto:manashkin@xxxxxxxxxxxx>> wrote:
And do not use push, use `git review` without parameters
On Wed, Dec 11, 2013 at 5:36 PM, Miroslav Anashkin
<manashkin@xxxxxxxxxxxx <mailto:manashkin@xxxxxxxxxxxx>> wrote:
Please fork stackforge repo to your account first and use the
forked version
On Wed, Dec 11, 2013 at 4:57 PM, Bogdan Dobrelya
<bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>> wrote:
On 12/11/2013 01:35 PM, Oleg Gelbukh wrote:
Looks like fuel.config already have this configuration
actually:
https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/gerrit/acls/stackforge/fuel.config#n5
Did you check if you actually can create a branch?
Yes, I've tried git push -u origin foo_branch and I've got
ERROR: Permission to stackforge/fuel-web(library).git
denied to bogdando.
--
Best regards,
Oleg Gelbukh
On Wed, Dec 11, 2013 at 2:36 PM, Bogdan Dobrelya
<bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>>
wrote:
On 12/11/2013 11:52 AM, Oleg Gelbukh wrote:
Bogdan,
In OpenStack CI, that is configured in
openstack-ci/config repository. You have to add
certain lines to gerrit access lists configuration
(modules/openstack_project/files/gerrit/acls/stackforge/fuel.config)
for your project there:
[access refs/*]
create = group <your-project-name>-core
or something like that. Please, ask at
openstack-infra ML or #openstack-infra for more
precise advice.
Looks like the openstack-ci/config repo is about
projects management, not its WIP branches - the only
reference for branch named "feature/ec" (mentioned in
http://lists.openstack.org/pipermail/openstack-dev/2013-July/012102.html)
I've found is:
./modules/gerritbot/files/gerritbot_channel_config.yaml:
openstack-swift:
events:
- patchset-created
- change-merged
- x-vrif-minus-2
projects:
- openstack/swift
- openstack/swift-bench
- openstack/python-swiftclient
branches:
- master
- feature/ec
So, it is still unclear how to create new branches
for review...
I will consult with #openstack-infra anyway, thank you.
I believe we should have this question clearly
elaborated for our R&D teams.
--
Best regards,
Oleg Gelbukh
On Wed, Dec 11, 2013 at 1:42 PM, Bogdan Dobrelya
<bdobrelia@xxxxxxxxxxxx
<mailto:bdobrelia@xxxxxxxxxxxx>> wrote:
On 12/11/2013 11:06 AM, Oleg Gelbukh wrote:
Bogdan,
You might be interested in the approach taken
by Swift team for long-term development effort
of erasure coding storage option:
http://lists.openstack.org/pipermail/openstack-dev/2013-July/012102.html
Thank you, the approach is good indeed. Do we
have a rights or work-flow for creating WIP
branches of our main repos?
--
Best regards,
Oleg Gelbukh
On Wed, Dec 11, 2013 at 1:02 PM, Bogdan
Dobrelya <bdobrelia@xxxxxxxxxxxx
<mailto:bdobrelia@xxxxxxxxxxxx>> wrote:
Hello.
On 12/10/2013 09:14 PM, Dmitry Borodaenko
wrote:
All,
We still have a few pain points left in
our development process that I
think are easy to fix with a bunch of
simple rules. I think releasing
4.0 will be less painful if we try to
address these.
1. Branch management for maintenance
releases
We already had this discussion during
3.2.1 release cycle, and agreed
to follow the approach that is in line
with what OpenStack and most
other free software projects are
following. Still, I think we should
do better at actually following the
process we agreed to.
To see how good we were at following it
for 3.2.1, open two terminal
windows and run:
git whatchanged 3.2..3.2-fixes
git whatchanged 3.2..master
and for each commit in 3.2-fixes, try
to find a matching fix in
master. Last time I checked there were
still many cases where bugfixes
were merged to 3.2-fixes before (or
even without) merging them to
master. Did anyone actually check that
we're not missing any important
fixes from 3.2.1 in 4.0?
We should create a new stable/4.0
branch as soon as 4.0 code freeze is
announced (ideally, the announcement
itself should direct committers
to the new branch). Reviewers should
REJECT all commits to stable/4.0
that have not been merged into master,
unless a justification is
provided in the COMMIT MESSAGE.
Can Jenkins help us by -1 such patches?
I.e. Jenkins could put -1 to any patch
targeted for non-master, unless its commits
were found in master.
2. Management and code review of
feature development branches
Yet another thing that everyone seems
to agree on is that huge
long-lived feature branches with many
commits and thousands of lines
worth of changes are evil and
dangerous. Luckily, the move to Gerrit
will make it hard enough to maintain
and merge multi-commit branches,
and will push people towards committing
and merging changes in smaller
self-sufficient chunks.
That should we do for long running
researches, such as HA improvements
(started at 3.1, targeted to 4.1 only), or
torrent based provisioning?
Should we melt down hundreds of commits
into a single patch in WIP branch,
before submitting new feature to review?
A recent negative example is the
fuel-library pull request #911 that
has merged 104 duplicate commits from
ancient alternative history into
master, instead of simply rebasing a
single commit. The only way to
prevent something like this from
happening is to summarily reject
changes that are too large and/or
contain messy revision history.
Jenkins could come to help here as well.
E.g. -1, if any commit in PR are
already present in target branch's history.
The other side of the same problem is
holding back small reasonable
changes for too long, placing
unnecessary burden on authors to keep
rebasing their change on top of other
changes that got merged earlier.
For example, my own fuel-docs pull
request #67 sat unreviewed for a
week only to be obsoleted by the move
of the repo to StackForge (after
being obsoleted couple more times by
changes that were merged ahead of
it). I suspect most other developers
had similar experiences. On top
of obvious frustration, holding a
change back tempts the author to
keep piling changes onto the same
request instead of creating a new
review request on top of updated master
for their next set of changes.
To use the same example, most of the
third commit on #67 should really
have been a separate pull request.
The fix is once again rather obvious:
when going through reviews,
start with fixes for critical bugs,
then go through remaining reviews
starting with the least recently
updated ones. Don't merge a review
request if there's an older review
request that can also be merged.
I'm using this link to see all our
outstanding review requests:
https://review.openstack.org/#/q/status:open+project:^stackforge/fuel-.*,n,z
Right now I see that there are review
requests that have +1 from CI
and from reviewers (meaning they can be
merged) sitting unchanged
since Nov 25, and a few unreviewed
requests going as far back as Nov
3. We shouldn't have a request sit
untouched by an approver for more
than a week, let alone a month. If
there's a any reason you don't want
to merge it, give it -1 and explain.
Otherwise, there's no reason not
to give it +2. If you have time to
review and merge a newer request,
you have time for that older one, too.
3. Bugs triage
Moving our bug tracking to public
launchpad was an important step
towards opening up our development
process, now we should improve
visibility of our bugs triage and
release management processes. In
addition to announcing target release
dates, we should also have well
defined release criteria (for example,
no critical bugs affecting the
upcoming release, no more than 5 bugs
with high importantce, etc.),
and documented rules on how to set
importance of a bug. We don't have
to be rigid and beaurocratic about it,
but having documented criteria
will help all participants of the
process prioritize their own work
and understand how it fits into the
state of the whole project. It
will also help avoid situations like
missing an important bugfix in a
release, by forcing us to review
priorities of all open bugs before
announcing a release.
--
Best regards,
Bogdan Dobrelya,
Researcher TechLead, Mirantis, Inc.
+38 (066) 051 07 53
Skype bogdando_at_yahoo.com
<http://bogdando_at_yahoo.com>
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com>
www.mirantis.ru <http://www.mirantis.ru>
bdobrelia@xxxxxxxxxxxx
<mailto:bdobrelia@xxxxxxxxxxxx>
--
Mailing list:
https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe :
https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
More help :
https://help.launchpad.net/ListHelp
--
Best regards,
Bogdan Dobrelya,
Researcher TechLead, Mirantis, Inc.
+38 (066) 051 07 53
Skypebogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com>
www.mirantis.ru <http://www.mirantis.ru>
bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>
--
Best regards,
Bogdan Dobrelya,
Researcher TechLead, Mirantis, Inc.
+38 (066) 051 07 53
Skypebogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com>
www.mirantis.ru <http://www.mirantis.ru>
bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>
--
Best regards,
Bogdan Dobrelya,
Researcher TechLead, Mirantis, Inc.
+38 (066) 051 07 53
Skypebogdando_at_yahoo.com <http://bogdando_at_yahoo.com>
38, Lenina ave.
Kharkov, Ukraine
www.mirantis.com <http://www.mirantis.com>
www.mirantis.ru <http://www.mirantis.ru>
bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>
--
Mailing list: https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
More help : https://help.launchpad.net/ListHelp
--
//Kind Regards///
Miroslav Anashkin
///L2 support engineer////,///
///Mirantis Inc.///
///+7(495)640-4944 (office receptionist)///
///+1(650)587-5200 (office receptionist, call from US)///
///35b, Bld. 3, Vorontsovskaya St.///
///Moscow////, Russia, 109147.//
www.mirantis.com <http://www.mirantis.com>
manashkin@xxxxxxxxxxxx <mailto:manashkin@xxxxxxxxxxxx>
////
--
//Kind Regards///
Miroslav Anashkin
///L2 support engineer////,///
///Mirantis Inc.///
///+7(495)640-4944 (office receptionist)///
///+1(650)587-5200 (office receptionist, call from US)///
///35b, Bld. 3, Vorontsovskaya St.///
///Moscow////, Russia, 109147.//
www.mirantis.com <http://www.mirantis.com>
manashkin@xxxxxxxxxxxx <mailto:manashkin@xxxxxxxxxxxx>
////
--
Mailing list: https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
Post to : fuel-dev@xxxxxxxxxxxxxxxxxxx
<mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~fuel-dev
<https://launchpad.net/%7Efuel-dev>
More help : https://help.launchpad.net/ListHelp
--
Yours Faithfully,
Vladimir Kuklin,
Senior Deployment Engineer,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru <http://www.mirantis.ru/>
vkuklin@xxxxxxxxxxxx <mailto:nveschikova@xxxxxxxxxxxx>
