RE: [gnome-db] Name proposal/contest for gnome-db/gASQL



Le lun 17/06/2002 à 19:25, Rodrigo Moya a écrit :
> On Mon, 2002-06-17 at 18:43, Malerba_Vivien stna dgac fr wrote:
> > Le dim 16/06/2002 à 23:18, Rodrigo Moya a écrit :
> > > On Thu, 2002-06-13 at 23:06, Fernando Martins wrote:
> > > > 
> > > > I know too little about CVS, so forgive me if this is wrong, but if egnima
> > > > is the name chosen to merge gnome-db and gASQL, would it not be more logical
> > > > to leave the modules libgda, libgnomedb, gnomedbfe and gASQL as they are and
> > > > put egnima as a virtual module to CVS?
> > > > 
> > > hmm, I don't know what would be better. Anyone has any comments?
> > 
> > >From the merge process, I'd say that at the moment we have a consistant
> > package in gnome-db's gasql branch, which, when I've finished the Gnome2
> > port can be a start for Egnima (and then replace completely the current
> > gnome-db and gASQL modules since parts of the two are now merged in that
> > module). So I don't think a virtual modules would bring much in this
> > case.
> > 
> > IMO the best would be to have 3 core modules: libgda, libgnomedb and
> > egnima, and a 4th one (gnome-db) to be a virtual module which basically
> > grabs the 3 previous ones. 
> > 
> so, are you saying to move, when the port is finished, the gasql branch
> into its own module (egnima) and then just keep gnome-db as a virtual
> module?

Yes, that's the idea.

> 
> If so, copying the gnome-db sources physically to egnima in the CVS
> repository might do the trick, without losing any CVS history.

I suppose so, but I don't knwo much of the internals of CVS.

> 
> > > 
> > > > This virtual module would then became real with time, i.e., would get parts
> > > > of the existing modules, get new parts or simply call existing modules, when
> > > > the project integration becomes more than just the sum of the parts.
> > > >
> > > that sounds like a cool idea. The only thing is that we'll lose some CVS
> > > history.
> > 
> > As of now, the integration is (from the source files' point of view)
> > quite finished since we now have a lib/ directory in gnome-db (The doc
> > is completely out of date though).
> >
> that's not a problem anymore, since we have now people who will work on
> the docs :-)
> 

Good! Let me know if I can bring some help to understand things for the
documentation.

> > I agree that we need a kind of features and TODO lists at least for
> > Egnima. I can propose something if you want.
> > 
> I've been using bugzilla for that, and I think that's what we should be
> using, since it helps a lot when keeping track of who is working on what
> and what else is missing. So far, the list of open bugs for
> libgda/libgnomedb/gnome-db/gASQL is at:
> 
> http://bugzilla.gnome.org/buglist.cgi?product=gASQL&product=gnome-db&product=libgda&product=libgnomedb&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboard=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&op_sys_details=&op_sys_details_type=substring&version_details=&version_details_type=substring&cmdtype=doit&order=Reuse+same+sort+as+last+time&form_name=query
> 
> so, if nobody has nothing against it, just let's use bugzilla. As soon
> as we finish the port, I'll create a product for egnima. Or, even
> better, I could create it now. For that, I'd just need to know in which
> components (parts) are we splitting out egnima. So, vivien, please tell
> me which components you want, and I'll create them, so that you can
> enter TODO tasks into bugzilla and have people take them when they want
> to work on something.

Yes, that's better using bugzilla.

About Egnima's components, I don't have a precise idea except to have
components for the documentation, packages, translations and general
code. I have no idea if we should split further the code into other sub
components.

Cheers,

Vivien



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]