Skip site navigation (1) Skip section navigation (2)

Re: pgAdmin III commit: Database Designer (milestone 1 of GSoC 2011)

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: Luis Ochoa <ziul1979(at)gmail(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: pgAdmin III commit: Database Designer (milestone 1 of GSoC 2011)
Date: 2011-06-30 08:02:11
Message-ID: 1309420931.1949.10.camel@laptop (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On Wed, 2011-06-29 at 20:08 +0100, Dave Page wrote:
> On Wednesday, June 29, 2011, Luis Ochoa <ziul1979(at)gmail(dot)com> wrote:
> > On Wed, Jun 29, 2011 at 3:51 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> >
> >
> >
> > On Wed, Jun 29, 2011 at 3:16 AM, Luis Ochoa <ziul1979(at)gmail(dot)com> wrote:
> >>
> >> Well, I can change that class name, but when should  I do that, now or
> >> later?
> >> which name can be used?
> >
> > Now would be better - I prefer not to leave the tree in a state where
> > we know major restructuring is required for too long. Name-wise, I'd
> > call the module "hotdraw", and prefix the class naes with "hd".
> >
> > Well, I think "hotdraw" name standalone can be a problem because this is the name of the original implementation, and that could lead to confuse developers who work with source the code in the future, I suggest then something hd only and the prefix will be hd too. What do you think about this?
> >
> hd works for me.

What would hotdraw confuse people, and hd wouldn't? I don't get it. I
see a hd directory, I wonder what it is (high definition would be my
first guess honestly).

While we are renaming it, we should move it to the root directory.
AFAICT, it could be used for the GQB.

> >>> Well, docs will be done at the end.
> >
> > End of what? If this is a milestone commit, then it presumably (I
> > hope) encompasses some completed functionality - which really isn't
> > complete until the docs are done. With the best will in the world,
> > things left to the end of GSoC projects often don't get completed as
> > planned, and I'd rather not see us end up with another cool, but
> > undocumented feature.
> >

Well, you already know what I think of our current documentation. It
won't be difficult to have the same kind of documentation for the DD
once the GSoC is done. We'll still have 10 months to write it. I know it
would be better to add it when we add the feature (to get a complete
commit), but with our current documentation, that doesn't seem a big
deal to me.

If you really want it now, I can write something this week-end.

> > Well I didn't write that sentence (following the thread) or anything about writing docs at my project/proposal (or before), because I never got a petition of doing that kind of things now or before, and they aren't included at my schedule. But I can do that if someone tell me what Should I do?.
> >
> No sorry - that was directed at Guillaume.
> I don't want to throw your GSoC schedule into turmoil, so I'm not
> going to insist on docs now (though I would expect them by the end of
> the project), but the project has always had an unwritten rule that
> any new features should include the docs - we've just been lax about
> enforcing it. That cannot continue though - we really need to become
> more disciplined.

I agree on this.


In response to

pgadmin-hackers by date

Next:From: Guillaume LelargeDate: 2011-06-30 08:08:39
Subject: Re: pgAdmin III commit: Database Designer (milestone 1 of GSoC 2011)
Previous:From: Dave PageDate: 2011-06-29 19:08:22
Subject: Re: pgAdmin III commit: Database Designer (milestone 1 of GSoC 2011)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group