fofredux-devel

[Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

So I just checked out off the head and copied my config.php over to try
to use my existing FOF database;  It correctly asks "cache dir not found
/ writable whatever have you run install?" so I ran install, and hit the
panel, and got this error:

[select feed.id, feed.url, feed.title, feed.link,
feed.description,feed.latitude,feed.longitude, feed.category_id,
cat.name from px_feeds feed, FOF_CATEGORY_TABLE cat WHERE cat.id =
feed.category_id order by feed.title]: 0.0022
Cannot query database. Have you run install.php? MySQL says: Unknown
column 'feed.latitude' in 'field list'

The problem is fairly obvious;  I guess we just need to make sure
upgrades from FOF work seemlessly, and ideally are backwards compatible
for now?   (This mainly relies on stevem not having any select *'s or
insert into table select * from other table in his code, but we should
also be good and add new columns to the end to give any select *s a
*chance* of working)

So uh, i tried altering my tables with the below sql, and I'm still
getting some errors.  I'll follow up when I isolate exactly what else
will be need for an upgrade.

(must be run in order at the moment:)

alter table px_feeds add column category_id int(11) default NULL;
alter table px_feeds add column latitude float default '0.0';
alter table px_feeds add column longitude float default '0.0';
alter table px_items add column flag tinyint(4) default NULL 
alter table px_items add column latitude float default '0.0';  
alter table px_items add column longitude float default '0.0';

(Oh, this does bring up the question of whether or not we want to change
the name of the 'read' column at some point, so we can stop confusing
mysql)

--Benjy

[Fofredux-devel] Re: unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

So the next problems I was having were because my category and
categoryXfeed tables had not been created.  This may have been because I
didn't add the table defitions to my config.php before running install,
but I have not followed up on this possibility.

Regardless, we should handle the case of the idiot who does not read
documnetion when trying to upgrade.

Any insights as to what the problem might have been before I back up and
dig into that?

--Benjy

On Sun, Nov 27, 2005 at 03:06:15PM -0800, Benjamin Stewart wrote:
> So I just checked out off the head and copied my config.php over to try
> to use my existing FOF database;  It correctly asks "cache dir not found
> / writable whatever have you run install?" so I ran install, and hit the
> panel, and got this error:
> 
> [select feed.id, feed.url, feed.title, feed.link,
> feed.description,feed.latitude,feed.longitude, feed.category_id,
> cat.name from px_feeds feed, FOF_CATEGORY_TABLE cat WHERE cat.id =
> feed.category_id order by feed.title]: 0.0022
> Cannot query database. Have you run install.php? MySQL says: Unknown
> column 'feed.latitude' in 'field list'
> 
> The problem is fairly obvious;  I guess we just need to make sure
> upgrades from FOF work seemlessly, and ideally are backwards compatible
> for now?   (This mainly relies on stevem not having any select *'s or
> insert into table select * from other table in his code, but we should
> also be good and add new columns to the end to give any select *s a
> *chance* of working)
> 
> So uh, i tried altering my tables with the below sql, and I'm still
> getting some errors.  I'll follow up when I isolate exactly what else
> will be need for an upgrade.
> 
> (must be run in order at the moment:)
> 
> alter table px_feeds add column category_id int(11) default NULL;
> alter table px_feeds add column latitude float default '0.0';
> alter table px_feeds add column longitude float default '0.0';
> alter table px_items add column flag tinyint(4) default NULL 
> alter table px_items add column latitude float default '0.0';  
> alter table px_items add column longitude float default '0.0';
> 
> (Oh, this does bring up the question of whether or not we want to change
> the name of the 'read' column at some point, so we can stop confusing
> mysql)
> 
> --Benjy

[Fofredux-devel] Re: unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

Okay, I'm giving up figuring out what's wrong with upgrading for the
moment and I'm going to work against a clean DB, but I don't think I'd
call it an RC until upgrade / backwards compatability issues are sorted
out.  If we want FOF users to check it out, I think it should be
backwards compatible so FOF users can check it out but switch back to
FOF if they want.

If no one else wants to work on the upgrade issues, I might have time to
work on it in the next week, but am going to integrate keyboard
shortcuts onto a branch today.

--Benjy

On Sun, Nov 27, 2005 at 03:13:31PM -0800, Benjamin Stewart wrote:
> So the next problems I was having were because my category and
> categoryXfeed tables had not been created.  This may have been because I
> didn't add the table defitions to my config.php before running install,
> but I have not followed up on this possibility.
> 
> Regardless, we should handle the case of the idiot who does not read
> documnetion when trying to upgrade.
> 
> Any insights as to what the problem might have been before I back up and
> dig into that?
> 
> --Benjy
> 
> On Sun, Nov 27, 2005 at 03:06:15PM -0800, Benjamin Stewart wrote:
> > So I just checked out off the head and copied my config.php over to try
> > to use my existing FOF database;  It correctly asks "cache dir not found
> > / writable whatever have you run install?" so I ran install, and hit the
> > panel, and got this error:
> > 
> > [select feed.id, feed.url, feed.title, feed.link,
> > feed.description,feed.latitude,feed.longitude, feed.category_id,
> > cat.name from px_feeds feed, FOF_CATEGORY_TABLE cat WHERE cat.id =
> > feed.category_id order by feed.title]: 0.0022
> > Cannot query database. Have you run install.php? MySQL says: Unknown
> > column 'feed.latitude' in 'field list'
> > 
> > The problem is fairly obvious;  I guess we just need to make sure
> > upgrades from FOF work seemlessly, and ideally are backwards compatible
> > for now?   (This mainly relies on stevem not having any select *'s or
> > insert into table select * from other table in his code, but we should
> > also be good and add new columns to the end to give any select *s a
> > *chance* of working)
> > 
> > So uh, i tried altering my tables with the below sql, and I'm still
> > getting some errors.  I'll follow up when I isolate exactly what else
> > will be need for an upgrade.
> > 
> > (must be run in order at the moment:)
> > 
> > alter table px_feeds add column category_id int(11) default NULL;
> > alter table px_feeds add column latitude float default '0.0';
> > alter table px_feeds add column longitude float default '0.0';
> > alter table px_items add column flag tinyint(4) default NULL 
> > alter table px_items add column latitude float default '0.0';  
> > alter table px_items add column longitude float default '0.0';
> > 
> > (Oh, this does bring up the question of whether or not we want to change
> > the name of the 'read' column at some point, so we can stop confusing
> > mysql)
> > 
> > --Benjy

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Kevin <ke...@dr...>]

