quickly-talk team mailing list archive

[Jeff Spaleta <jspaleta@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 19, 2012 at 7:20 AM, Rick Spencer
<rick.spencer@xxxxxxxxxxxxx> wrote:
> 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.

Two things:


1) for a second opportunistic contributor to a quikly project a bzr
"push" isn't so obviously a simple one-liner.  For example
for qreator.  bzr push  lp:~jspaleta/qreator    results in an error.
I need something like lp:~jspaleta/poop/qreator

Why? I don't know.. seems pretty arbitrary lp specific syntax to me.
And thus confusing to that second opportunistic developer.. who can't
necessarily rely on the primary opportunistic developer to help with
the bzr who uses quickly to generate the project instead of
interacting with bzr and launchpad the traditional way.  Quickly push
could standardize the branch naming a bit and take some of the
unknowns out the push process.

Now looking beyond the ubuntu template to a template that supports a
hoster which uses git of hg....  they won't necessary have these "too
short to be a branch name" limitations. If all of quickly's template
supported a standardized  "push" for simple opportunistic patch
creation, you cut down on the some of the confusion which is going to
come when quickly projects are not all lp/bzr based.


2)what about firing off merge proposals from quickly?
Assuming things have been pushed via bzr into a personal lp branch by
the second contributor to a project..by any means available...
Can quickly streamline the process of pinging the primary developer of
the project for the merge proposal by scripting the launchpad
interaction?
I take it this is still documents the best practices on how to do a
merge proposal back to mainline in launchpad?
https://dev.launchpad.net/UsingMergeProposals


Did I say 2 I meant 3 things

3) How about dummy commands which provide breadcrumbs to the second
opportunistic developer on how to prep a change for review?
    quickly push : "You'll need to use bzr directly... learn how"
    quickly merge-request: "Look here for how to manage merge
proposals in launchpad"
    Or have quickly save breadcrumb the next steps.....
  "Hey you made a local change and saved it into a local bzr branch.
You aren't listed as part of the project's development team. Want a
project developer to review your patch? Go look here: <url> for the
process of submitting your changes for review and inclusion."

-jef