Details about the last push

[suren...@gmail.com]

Hi,
Instead of settings.py in django project being versioned, I removed it
and made a settings.py.sample. (Also made a few changes to the way
settings.py looked, inspired from djangoproject.com's source). Every
installation has an added step of copying this file to settings.py and
adding corresponding host's DB connection details. Since Aditya's push
had this file, had to include it back and then remove it again so that
the merge went fine. True this had to be done at the starting of
project and anyone who wanted to see old crendentials data can always
get it from old versions, atleast it won't be on the head now.

Other Changes: The admin UI started complaining because of new CSRF
requirements in django. So updated all admin templates. That was
another commit. Also added an example.sql which contains just the data
for a contest, its problems, submissions that we have using to test
against.

With the current default branch tip, the checker backend is working
fine, but its not jailed as I expected it to be. As far as the FE is
concerned, still the entire FE is pending.

PK: Following are the major bugs at this point, for the sprint that we
informally planned.
1) Complete the JAIL
2) Decouple evaluation logic
3) Complete FE views asap

@Aditya: I haven't got time to look into your DB decoupling. Let me
look into it and come back to you on that :)

--
regards
Suren

http://twitter.com/suren

[krishnan parthasarathi]

Hi Suren,

On Sat, Oct 16, 2010 at 1:22 AM, suren...@gmail.com <suren...@gmail.com> wrote:

Hi,
Instead of settings.py in django project being versioned, I removed it
and made a settings.py.sample. (Also made a few changes to the way
settings.py looked, inspired from djangoproject.com's source). Every
installation has an added step of copying this file to settings.py and
adding corresponding host's DB connection details.

I don't understand why this change is needed. Can you explain it in slightly more detail?

Since Aditya's push
had this file, had to include it back and then remove it again so that
the merge went fine. True this had to be done at the starting of
project and anyone who wanted to see old crendentials data can always
get it from old versions, atleast it won't be on the head now.

Other Changes: The admin UI started complaining because of new CSRF
requirements in django. So updated all admin templates. That was
another commit. Also added an example.sql which contains just the data
for a contest, its problems, submissions that we have using to test
against.

With the current default branch tip, the checker backend is working
fine, but its not jailed as I expected it to be. As far as the FE is
concerned, still the entire FE is pending.

PK: Following are the major bugs at this point, for the sprint that we
informally planned.
1) Complete the JAIL

The jail/chroot does not work without having mounted (mount -- bind, in Ubuntu) /usr, /bin, /lib directories in the chrooted directory. Having said that, you should see if a file "chstuff" was created in the chrooted directory. That file has the errno with which chroot command failed. That is a good starting point. Since I have not got a test setup yet, can you please look into that and give me more details?

2) Decouple evaluation logic

Are you referring to a make our codechecker accept a problem setter supplied evaluator to evaluate each submission? If that is the case, we will take that up after we finalise on the redesign task.

3) Complete FE views asap

Yes, this is important as well. Since FE is independent to the backend, can you create issues that track the necessary changes, so that each of us can start working on it?

@Aditya: I haven't got time to look into your DB decoupling. Let me
look into it and come back to you on that :)

--
regards
Suren

http://twitter.com/suren

--
--Krishnan Parthasarathi

[suren...@gmail.com]

HI Krishnan,

On Sat, Oct 16, 2010 at 1:50 AM, krishnan parthasarathi
<krishnan.pa...@gmail.com> wrote:
> Hi Suren,
>
> On Sat, Oct 16, 2010 at 1:22 AM, suren...@gmail.com <suren...@gmail.com>
> wrote:
>>
>> Hi,
>> Instead of settings.py in django project being versioned, I removed it
>> and made a settings.py.sample. (Also made a few changes to the way
>> settings.py looked, inspired from djangoproject.com's source). Every
>> installation has an added step of copying this file to settings.py and
>> adding corresponding host's DB connection details.
>
> I don't understand why this change is needed. Can you explain it in slightly
> more detail?

Ideally settings.py should never be revisioned. As we move forward, we
have to a gmail related account information for making registration
work which should not be revisioned at all. One simple problem with
revisioning the settings.py. Lets say some one who is participating
knows our db password. He can directly connect and make changes to the
DB. Though the DB will have permissions on localhost, its not too
hard to do such a thing via the submitted code. So the approach here
is to create a settings.py.sample which is revisioned and always to
create a settings.py copying from the sample and adding the DB and
other secrets. This I observed from various other projects -
djangoproject, wordpress and fossconf.

>>
>> PK: Following are the major bugs at this point, for the sprint that we
>> informally planned.
>> 1) Complete the JAIL
>
> The jail/chroot does not work without having mounted (mount -- bind, in
> Ubuntu) /usr, /bin, /lib directories in the chrooted directory. Having said
> that, you should see if a file "chstuff" was created in the chrooted
> directory. That file has the errno with which chroot command failed. That is
> a good starting point. Since I have not got a test setup yet, can you please
> look into that and give me more details?
>>

Will check this up and let you know.

>> 2) Decouple evaluation logic
>
> Are you referring to a make our codechecker accept a problem setter supplied
> evaluator to evaluate each submission? If that is the case, we will take
> that up after we finalise on the redesign task.
>>

No, not that one. But a setuid_helper like external command that will
replace the current evaluation method. I thought we discussed this
already.

>> 3) Complete FE views asap
>
> Yes, this is important as well. Since FE is independent to the backend, can
> you create issues that track the necessary changes, so that each of us can
> start working on it?

Will do !

[krishnan parthasarathi]

Ok, that makes sense. 

>>
>> PK: Following are the major bugs at this point, for the sprint that we
>> informally planned.
>> 1) Complete the JAIL
>
> The jail/chroot does not work without having mounted (mount -- bind, in
> Ubuntu) /usr, /bin, /lib directories in the chrooted directory. Having said
> that, you should see if a file "chstuff" was created in the chrooted
> directory. That file has the errno with which chroot command failed. That is
> a good starting point. Since I have not got a test setup yet, can you please
> look into that and give me more details?
>>

Will check this up and let you know.

>> 2) Decouple evaluation logic
>
> Are you referring to a make our codechecker accept a problem setter supplied
> evaluator to evaluate each submission? If that is the case, we will take
> that up after we finalise on the redesign task.
>>

No, not that one. But a setuid_helper like external command that will
replace the current evaluation method. I thought we discussed this
already.

There seems to be a small misunderstanding. The external command you are referring to is nothing but program/binary(s) supplied by the problem setter that will perform the evaluation and/or scoring of the submissions for that problem. We provide a default compare against reference output and assign a score for the submission for a problem mechanism which can be overridden by giving an external command if applicable for both evaluation and scoring separately.

>> 3) Complete FE views asap
>
> Yes, this is important as well. Since FE is independent to the backend, can
> you create issues that track the necessary changes, so that each of us can
> start working on it?

Will do !


--

regards
Suren

http://twitter.com/suren

--
--Krishnan Parthasarathi