Benjamin Stewart wrote:

<snip>

>(Oh, this does bring up the question of whether or not we want to change
>the name of the 'read' column at some point, so we can stop confusing
>mysql)
>  
>
+1.   Using reserved words as column names is a bad idea.  The backtick 
workaround is not cross DB compatible.  This column could even be 
eliminated by using a "read" or "unread" tag.

--Kevin

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Andrew T. <ajt...@hi...>]

Do we want to support some enumerated "Flag" that is separate from
tags/categories for things like read, unread, "flagged", "delete" ?

I guess incorporating this into tags is the most flexible means. Would
require less coding to do a search on "all items with tags windows,
programming, unread" and completely flexible "flags"

What say anyone else?

Andy


On 11/28/05, Kevin <ke...@dr...> wrote:
> Benjamin Stewart wrote:
>
> <snip>
>
> >(Oh, this does bring up the question of whether or not we want to change
> >the name of the 'read' column at some point, so we can stop confusing
> >mysql)
> >
> >
> +1.   Using reserved words as column names is a bad idea.  The backtick
> workaround is not cross DB compatible.  This column could even be
> eliminated by using a "read" or "unread" tag.
>
> --Kevin
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Fofredux-devel mailing list
> Fof...@li...
> https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>


--
Andrew Turner
ajt...@hi...        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA
idealistic technocrat

Photos - http://flickr.com/photos/ajturner
Travel   - http://highearthorbit.com/projects/location/

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

Whatever we do, I would like to reiterate the desire to maintain
backwards compatability for the first release, which means we can't get
rid of 'read' yet.

Ultimately, I think I like the idea of using tags for all status, and we
might have some "reserved" tags (read, unread, etc) that don't show up
as normal tags in the UI, but act just like tags.

--Benjy



