Re: Customize ReviewBoard instance
This give some point of view :) Great thanks!
For now I have separate branch for each of my issue. Each branch is
lead from reviewboard master and contain only changes for each issue.
All of issues is merged to "intel" branch. I made some smart command
"intelit" which make greate use from git archive and propagate changes
in intel branch to virtualenv system and of course working reviewboard
copies as well.
I think when I will try use hooks branch or 1.6 I just checkout this
branch and merge all my issues to it. This will be probably easier :)
Thank You for Your time and publishing extra branches :) Today is a
big day - first implementing of ReviewBoard in our team :] So. I have
a grate hope all will go fine, my managers will be charm of this tool
and I get more tasks to help with development :]
On Apr 6, 8:03 am, Christian Hammond wrote:
> The beauty of Git is that you don't have to only base your changes on one
> branch. You can easily merge from multiple branches into your branch.
>
> What I'd recommend is to have a branch, for example "vendor", which is what
> your internal builds will be from.
>
> Then, each feature would go its own feature branch, for the purpose of
> making it easy to port certain things down the road, and maybe to even
> provide patches.
>
> "vendor" would merge from each branch when you're ready to do a new build.
> This is done by:
>
> $ git checkout vendor
> $ git merge my-feature
>
> You may have to resolve some merge conflicts, but then you'd have that
> feature in your branch. Periodically, you'd also merge from "master". If you
> want our extensions branch for instance, you'd merge from "extensions". If
> you want it to incorporate the 1.6 changes before they land to "master", you
> might merge from "release-1.6".
>
> The key point is that your branch for your own builds can merge from any
> number of branches, any time those branches merge, and those branches can
> merge from what they need to ("master" for example).
>
> You probably shouldn't ever commit to any of the upstream branches, though,
> as those should be reserved for changes coming from our GitHub repository.
> If you've been doing this and want to try the "vendor" approach, it won't be
> hard to switch over. Just rename your branch:
>
> $ git branch -M master vendor
> $ git checkout -b master origin/master
>
> That'll rename "master" to "vendor" and then create a new "master" branch.
>
> Hope that helps?
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.reviewboard.org
> VMware, Inc. -http://www.vmware.com
>
> On Mon, Apr 5, 2010 at 9:21 PM, Jan Koprowski wrote:
>
> > Thank You very much for answer :)
>
> > To the POST hooks :) or URL hooks. IMHO there are many ways to pass
> > arguments to hook like this. I think this will be good to have
> > something like "method" argument in hook calling which could be
> > similar to jquery.ajax argument. Which means when we call hook we
> > could determine how arguments hook will be send:
> > POST, GET or JSON or something else. My little suggestion :)
>
> > I belive this mechanism will be good enough to customize reviewboard
> > external integrations :]
>
> > About branches. Now I see one problem.
> > I'am providing some features to ReviewBoard (more fixes for ClearCase
> > then features but features will be there also) and I post reviews for
> > it. But there are some features which have sens only for my company,
> > and I just keep them in another branch without posting it public.
> > Which branch I should use? Now I use default one from github. Now I
> > see there is another branches where some of features which I need
> > (maybe which I implement by my self) are present :) I don't want
> > implement features which is available now. No I'am a little bit
> > confused which branch I should use to have stable ReviewBoard, may
> > post reviews and write patches and get unpublic features not provide
> > in ReviewBoard yet? Is there any branch like this? :D
>
> > Thank You for Your answers :)
>
> > On Apr 6, 5:14 am, Christian Hammond wrote:
> > > Hi,
>
> > > We have a few things planned and in development for the level of
> > > customization you guys want.
>
> > > 1) We have some things that will be in the 1.6 release (it's actually
> > > written today, just isn't scheduled for 1.5) for WebHooks, which allow
> > for
> > > calling external scripts (technically, doing an HTTP POST to a URL) on
> > > various events. I can't remember exactly if Submitted or Discarded hooks
> > > into this, but it could be made to if it doesn't.
>
> > > I'll probably create an early 1.6 branch for development before long
> > which
> > > will have this. You could make use of this branch if you want to use this
> > > sooner, though you'd have to maintain your own packages internally.
>
> > > The way it works is that you have a script hosted on a web server
> > somewhere.
> > > It could be PHP, Python, whatever. It responds to an HTTP PO
Re: Customize ReviewBoard instance
The beauty of Git is that you don't have to only base your changes on one
branch. You can easily merge from multiple branches into your branch.
What I'd recommend is to have a branch, for example "vendor", which is what
your internal builds will be from.
Then, each feature would go its own feature branch, for the purpose of
making it easy to port certain things down the road, and maybe to even
provide patches.
"vendor" would merge from each branch when you're ready to do a new build.
This is done by:
$ git checkout vendor
$ git merge my-feature
You may have to resolve some merge conflicts, but then you'd have that
feature in your branch. Periodically, you'd also merge from "master". If you
want our extensions branch for instance, you'd merge from "extensions". If
you want it to incorporate the 1.6 changes before they land to "master", you
might merge from "release-1.6".
The key point is that your branch for your own builds can merge from any
number of branches, any time those branches merge, and those branches can
merge from what they need to ("master" for example).
You probably shouldn't ever commit to any of the upstream branches, though,
as those should be reserved for changes coming from our GitHub repository.
If you've been doing this and want to try the "vendor" approach, it won't be
hard to switch over. Just rename your branch:
$ git branch -M master vendor
$ git checkout -b master origin/master
That'll rename "master" to "vendor" and then create a new "master" branch.
Hope that helps?
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Mon, Apr 5, 2010 at 9:21 PM, Jan Koprowski wrote:
> Thank You very much for answer :)
>
> To the POST hooks :) or URL hooks. IMHO there are many ways to pass
> arguments to hook like this. I think this will be good to have
> something like "method" argument in hook calling which could be
> similar to jquery.ajax argument. Which means when we call hook we
> could determine how arguments hook will be send:
> POST, GET or JSON or something else. My little suggestion :)
>
> I belive this mechanism will be good enough to customize reviewboard
> external integrations :]
>
> About branches. Now I see one problem.
> I'am providing some features to ReviewBoard (more fixes for ClearCase
> then features but features will be there also) and I post reviews for
> it. But there are some features which have sens only for my company,
> and I just keep them in another branch without posting it public.
> Which branch I should use? Now I use default one from github. Now I
> see there is another branches where some of features which I need
> (maybe which I implement by my self) are present :) I don't want
> implement features which is available now. No I'am a little bit
> confused which branch I should use to have stable ReviewBoard, may
> post reviews and write patches and get unpublic features not provide
> in ReviewBoard yet? Is there any branch like this? :D
>
> Thank You for Your answers :)
>
> On Apr 6, 5:14 am, Christian Hammond wrote:
> > Hi,
> >
> > We have a few things planned and in development for the level of
> > customization you guys want.
> >
> > 1) We have some things that will be in the 1.6 release (it's actually
> > written today, just isn't scheduled for 1.5) for WebHooks, which allow
> for
> > calling external scripts (technically, doing an HTTP POST to a URL) on
> > various events. I can't remember exactly if Submitted or Discarded hooks
> > into this, but it could be made to if it doesn't.
> >
> > I'll probably create an early 1.6 branch for development before long
> which
> > will have this. You could make use of this branch if you want to use this
> > sooner, though you'd have to maintain your own packages internally.
> >
> > The way it works is that you have a script hosted on a web server
> somewhere.
> > It could be PHP, Python, whatever. It responds to an HTTP POST and knows
> how
> > to take a certain payload and return certain information. You would then
> > reference this URL in the admin UI for different events.
> >
> > 2) It's quite possible we'll have some level of theme support (perhaps as
> a
> > Summer of Code project) for letting admins configure their own templates
> by
> > basically just overriding parts that they need. That's not happening for
> > 1.5, but maybe 1.6.
> >
> > 3) We're working on extensions support. There are branches for it today,
> but
> > it's nowhere near ready for production use. However, it will allow for
> more
> > advanced customization without modifying Review Board.
> >
> > As for the suggestions for changing how settings works, I'd actually
> rather
> > do nothing about this right now. I feel that while we'd get a lot of
> > flexibility, it would increase our support burden, and there's rarely a
> case
> > where this would need to be used anyway. The customizations you're
> > referencing will be there in a
Re: Customize ReviewBoard instance
Thank You very much for answer :) To the POST hooks :) or URL hooks. IMHO there are many ways to pass arguments to hook like this. I think this will be good to have something like "method" argument in hook calling which could be similar to jquery.ajax argument. Which means when we call hook we could determine how arguments hook will be send: POST, GET or JSON or something else. My little suggestion :) I belive this mechanism will be good enough to customize reviewboard external integrations :] About branches. Now I see one problem. I'am providing some features to ReviewBoard (more fixes for ClearCase then features but features will be there also) and I post reviews for it. But there are some features which have sens only for my company, and I just keep them in another branch without posting it public. Which branch I should use? Now I use default one from github. Now I see there is another branches where some of features which I need (maybe which I implement by my self) are present :) I don't want implement features which is available now. No I'am a little bit confused which branch I should use to have stable ReviewBoard, may post reviews and write patches and get unpublic features not provide in ReviewBoard yet? Is there any branch like this? :D Thank You for Your answers :) On Apr 6, 5:14 am, Christian Hammond wrote: > Hi, > > We have a few things planned and in development for the level of > customization you guys want. > > 1) We have some things that will be in the 1.6 release (it's actually > written today, just isn't scheduled for 1.5) for WebHooks, which allow for > calling external scripts (technically, doing an HTTP POST to a URL) on > various events. I can't remember exactly if Submitted or Discarded hooks > into this, but it could be made to if it doesn't. > > I'll probably create an early 1.6 branch for development before long which > will have this. You could make use of this branch if you want to use this > sooner, though you'd have to maintain your own packages internally. > > The way it works is that you have a script hosted on a web server somewhere. > It could be PHP, Python, whatever. It responds to an HTTP POST and knows how > to take a certain payload and return certain information. You would then > reference this URL in the admin UI for different events. > > 2) It's quite possible we'll have some level of theme support (perhaps as a > Summer of Code project) for letting admins configure their own templates by > basically just overriding parts that they need. That's not happening for > 1.5, but maybe 1.6. > > 3) We're working on extensions support. There are branches for it today, but > it's nowhere near ready for production use. However, it will allow for more > advanced customization without modifying Review Board. > > As for the suggestions for changing how settings works, I'd actually rather > do nothing about this right now. I feel that while we'd get a lot of > flexibility, it would increase our support burden, and there's rarely a case > where this would need to be used anyway. The customizations you're > referencing will be there in a much easier way in future releases, and if > you really need to specify your own TEMPLATE_DIRS, you can define it without > inheriting and just shove the old values in there. Much easier than a whole > new import mechanism :) > > Christian > > -- > Christian Hammond - chip...@chipx86.com > Review Board -http://www.reviewboard.org > VMware, Inc. -http://www.vmware.com > > On Sat, Apr 3, 2010 at 12:11 AM, Jan Koprowski wrote: > > > > > Hi! > > > I'am start using reviewboard and need some customizations: > > 1) I need hooks run after Submited or Discarded > > 2) Add custom footer, change logo, title > > > First thing is a way to customize some layoutes. I know how I can do > > that now: > > * copy templates from reviewboard to my folder > > * set in my settings_local TEMPLATE_DIRS to my directory and > > oryginal directory (for example symlink somewhere inside my instance > > created by rb-site) > > but this option have one limitation. Upgrading my ReviewBoard need > > to check is modified by me templates doesn't change... hmmm. > > > My idea is made some modifications in settings_local which allow not > > only overwrite existing settings but modify it. > > My first try looks like: > > settings_local.py > > --- > > import reviewboard.settings > > TEMPLATE_DIRS = ( > > r'/my/custom/dir' > > ) + reviewboard.settings.TEMPLATE_DIRS > > --- > > but this doesn't have effect. I guess problem in import recursion. > > settings_local import settings and settings import settings_local. > > Python make it and modify TEMPLATE_DIRS but Django doesn't catch > > this. > > > So the second shoot is change some ways. > > * settings.py > settings_default.py > > * settings_local.py > > --- > > from reviewboard
Re: Customize ReviewBoard instance
Hi,
We have a few things planned and in development for the level of
customization you guys want.
1) We have some things that will be in the 1.6 release (it's actually
written today, just isn't scheduled for 1.5) for WebHooks, which allow for
calling external scripts (technically, doing an HTTP POST to a URL) on
various events. I can't remember exactly if Submitted or Discarded hooks
into this, but it could be made to if it doesn't.
I'll probably create an early 1.6 branch for development before long which
will have this. You could make use of this branch if you want to use this
sooner, though you'd have to maintain your own packages internally.
The way it works is that you have a script hosted on a web server somewhere.
It could be PHP, Python, whatever. It responds to an HTTP POST and knows how
to take a certain payload and return certain information. You would then
reference this URL in the admin UI for different events.
2) It's quite possible we'll have some level of theme support (perhaps as a
Summer of Code project) for letting admins configure their own templates by
basically just overriding parts that they need. That's not happening for
1.5, but maybe 1.6.
3) We're working on extensions support. There are branches for it today, but
it's nowhere near ready for production use. However, it will allow for more
advanced customization without modifying Review Board.
As for the suggestions for changing how settings works, I'd actually rather
do nothing about this right now. I feel that while we'd get a lot of
flexibility, it would increase our support burden, and there's rarely a case
where this would need to be used anyway. The customizations you're
referencing will be there in a much easier way in future releases, and if
you really need to specify your own TEMPLATE_DIRS, you can define it without
inheriting and just shove the old values in there. Much easier than a whole
new import mechanism :)
Christian
--
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Sat, Apr 3, 2010 at 12:11 AM, Jan Koprowski wrote:
> Hi!
>
> I'am start using reviewboard and need some customizations:
> 1) I need hooks run after Submited or Discarded
> 2) Add custom footer, change logo, title
>
> First thing is a way to customize some layoutes. I know how I can do
> that now:
> * copy templates from reviewboard to my folder
> * set in my settings_local TEMPLATE_DIRS to my directory and
> oryginal directory (for example symlink somewhere inside my instance
> created by rb-site)
> but this option have one limitation. Upgrading my ReviewBoard need
> to check is modified by me templates doesn't change... hmmm.
>
> My idea is made some modifications in settings_local which allow not
> only overwrite existing settings but modify it.
> My first try looks like:
> settings_local.py
> ---
> import reviewboard.settings
> TEMPLATE_DIRS = (
> r'/my/custom/dir'
> ) + reviewboard.settings.TEMPLATE_DIRS
> ---
> but this doesn't have effect. I guess problem in import recursion.
> settings_local import settings and settings import settings_local.
> Python make it and modify TEMPLATE_DIRS but Django doesn't catch
> this.
>
> So the second shoot is change some ways.
> * settings.py > settings_default.py
> * settings_local.py
> ---
> from reviewboard.settings_default import *
> [...
> ...
> ...]
> some custom modifications
> * settings.py
> ---
> try:
> from settings_local import *
> except:
> from default import *
>
> some neccessery checks and customizations
>
> This is the way (i think) good enough which provide some features
> 1) We have our default values
> 2) User can change anything in settings_local. Overwriting is only
> one option. There can be also modification! They can add some custom
> template directory before templates from reviewboard (and create their
> own templates) or not :] Second grate benefit is way to add some
> custom plugins (MIDDLEWARE_CLASSES or APPS) which allow to do many
> greate things.
>
> Unfortunetly I don't know how this looks with merging with Django
> source tree so :] there is second option (IMHO a little bit worse then
> first one)
> At the end add loop which check settings_local under MYRB_PRE_ and
> MYRB_POST_ prefixed variables and add/append values to existing once.
> for variable filter(lambda s: s.startswith('MYRB_PRE_'),
> dir(settings_local))
> [...]
> globals()[varname] = variable + globals()[varname]
> for variable filter(lambda s: s.startswith('MYRB_POST_'),
> dir(settings_local))
> [...]
> globals()[varname] = globals()[varname] + variable
>
> IMHO first option is much more clear and flexible and bettter
> designed then first one. What do You think? I can prepare review for
