quickly-talk team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

Hello!  So all of the non-blocked quickly work items for this cycle are
done.  There are two remaining refactorings I've got in mind, only one
of which I think is actually important for this cycle:

1) Refactor project_root to make upgrades safer/easier
2) Refactor some template code into the quickly module to make writing
new templates easier

#1 would be best to solve in time for natty.  #2 can safely wait, so I'd
like to focus on #1 in this email.

I've talked about this problem on this list before, and talked to Didier
about it in person at the rally in Texas.  Basically, I'd like to start
declaring bits of project_root as "owned by Quickly" and say that if you
break those bits, you bought it.

This would see almost all of project_root/python moved into a new python
module "python_quickly" (which would then get renamed to something like
"test_project_quickly").  The main bin/project wrapper would also be
owned by Quickly.  

Additionally, we would say that there is only one entry point into the
user's modifiable code.  This would make it easier to drop in existing
code into a new Quickly project.

I have a work-in-progress merge here:
https://code.launchpad.net/~mterry/quickly/refactor-project-root/+merge/48923

I have two concerns for further discussion:

A) Data and .ui files aren't addressed by this merge.  Since those can't
be split into modifiable and non-modifiable bits, I think we just need
to keep handling these specially in upgrade code.

B) How to upgrade 10.10 users to this new layout?  This is a big
question that I don't know how to answer.  Talking to Didier about it,
we were leaning towards just not supporting an upgrade path.  This is
consistent with our project's general stance towards refactoring (and
hopefully will be the last such no-upgrade refactor for a long time due
to the new layout).  The problem is that if the user added any code
anywhere, it would be prohibitively complicated to pull that out and add
it to the new skeleton customizable classes.

We could still try to handle old-layout projects for as long as
possible, so it's not like we need to tell everyone to start fresh.  We
just couldn't upgrade the user to the new layout.

Not being able to upgrade is somewhat soothed by the new ease of
dropping in existing code (the user could just drop in previous project
and keep trucking with a little bit of manual hooking up).   But in
general, upgrades wouldn't be done automatically.  How OK would such a
lack of upgradability be?

-- 
mterry