On Mon, Nov 28, 2005 at 01:50:42PM -0500, Andrew Turner wrote:
> Do we want to support some enumerated "Flag" that is separate from
> tags/categories for things like read, unread, "flagged", "delete" ?
>=20
> I guess incorporating this into tags is the most flexible means. Would
> require less coding to do a search on "all items with tags windows,
> programming, unread" and completely flexible "flags"
>=20
> What say anyone else?
>=20
> Andy
>=20
>=20
> On 11/28/05, Kevin <ke...@dr...> wrote:
> > Benjamin Stewart wrote:
> >
> > <snip>
> >
> > >(Oh, this does bring up the question of whether or not we want to chan=
ge
> > >the name of the 'read' column at some point, so we can stop confusing
> > >mysql)
> > >
> > >
> > +1.   Using reserved words as column names is a bad idea.  The backtick
> > workaround is not cross DB compatible.  This column could even be
> > eliminated by using a "read" or "unread" tag.
> >
> > --Kevin
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Fofredux-devel mailing list
> > Fof...@li...
> > https://lists.sourceforge.net/lists/listinfo/fofredux-devel
> >
>=20
>=20
> --
> Andrew Turner
> ajt...@hi...        42.4266N x 83.4931W
> http://highearthorbit.com              Northville, Michigan, USA
> idealistic technocrat
>=20
> Photos - http://flickr.com/photos/ajturner
> Travel   - http://highearthorbit.com/projects/location/
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Fofredux-devel mailing list
> Fof...@li...
> https://lists.sourceforge.net/lists/listinfo/fofredux-devel

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Andrew T. <ajt...@hi...>]

Ok - so read/unread in tags it is. Sounds reasonable. Do we filter
read/unread when we display an item's tags? If so, do we use
read/unread as the "magic tags" regardless of language (I think we
will definitely want to support multiple languages in the UI)

Also, as for backwards compatability, you mean being able to switch
back and forth b/w FoF v0.19 and FoFRedux v0.2? We will need to
reconfigure tables at some point, and this may be the best point to
provide an "upgrade" script that would migrate the "read" column to a
"read/unread" flag. ADODB is nice in that it supports table format,
but we could write a script for this first release. Do you think that
covers the compatability enough?



On 11/28/05, Benjamin Stewart <bs...@cr...> wrote:
> Whatever we do, I would like to reiterate the desire to maintain
> backwards compatability for the first release, which means we can't get
> rid of 'read' yet.
>
> Ultimately, I think I like the idea of using tags for all status, and we
> might have some "reserved" tags (read, unread, etc) that don't show up
> as normal tags in the UI, but act just like tags.
>
> --Benjy
>
>
>
> On Mon, Nov 28, 2005 at 01:50:42PM -0500, Andrew Turner wrote:
> > Do we want to support some enumerated "Flag" that is separate from
> > tags/categories for things like read, unread, "flagged", "delete" ?
> >
> > I guess incorporating this into tags is the most flexible means. Would
> > require less coding to do a search on "all items with tags windows,
> > programming, unread" and completely flexible "flags"
> >
> > What say anyone else?
> >
> > Andy
> >
> >
> > On 11/28/05, Kevin <ke...@dr...> wrote:
> > > Benjamin Stewart wrote:
> > >
> > > <snip>
> > >
> > > >(Oh, this does bring up the question of whether or not we want to ch=
ange
> > > >the name of the 'read' column at some point, so we can stop confusin=
g
> > > >mysql)
> > > >
> > > >
> > > +1.   Using reserved words as column names is a bad idea.  The backti=
ck
> > > workaround is not cross DB compatible.  This column could even be
> > > eliminated by using a "read" or "unread" tag.
> > >
> > > --Kevin
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through lo=
g files
> > > for problems?  Stop!  Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUN=
K!
> > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > > _______________________________________________
> > > Fofredux-devel mailing list
> > > Fof...@li...
> > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel
> > >
> >
> >
> > --
> > Andrew Turner
> > ajt...@hi...        42.4266N x 83.4931W
> > http://highearthorbit.com              Northville, Michigan, USA
> > idealistic technocrat
> >
> > Photos - http://flickr.com/photos/ajturner
> > Travel   - http://highearthorbit.com/projects/location/
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> > _______________________________________________
> > Fofredux-devel mailing list
> > Fof...@li...
> > https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>


--
Andrew Turner
ajt...@hi...        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA
idealistic technocrat

Photos - http://flickr.com/photos/ajturner
Travel   - http://highearthorbit.com/projects/location/

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Kevin <ke...@dr...>]

