← Back to team overview

quickly-talk team mailing list archive

Re: Introduction and a question about quickly workflow

 

Le 19/06/2012 16:20, Rick Spencer a écrit :
On Tue, Jun 19, 2012 at 4:34 PM, Michael Terry
<michael.terry@xxxxxxxxxxxxx> wrote:
On 19/06/12 00:58, Jeff Spaleta wrote:
Anyways my long term goal is to make a functional alternative template
for Fedora so apps developed with quickly can package/publish/submit
against a Fedora target, without disrupting the ability to
package/publish/submit Ubuntu. And then from there an ebuild template
perhaps.

Sounds great!


quickly pull to update my local files with the latest mainline branch
quickly edit : this works just fine.
quickly push to commit my changes into a personal branch
quickly merge-request to send a notice of a merge request through lp
for David to review.

Thinking about this, I fear it will be a rabbit hole, where we'd have to
keep adding thin bzr-veneers to quickly in order to keep up the illusion.

You identified the basic elements of collaboration: pull, edit, commit,
push, merge-request.  But to support those, we'd need a couple more.

- A "quickly diff" so the user knows what they are pushing.
- Probably a "quickly resolve" to deal with conflicts after a pull.

What's the motivation to abstract the VCS?  The ubuntu-application template
can just say "use bzr to collaborate, we've set it up for you already" and
the fedora-application template can say the same, but for git.

We don't have strong decision making guidelines for what Quickly chooses to
abstract and what it doesn't.  But I'd say that since the layer here would
be so thin and collaboration isn't an early-project kind of friction that
risks killing a new developer's motivation, I'm happy to just point the user
at an external tool.  I'm actually curious why we have "quickly save".
The only "rule" that we had in quickly was that everything should be
"easy and fun".

We put in quickly save so that the user didn't have to worry about
learning what it means to add and commit, but would get a roll back
point.

HTH

I think as well that we should prevent and not going crazy in the number of commands and only keep what is interesting for the opportunistic developer which is what Quickly is focussing on.

Didier


References