Please fork stackforge repo to your account first and use the forked version
On Wed, Dec 11, 2013 at 4:57 PM, Bogdan Dobrelya <[email protected]>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 > <[email protected]>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 >> <[email protected]>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 <[email protected] >>> > 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 >>>> 38, Lenina ave. >>>> Kharkov, Ukraine >>>> www.mirantis.com >>>> www.mirantis.ru >>>> [email protected] >>>> >>>> >>>> >>>> -- >>>> Mailing list: https://launchpad.net/~fuel-dev >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~fuel-dev >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Researcher TechLead, Mirantis, Inc. >>> +38 (066) 051 07 53 >>> Skype bogdando_at_yahoo.com >>> 38, Lenina ave. >>> Kharkov, [email protected] >>> >>> >> >> >> -- >> Best regards, >> Bogdan Dobrelya, >> Researcher TechLead, Mirantis, Inc. >> +38 (066) 051 07 53 >> Skype bogdando_at_yahoo.com >> 38, Lenina ave. >> Kharkov, [email protected] >> >> > > > -- > Best regards, > Bogdan Dobrelya, > Researcher TechLead, Mirantis, Inc. > +38 (066) 051 07 53 > Skype bogdando_at_yahoo.com > 38, Lenina ave. > Kharkov, [email protected] > > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-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 [email protected]
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