> Ok - so read/unread in tags it is. Sounds reasonable. Do we filter
> read/unread when we display an item's tags? If so, do we use
> read/unread as the "magic tags" regardless of language (I think we
> will definitely want to support multiple languages in the UI)
>
> Also, as for backwards compatability, you mean being able to switch
> back and forth b/w FoF v0.19 and FoFRedux v0.2? We will need to
> reconfigure tables at some point, and this may be the best point to
> provide an "upgrade" script that would migrate the "read" column to a
> "read/unread" flag. ADODB is nice in that it supports table format,
> but we could write a script for this first release. Do you think that
> covers the compatability enough?

For me, just running install.php and doing an OPML import was a *good
enough* upgrade path.  ;)

Ben, Do you really think retaining backwards compatiblity with FoF at the
db schema level is a good idea?  What about if we provide a decent import
function that pulls the feeds and items from the FoF tables but does not
modify them?


> On 11/28/05, Benjamin Stewart <bs...@cr...> wrote:
>> Whatever we do, I would like to reiterate the desire to maintain
>> backwards compatability for the first release, which means we can't ge=
t
>> rid of 'read' yet.
>>
>> Ultimately, I think I like the idea of using tags for all status, and =
we
>> might have some "reserved" tags (read, unread, etc) that don't show up
>> as normal tags in the UI, but act just like tags.
>>
>> --Benjy
>>
>>
>>
>> On Mon, Nov 28, 2005 at 01:50:42PM -0500, Andrew Turner wrote:
>> > Do we want to support some enumerated "Flag" that is separate from
>> > tags/categories for things like read, unread, "flagged", "delete" ?
>> >
>> > I guess incorporating this into tags is the most flexible means. Wou=
ld
>> > require less coding to do a search on "all items with tags windows,
>> > programming, unread" and completely flexible "flags"
>> >
>> > What say anyone else?
>> >
>> > Andy
>> >
>> >
>> > On 11/28/05, Kevin <ke...@dr...> wrote:
>> > > Benjamin Stewart wrote:
>> > >
>> > > <snip>
>> > >
>> > > >(Oh, this does bring up the question of whether or not we want to
>> change
>> > > >the name of the 'read' column at some point, so we can stop
>> confusing
>> > > >mysql)
>> > > >
>> > > >
>> > > +1.   Using reserved words as column names is a bad idea.  The
>> backtick
>> > > workaround is not cross DB compatible.  This column could even be
>> > > eliminated by using a "read" or "unread" tag.
>> > >
>> > > --Kevin
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> > > for problems?  Stop!  Download the new AJAX search engine that mak=
es
>> > > searching your log files as easy as surfing the  web.  DOWNLOAD
>> SPLUNK!
>> > > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
>> > > _______________________________________________
>> > > Fofredux-devel mailing list
>> > > Fof...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>> > >
>> >
>> >
>> > --
>> > Andrew Turner
>> > ajt...@hi...        42.4266N x 83.4931W
>> > http://highearthorbit.com              Northville, Michigan, USA
>> > idealistic technocrat
>> >
>> > Photos - http://flickr.com/photos/ajturner
>> > Travel   - http://highearthorbit.com/projects/location/
>> >
>> >
>> > -------------------------------------------------------
>> > This SF.net email is sponsored by: Splunk Inc. Do you grep through l=
og
>> files
>> > for problems?  Stop!  Download the new AJAX search engine that makes
>> > searching your log files as easy as surfing the  web.  DOWNLOAD
>> SPLUNK!
>> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
>> > _______________________________________________
>> > Fofredux-devel mailing list
>> > Fof...@li...
>> > https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>>
>
>
> --
> Andrew Turner
> ajt...@hi...        42.4266N x 83.4931W
> http://highearthorbit.com              Northville, Michigan, USA
> idealistic technocrat
>
> Photos - http://flickr.com/photos/ajturner
> Travel   - http://highearthorbit.com/projects/location/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Fofredux-devel mailing list
> Fof...@li...
> https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>


--=20
Kevin

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Andrew T. <ajt...@hi...>]

On 11/28/05, Kevin <ke...@dr...> wrote:
>
> For me, just running install.php and doing an OPML import was a *good
> enough* upgrade path.  ;)

Me too - which is why I didn't notice missing tables, etc. in applying
FoFRedux to an existing DB. > 30 day old items are by default deleted
currently anyways?

