On 21/08/14 18:05, Matthew Booth wrote:
[snip]
> This seems to mean different things to different people. There's a list
> here which contains some criteria for new commits:
[snip]
> Any more of these?
There is also https://wiki.openstack.org/wiki/CodeReviewGuideline
iles:
https://bitbucket.org/thomaswaldmann/xstatic-jquery/src/tip/xstatic/__init__.py
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 28/08/14 12:41, Radomir Dopieralski wrote:
> On 27/08/14 16:31, Sean Dague wrote:
>
> [snip]
>
>> In python 2.7 (using pip) namespaces are a bolt on because of the way
>> importing modules works. And depending on how you install things in a
>> namespace will over
eezes the
implementation details of the tested unit, instead of testing its behavior.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ure, find has a "-delete" parameter that won't break horribly on
strange filenames.
find . -name '*.pyc' -delete
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
,
so I'm writing here. Please let me know if I should have done it
differently.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ooner.
Whether we need node.js for it or not is a technical issue -- as Imre
demonstrated here, this one can be solved without node.js, so there is
really nothing stopping us from adopting it.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
Open
n create a policy that will
make Horizon better in the long run.
Thank you,
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the Horizon documentation, so that other people won't make
a fool of them like I just did?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
x27;t use either, I'm not sure we want it.
I'm sure that pointers to resources specific for our use cases would
greatly help everyone make a decission.
Thanks,
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
has to be Tuskar-API, and I
really don't see any other option.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 12/12/13 11:49, Radomir Dopieralski wrote:
> On 11/12/13 13:33, Jiří Stránský wrote:
>
> [snip]
>
>> TL;DR: I believe that "As an infrastructure administrator, Anna wants a
>> CLI for managing the deployment providing the same fundamental features
>> as
"normal"
Horizon in Undercloud, and require the admins to specially configure the
users to see Tuskar. Instead, a preconfigured installation of Horizon
with Tuskar enabled seems much better.
--
Radomir Dopieralski
___
OpenStack-dev mailing lis
tions.
I hope that helps.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t any
warning. If anyone deserves punishment in such a situation, it's the
programmers who wrote the UI in such a way.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
y and his judgement about
what works better -- unless of course we are willing to learn all that
ourselves, which may take quite some time.
What is the point of having an expert, if we know better, after all?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 20/12/13 00:17, Jay Pipes wrote:
> On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:
>> On 14/12/13 16:51, Jay Pipes wrote:
>>
>> [snip]
>>
>>> Instead of focusing on locking issues -- which I agree are very
>>> important in the virtualized side of
lt
decision and limit our options. In the discussion I saw I didn't see
anything like that pointed out, but maybe it's just so obvious that
everybody takes it for granted and it's just me that can't see it. In
that case I will rest my case.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 20/12/13 13:04, Radomir Dopieralski wrote:
[snip]
I have just learned that tuskar-api stays, so my whole ranting is just a
waste of all our time. Sorry about that.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev
lly having a complete UI for deploying OpenStack.
I fail to see how leaving ourselves the ability to add locks when they
become needed, by keeping tuskar-api in place, conflicts with actually
having a complete UI for deploying OpenStack. Can you elaborate on that?
cluded libraries. Of course, the reviewers have to pay attention to
make sure that all the non-library code is added to the list, but we
don't really get new files that often.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@li
have settings, _ and everything from urlresolvers importable without
the need for the #noqa tag.
Of course every project can add their own names there, depending what
they need.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/01/14 16:18, Russell Bryant wrote:
> On 01/03/2014 10:10 AM, Radomir Dopieralski wrote:
>> I think that we can actually do a little bit better and remove many of
>> the #noqa tags without forfeiting automatic checking. I submitted a
>> patch: https://review.op
7;s dashboard in that case?
We recently added a way for dashboards to have (some) of their
configuration provided in separate files, maybe that would be
helpful for Murano?
The patch is https://review.openstack.org/#/c/56367/
We can add more settings that can be changed, we just h
We could also have Instance Category, Instance Kind, Instance Purpose,
Instance Assignment, Instance Genre, Instance Class...
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
in our projects.
>
> Meh, probably just habit and copy/paste behavior.
It's actually not just a habit, it's a requirement, and hacking has a
check for files with missing licenses.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
Ope
m, and putting them in Horizon
would make that impossible. It's a workaround, but it also makes it
impossible for apps other than the dashboard (like tuskar-ui) to inherit
from those less files. I think that if we had a solution for that for
SASS, that would be another strong advantage of
n the Heat
parameter list that we get from it as "NoEcho": "true", so we do have an
idea about which parts are sensitive.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ting everything, we need to ask
ourselves the question about system boundaries and about what we are
protecting from what. Otherwise we will end up with ridiculous things
like encrypting the passwords and storing the decryption key right in
the same place. In other words, this has to be designed.
On 20/02/14 11:46, Dougal Matthews wrote:
> On 20/02/14 10:36, Radomir Dopieralski wrote:
>> On 20/02/14 11:21, Dougal Matthews wrote:
>>> If we do store passwords however, I wonder if we are
>>> best to encrypt everything to be safe. The overhead shouldn't be t
On 20/02/14 12:02, Radomir Dopieralski wrote:
> On 20/02/14 11:46, Dougal Matthews wrote:
>> On 20/02/14 10:36, Radomir Dopieralski wrote:
>>> On 20/02/14 11:21, Dougal Matthews wrote:
>>>> If we do store passwords however, I wonder if we are
>>>>
On 20/02/14 14:10, Jiří Stránský wrote:
> On 20.2.2014 12:18, Radomir Dopieralski wrote:
>> Thinking about it some more, all the uses of the passwords come as a
>> result of an action initiated by the user either by tuskar-ui, or by
>> the tuskar command-line client. So maybe
On 20/02/14 15:00, Tomas Sedovic wrote:
> Are we even sure we need to store the passwords in the first place? All
> this encryption talk seems very premature to me.
How are you going to redeploy without them?
--
Radomir Dopieralski
___
OpenSta
On 20/02/14 15:57, Tomas Sedovic wrote:
> On 20/02/14 15:41, Radomir Dopieralski wrote:
>> On 20/02/14 15:00, Tomas Sedovic wrote:
>>
>>> Are we even sure we need to store the passwords in the first place? All
>>> this encryption talk seems very premature to me.
&g
On 21/02/14 10:38, Dougal Matthews wrote:
> On 21/02/14 09:24, Tomas Sedovic wrote:
>> On 20/02/14 16:24, Imre Farkas wrote:
>>> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:
>>>> On 20/02/14 15:41, Radomir Dopieralski wrote:
>>>>> On 20/02/14 15:00,
;t imagine such a situation.
Finally, when you need to save a whole lot of json outputs and need to
know where they come from, you traditionally put that information in the
file name, no?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenSt
ICFILES_DIRS.append(
('horizon/lib/jquery-ui/ui',
xstatic.main.XStatic(xstatic.pkg.jquery_ui).base_dir))
But in your Debian package, you can completely drop xstatic and just use
absolute paths to the filesystem explicitly.
--
Radomir Dopieralski
___
On 25/11/14 00:09, David Lyle wrote:
> I am pleased to nominate Thai Tran and Cindy Lu to horizon-core.
[...]
Thai Tran +1
Cindy Lu +1
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
h
ing that package and helping with its testing.
What do you think? Do you see any disastrous problems with this system?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ints to where Bower is configured to put the files.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 05/01/15 00:35, Richard Jones wrote:
> On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
> mailto:openst...@sheep.art.pl>> wrote:
>
> On 20/12/14 21:25, Richard Jones wrote:
> > This is a good proposal, though I'm unclear on how the
> > static
o remove the xstatic dependencies to the mock and
cookies packages.
2. Patch global-requirements to remove them, and add newer Angular.
3. Patch Horizon to use the newer Angular.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nts.
That's strange, I thought that we use 1.2.16 already. Sorry for my mistake.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
d-webclient/tree/tox.ini
>
I created a blueprint for this.
https://blueprints.launchpad.net/horizon/+spec/static-file-bower
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
leases and push them out to customers. Node.js is a total
> incompatibility for Solaris. If upstream moves to using Bower we'll be
> forced to look for alternatives at managing the JavaScript libraries.
I have some bad news for you. Horizon already uses node.js for running
jshint on its Jav
with your own scripts) is
the development machine. For convenience, we will keep the list of
dependencies in a format compatible with Bower -- but it's a simple JSON
file that can be read by any other tool or script, written in any language.
I hope that clears it.
--
Radomir Dopiera
we can cut a corner and save the packagers having to
create all those dummy XStatic shims.
--
Radomir Dopieralski
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
d updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that specific library an
es into the Horizon's
package. That's the whole point, Horizon only has paths to them. The
files themselves are provided by the system-wide packages.
--
Radomir Dopieralski
__
OpenStack Development Mailing List
ng to
the actual system-wide JavaScript packages -- XStatic has such a
capability. So while we are indeed maintaining some of the XStatic
packages for our own convenience, the packages that contain actual code
in the distributions are
?
Yes, that is *exactly* the change that we want to make now and that we
are discussing! Drop the whole XStatic thing, and have a file in Horizon
that configures all the paths. Then use Bower for downloading the files
in development environments, and system packages in production.
--
Radomir
n't have to generate a file with all the includes
after all, because django-pyscss actually solves that problem for us.
Horizon's plugins can refer to Horizon's own files easily now.
The linter and other tools:
We will be able to include the linter in the gate check without having
-- I suppose we will work that
out soonish.
Oh, and great thanks to all the people who have helped me so far with
it, I wouldn't even dream about trying such a thing without you. Also
thanks in advance to anybody who plans to help!
--
Radomir Dopieralski
_
e documented?
I don't think this is important, but since we have some time until the
patches for static files and other stuff clear, we could have a poll for
the name. Gabriel, would you like to run that?
--
Radomir Dopieralski
___
is
important as well as the way it was made, but I'm hopeless at it.
It would be a great help if you could handle that.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
components of OpenStack, Horizon has to be
packaged at the end of the cycle, with all of its dependencies.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
not modifying the source code.
> When some of these
> dependencies begin to publish xstatic packages themselves, do the
> equivalent repositories in Gerrit get decommissioned at that point?
Yes, we will hand over the keys to the pypi entries, and get rid of the
repositories on our side.
proposed names. In case the most popular name is impossible to use
(due to trademark issues), we will use the next most popular. In case of
a tie, we will pick randomly.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
ble for the job.
In Horizon we only use Mox, and Mock is not even in requirements.txt. I
would like to propose to add Mock to requirements.txt and start using it
in new tests where it makes more sense than Mox -- in particular, when
we are writing unit tests only testing small part of the code.
T
/ doesn't sound good either, as the
projects they are packaging are not related to OpenStack.
Have them be managed by someone else? Who?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/03/2014 06:44 PM, Radomir Dopieralski wrote:
> We decided that we need to pick the name for the splitting of Horizon
> properly. From now up to the next meeting on June 10 we will be
> collecting name proposals at:
>
> https://etherpad.openstack.org/p/horizon-name-proposals
d for the dashboard part were removed from
the list. Once we get the results, we will consult with the OpenStack
Foundation and select the first valid name with the highest ranking.
The poll will end at the next Horizon team meeting, Tuesday, June 17, at
16:00 UTC.
Thank you,
--
Radomir Do
n't work for
> me - "you already voted from given key".
>
> Can anybody help?
>
> Thanks
> -- Jarda
>
> On 2014/10/06 21:18, Radomir Dopieralski wrote:
>> Hello everyone.
>>
>> We have collected a fine number of name proposals for the librar
On 06/10/2014 09:18 PM, Radomir Dopieralski wrote:
The name poll is now officially over, and the winner is:
horizon_lib
You can view the results here:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ea99af9511f3f255
I think we won't need to check for trademark issues with this name,
On 10/03/14 17:50, Lyle, David wrote:
> The results are unanimous. Congratulations Radomir and welcome to the
> Horizon Core team.
Thank you everyone, I will do my best!
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenSta
as 4 or 6 as the case may be.
Some browsers (Chrome, iirc) will not submit the values from form fields
that are disabled. That means, that when re-displaying this form
(after an error in any other field, for example), that field's value
will be missing, and the browser will happily display th
y
edited the form's HTML to get rid of the disabled or readonly attribute.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hello,
I also think that this thread is going in the wrong direction, but I
don't think the direction Boris wants is the correct one either. Frankly
I'm a little surprised that nobody mentioned another advantage that soft
delete gives us, the one that I think it was actually used for originally.
On 14/03/14 11:08, Alexei Kornienko wrote:
> On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
[snip]
>> OpenStack is a big, distributed system of multiple databases that
>> sometimes rely on each other and cross-reference their records. It's not
>> uncommon to have s
ossible task.)
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s how little effort is involved. You can see the patch at:
https://review.openstack.org/#/c/82516/
Any feedback and suggestions appreciated.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.or
g bower in a script in order to
> dynamically generate packages with the right versions?
How the actual xstatic-* packages are created and maintained is up to
the packager. They are not part of Horizon, so you can use any tools
you wish to create and update them.
--
Radomir Dopieralski
___
clause simply
makes that license incompatible with OpenStack's license. To use it, we
would need to change OpenStack's license too, and it quickly becomes
quite complex.
You have to remember that organizations like NSA use OpenStack, so we
can't possib
rk, and it uses a global
variable. I'm sure it would be possible to do it in a little bit cleaner
way. But at least it gives us the warning (sure, only if an exception is
actually being thrown, but that's test coverage problem).
I propose to do exception deprecating in this way in the
s... :(
>
> Ops, silly me. The parenthesis aren't correct. Fixing it made it all
> work. Sorry for the noise, issue closed!
By the way, did you consider sending that python 3 patch upstream to the
python-pyscss guys, so that you don't have to apply it manually every
time? They are quite responsive.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
odernizr.
I remember that discussion differently, and I'm not so sure there was a
definite conclusion. We definitely should not use a white list for this.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
ou want to replace this system with anything else, please keep in
contact with the packagers to make sure that the resulting process makes
sense and is acceptable for them.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.
he only thing that works
without having to modify the code of those tools.
Of course things might have changed since, or we may have someone with
better JavaScript hacking skills who would manage to make it work. But
last year we failed.
--
Radomir Dopieralski
_
ript) and therefore if we used it, you
would have to convince your fellow system administrators to install
node.js on their production servers. Violence may result.
[...]
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
grate new horizon_lib and horizon (or openstack-horizon) to
> devstack
I suppose we have to reach out to the devstack people for that.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
's mostly because if you develop a new web application in-house,
and deploy it on your server, you don't really have such large legal
risk, configuration complexity or support problem -- you just have to
care about that single application, be
On 14/11/14 13:02, Richard Jones wrote:
>> On 14 November 2014 18:51, Radomir Dopieralski > <mailto:openst...@sheep.art.pl>> wrote:
>> On 13/11/14 23:30, Martin Geisler wrote:
[...]
>> > Maybe a difference is that you don't (yet) install a web a
On 15/11/14 03:21, Richard Jones wrote:
> On 15 November 2014 00:58, Radomir Dopieralski wrote:
[...]
>> 4. additions and upgrades of libraries moderated by the packagers,
>
> Is there already some mechanism for handling the creation and management
> of xstatic pac
n for that.
- A script that would generate a file with all the paths to those
packaged libraries, that would get included in Horizon's settings.py
What do you think?
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 18/11/14 00:59, Richard Jones wrote:
> On 17 November 2014 21:54, Radomir Dopieralski <mailto:openst...@sheep.art.pl>> wrote:
>> - Bower in the development environment,
>> - Bower configuration file in two copies, one for global-requirements,
>> and one for th
make a whole xstatic package just to put that single path in
there. The horizon system package would already depend on all the
javascript library packages, so we are sure the files are there.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ne here or on
the wiki/etherpad, as that leaves tangible traces. I will post a
detailed e-mail in a few days. Other than that, I don't see a compelling
reason to organize it.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
na +1
Zhenguo +1
Thank you for your great work guys!
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hello,
I did some planning and thinking around the subject of Horizon's
configuration files. I summarized it all at:
https://review.openstack.org/#/c/100521/8/horizon-config-rfc.rst
Please feel free to comment. Any feedback appreciated.
--
Radomir Dopier
t will help us review faster and get
to your patch sooner.
Thank you,
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
seful.
If you are customizing or extending Horizon, please take a moment and
write what you are doing exactly and what you would like to do, if it's
not possible at the moment. Please do it under a new heading, so that we
have some order in there.
Thank you,
--
Radomir D
hem are sometimes
warranted -- but they are always suspicious, and when I find myself
falling into one of them, I always rethink what I'm doing. Maybe you
have some more bad patterns that you would like to share? Reviewing code
is a difficult skill and it's always good to improve it by us
On 06/11/13 23:07, Robert Collins wrote:
> On 6 November 2013 21:34, Radomir Dopieralski wrote:
> [...] Firstly, things
> like code duplication is a sliding scale, and I think it's ok for a
> reviewer to say 'these look similar, give it a go please'. If the
> re
t. In my team I was on the review duty all the
time, so it wasn't much of an issue, but you are right that it is very
important in the more distributed environment of OpenStack. I will keep
it in mind for the future, thank you.
I'm also not sure whethe
On 06/11/13 09:34, Radomir Dopieralski wrote:
> Hello,
>
> I'm quite new in the OpenStack project, but I love it already. What is
> especially nifty is the automated review system -- I'm really impressed.
> I'm coming from a project in which we also did reviews of
rs as OpenStack is probably the reason why I didn't notice the
problem with comment ownership. I added a section about that to the
wiki page.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ideas.
Reading is not a problem, it's helpful and people do like attention :)
The problem is if you force them to respond by -1'ing the patch, making
them explain themselves every time.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
O
.
Well, you can do it with one copy-paste, edit and command. But then it
has to be approved by one more person, so it doesn't necessarily make it
much faster.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
Hi,
sorry for late reply. The whole "openstack_dashboard/local/enabled/"
mechanism was inspired by the mechanisms used commonly in Debian and other
distributions to enable/disable plugins. In short, you shouldn't *copy* the
configuration files to the "enabled" directory -- instead you should keep
you really shouldn't.
Most web servers out there expect to do their own process/thread
management and get really embarrassed if you do something like this,
resulting in weird stuff happening.
--
Radomir Dopieralski
_
1 - 100 of 131 matches
Mail list logo
