quickly-talk team mailing list archive

[tony byrne <tony.badwolf@xxxxxxxxx>]

I think "upgrading" the user's code is fraught with risk. Most users
would not be contributors but could easily bug-fix some of the quickly
supplied code in their project. If an upgrade is automatic it would
need to compare the user's code with the maverick supplied code, or
perhaps even the lucid codebase, before overwriting. Perhaps the
upgrade could be a user controlled process similar to upgrade-manager,
listing the changes and allowing partial upgrades.

 Do you intend to upgrade projects or the templates in
~/quickly-templates or both ? What about chains of templates or
projects derived from ~/quickly-templates/my_template ?

Assuming that the user's edits to their code "breaks" quickly supplied
code seems like Cathedral thinking. It seems to me best to offer the
best template/source tree to the user that we can then leave them to
it. Poking changes into it ever 6 months seems wrong.

On 08/02/2011, Michael Terry <michael.terry@xxxxxxxxxxxxx> wrote:
> 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
>