>
> Ben, Do you really think retaining backwards compatiblity with FoF at the
> db schema level is a good idea?  What about if we provide a decent import
> function that pulls the feeds and items from the FoF tables but does not
> modify them?

We could create a new set of tables (ergo the table prefix change by
default) and migrate across for the first time. Does this scale for
the future?

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

> For me, just running install.php and doing an OPML import was a *good
> enough* upgrade path.  ;)

Heh.  

> Ben, Do you really think retaining backwards compatiblity with FoF at the
> db schema level is a good idea?  What about if we provide a decent import
> function that pulls the feeds and items from the FoF tables but does not
> modify them?

I don't think it's a good idea *long* term, but I don't think it'd be
that hard to do for just one release.  While on the one hand we have to
bite the bullet at some point and release 1 seems like as good a time as
any, I'm not really sure it's *necessary* for v1 unless some feature
really calls for it.  

The advantage of this is it'd let people switch back and forth between
the two and let them decide which one they like.  If nothing else,
hopefully this would earn us some points with whatever users decide to
check us out.  If we have even one compelling feature that FOF doesn't,
then why wouldn't they switch?  

But, I could be pursuaded otherwise.  For example, if the name 'read'
causes us too many problems, then sure, we could get rid of it.  And
whoever suggested that it'd be easy enough to write a script to flip the
database back to an FOF database is probably right.

I just thought it'd be a "nice to have."

--Benjy

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Kevin <ke...@dr...>]

>> Ben, Do you really think retaining backwards compatiblity with FoF at
>> the
>> db schema level is a good idea?  What about if we provide a decent
>> import
>> function that pulls the feeds and items from the FoF tables but does n=
ot
>> modify them?
>
> I don't think it's a good idea *long* term, but I don't think it'd be
> that hard to do for just one release.  While on the one hand we have to
> bite the bullet at some point and release 1 seems like as good a time a=
s
> any, I'm not really sure it's *necessary* for v1 unless some feature
> really calls for it.
>
> The advantage of this is it'd let people switch back and forth between
> the two and let them decide which one they like.  If nothing else,
> hopefully this would earn us some points with whatever users decide to
> check us out.  If we have even one compelling feature that FOF doesn't,
> then why wouldn't they switch?
>
> But, I could be pursuaded otherwise.  For example, if the name 'read'
> causes us too many problems, then sure, we could get rid of it.  And
> whoever suggested that it'd be easy enough to write a script to flip th=
e
> database back to an FOF database is probably right.
>
> I just thought it'd be a "nice to have."

So, what have we done so far that breaks FoF compatiblity?  I guess I'll
have to install it and see.  Removing or renaming the "read" column
definitly will break it.  We could set a "compatiblity flag" that will
keep the "read" column in sync with the read/unread tags.  There are very
few places where the read column is altered, so it's not too difficult to
do.

--=20
Kevin

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

> So, what have we done so far that breaks FoF compatiblity?  I guess I'll
> have to install it and see.  Removing or renaming the "read" column
> definitly will break it.  We could set a "compatiblity flag" that will
> keep the "read" column in sync with the read/unread tags.  There are very
> few places where the read column is altered, so it's not too difficult to
> do.

The problem is, if we switch to tags for state, FOF won't update that
and will *only* update 'read,' which means changes made in FOF won't be
picked up by us.

--Benjy

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Kevin <ke...@dr...>]

>> So, what have we done so far that breaks FoF compatiblity?  I guess I'=
ll
>> have to install it and see.  Removing or renaming the "read" column
>> definitly will break it.  We could set a "compatiblity flag" that will
>> keep the "read" column in sync with the read/unread tags.  There are
>> very
>> few places where the read column is altered, so it's not too difficult
>> to
>> do.
>
> The problem is, if we switch to tags for state, FOF won't update that
> and will *only* update 'read,' which means changes made in FOF won't be
> picked up by us.

Okay, so it's not just supporting a downgrade path back to FoF, but also
running them in parallel.  So, the plus for doing this is making it easie=
r
for existing FoF users to try out FoFr.  The downside is we wait a few
revs before converting the read column to a tag.

--=20
Kevin

Re: Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Carlos K. <ck...@gm...>]

I agree with Benjy, allowing the users run fof and fofredux
simultaneously with the same db and tables, would allow them to choose
more easily.

I guess that at fofredux installation time, we should only add tables
and keep the original ones unmodified.

To summarize, what features we want to include in the 0.2 release ?
categories, feeds and search, anything else ?
I order to get to users to migrate to fofredux we'll have to offer a
significant set of new features. Nonetheles, having an active
development team backing up the project is a "feature" strong enough
to convince a lot of people.

Carlos.

Re: Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Andrew T. <ajt...@hi...>]

I agree Carlos, I think having active development/continuation of FoF
will be a big pull for a lot of users. Fixing of current bugs, etc. in
the FoF SF site, active CVS development, etc.

So if we want to allow "dual running", then adding columns should be
ok as long as they aren't "necessary" for FoF to pick up on.

What's the vote for the 0.2 release features? I think there are 2 options:
1) Categories, Search, simplified architecture (less pages), keyboard contr=
ol
2) Search, arch, tags, encapsulated DB (for switching b/w PSQL and MySQL)

The primary question being - lots of new features now, or updated
codebase/support and new features later?

I vote for option 1 with the a roadmap for users describing what we
are working on and will come out approx when. Getting 0.2 out sooner
rather than later lets people know the fork is actually alive and to
start checking it out.

Andy

On 11/29/05, Carlos Kozuszko <ck...@gm...> wrote:
> I agree with Benjy, allowing the users run fof and fofredux
> simultaneously with the same db and tables, would allow them to choose
> more easily.
>
> I guess that at fofredux installation time, we should only add tables
> and keep the original ones unmodified.
>
> To summarize, what features we want to include in the 0.2 release ?
> categories, feeds and search, anything else ?
> I order to get to users to migrate to fofredux we'll have to offer a
> significant set of new features. Nonetheles, having an active
> development team backing up the project is a "feature" strong enough
> to convince a lot of people.
>
> Carlos.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Fofredux-devel mailing list
> Fof...@li...
> https://lists.sourceforge.net/lists/listinfo/fofredux-devel
>


--
Andrew Turner
ajt...@hi...        42.4266N x 83.4931W
http://highearthorbit.com              Northville, Michigan, USA
idealistic technocrat

Photos - http://flickr.com/photos/ajturner
Travel   - http://highearthorbit.com/projects/location/

Re: Re: Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Carlos K. <ck...@gm...>]

> I think there are 2 options:
> 1) Categories, Search, simplified architecture (less pages), keyboard con=
trol
> 2) Search, arch, tags, encapsulated DB (for switching b/w PSQL and MySQL)

I think we could live without tags and encapsulated in our first
release. Vote for 1 too.

> ...with the a roadmap for users describing what we are working on and wil=
l come out approx when.

That brings my attention to the fact that we will need a site for the
project in order to communicate news, readmaps, etc. Do you think a
wiki would do ? Something like the hibernate.org site would be a nice
site to have, although we could settle with a much more simple
version.

Carlos.

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Kevin <ke...@dr...>]

Andrew Turner wrote:

>I agree Carlos, I think having active development/continuation of FoF
>will be a big pull for a lot of users. Fixing of current bugs, etc. in
>the FoF SF site, active CVS development, etc.
>
>So if we want to allow "dual running", then adding columns should be
>ok as long as they aren't "necessary" for FoF to pick up on.
>
>What's the vote for the 0.2 release features? I think there are 2 options:
>1) Categories, Search, simplified architecture (less pages), keyboard control
>2) Search, arch, tags, encapsulated DB (for switching b/w PSQL and MySQL)
>
>  
>
#1     Let's do a feature freeze real soon and bugfix like crazy for the 
release.  I'll throw my tag code on a branch and leave it for later.  I 
haven't seen the keyboard navigation code but it sounds like a really 
nice feature to have.

Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

[Benjamin S. <bs...@cr...>]

> #1     Let's do a feature freeze real soon and bugfix like crazy for the 
> release.  I'll throw my tag code on a branch and leave it for later.  I 
> haven't seen the keyboard navigation code but it sounds like a really 
> nice feature to have.

It's implemented on my checked out copy, but it's buggy at the moment
(the navigation "misses" the entry a lot, and I have to figure out why).
I'll check it on a branch this afternoon so you can play with it if you
want.

Also, I haven't tested it anything but Safari and Firefox yet.

--Benjy