Re: git workflows for general Ubuntu development

[Robie Basak]

I've replied in much more detail on the vcs-pkg-discuss list[1].

On these specific questions:

On Tue, Nov 15, 2016 at 09:57:56AM +1300, Michael Hudson-Doyle wrote:
> This is pretty exciting! Do you think your work will fulfil the goals of
> the UDD project or is there still some stuff that's out of scope?

I'm not sure. Our goal was to meet our needs for "Ubuntu merges" only.
Any other use cases are a happy coincidence. Is there a list of the UDD
goals anywhere? It seems to me that it is quite possible to fulfill most
use cases using our imported trees. Whether developers want to do this
or not is another matter.

> The two questions I have (which are touched on but not afaics really
> answered in the notes are) 1) how does this work if I already maintain the
> packaging for some package in git?

This should work well I think, though we haven't tried it. I believe
that if you just started pushing your tree as "upload tags" to the tree
the importer uses, the importer will integrate everything and it will
Just Work. We'd need to do some testing to check that this is true
before recommending anyone commit to this though.

Historical stuff should work fine too, if it is possible to tag your
tree appropriately before the importer runs for the first time.

> packaging for some package in git? 2) what about dgit?

More on this in my vcs-pkg-discuss post. I think it may be possible to
have bidirectional communication with dgit, so dgit client side tools
would work fine. But this isn't on our roadmap.

On Tue, Nov 15, 2016 at 01:14:01AM +, Colin Watson wrote:
> On Mon, Nov 14, 2016 at 04:58:44PM -0800, Nish Aravamudan wrote:
> > 2) dgit does not fully meet our needs at this time. It's going to be
> > something Robie covers in more detail in the UOS session, but hopefully
> > he'll be able to respond here, as well.
> 
> I think there's the follow-up question here of "why not improve dgit to
> meet our needs?".  That was certainly always what I envisioned happening
> when I was sketching out preparatory work for this on the Launchpad
> side; I'd already done some initial preparation to get it working for
> us; and there are some problems (perhaps not fatal, but not necessarily
> trivial) associated with having more than one potential importer, not to
> mention the duplicated effort.

FTR, I've answered this (or at least introduced some of my reasoning) on
the vcs-pkg-discuss list[1].

[1] 
http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/2016-November/000909.html


signature.asc
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: git workflows for general Ubuntu development

[Colin Watson]

On Mon, Nov 14, 2016 at 04:58:44PM -0800, Nish Aravamudan wrote:
> 2) dgit does not fully meet our needs at this time. It's going to be
> something Robie covers in more detail in the UOS session, but hopefully
> he'll be able to respond here, as well.

I think there's the follow-up question here of "why not improve dgit to
meet our needs?".  That was certainly always what I envisioned happening
when I was sketching out preparatory work for this on the Launchpad
side; I'd already done some initial preparation to get it working for
us; and there are some problems (perhaps not fatal, but not necessarily
trivial) associated with having more than one potential importer, not to
mention the duplicated effort.

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: git workflows for general Ubuntu development

[Nish Aravamudan]

On 15.11.2016 [09:57:56 +1300], Michael Hudson-Doyle wrote:
> On 15 November 2016 at 01:51, Robie Basak  wrote:
> 
> > On the server team, we've been working on a process that uses git to do
> > our "Ubuntu merges". As a consequence, we now have a mechanism that can
> > import package histories into git on Launchpad. We think that this work
> > opens up a bunch of new possibilities, such as for drive-by contributors
> > submitting merge proposals entirely through git.
> >
> 
> This is pretty exciting! Do you think your work will fulfil the goals of
> the UDD project or is there still some stuff that's out of scope?

Is there a list of those goals? I have never used UDD and wasn't
contributing to Ubuntu when it was in-use.

> > We'll be talking about our work tomorrow, as part of the Ubuntu Online
> > Summit. The session page is at
> > http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/
> > and is currently scheduled for 2016-11-15 18:00 UTC. Times may change,
> > so be sure to check the schedule tomorrow.
> >
> > I originally wrote about this in August 2014
> > (https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html).
> > We've come on a long way since then. Our automated git imports preserve
> > histories. Where relevant, Ubuntu packages are correctly parented from
> > their Debian origins. We hope to start running this live soon, which
> > will import package uploads into our git trees as they happen rather
> > than on-demand. Once this is live, anyone will be able to easily clone
> > from the "current" Ubuntu packaging git trees, which we think is useful
> > in itself.
> >
> > If you're interested, we'd love your feedback. What are your use cases?
> > What sort of workflows would you like to see? You can see some further
> > notes of ours as they form in the pad on the session page linked above.
> > What have we missed?
> >
> 
> The two questions I have (which are touched on but not afaics really
> answered in the notes are) 1) how does this work if I already maintain the
> packaging for some package in git? 2) what about dgit?

1) No impact to you -- we currently don't have plans to 'import the
world' (meaning all source packages). If the importer were to run
against that source package, though, it would simply import the source
package(s) according to Launchpad's publishing history in Debiand and
Ubuntu. What is most interesting, perhaps, is that you can push
'upload/' tags to the repository the importer uses (presuming
permissions) and the importer will recognize that tag, compare it to the
corresponding upload in Launchpad (source package comparison) and if
they match, it will use the upload-tag as the imported-commit, and
parent it into the history. So if you have broken-out changes (and this
is true for merges too) in your git tree, you can use the upload/ tags
to reflect that. There is no presumption of common ancestry, so the
resulting history (if you have a separate repository right now), might
look a little strange, but it should work :)

It's a bit hand-wavy written out like that, so feel free to ping me on
IRC (nacc) and I'll try and help clarify.

2) dgit does not fully meet our needs at this time. It's going to be
something Robie covers in more detail in the UOS session, but hopefully
he'll be able to respond here, as well.

Thanks,
Nish

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: git workflows for general Ubuntu development

[Michael Hudson-Doyle]

On 15 November 2016 at 01:51, Robie Basak  wrote:

> On the server team, we've been working on a process that uses git to do
> our "Ubuntu merges". As a consequence, we now have a mechanism that can
> import package histories into git on Launchpad. We think that this work
> opens up a bunch of new possibilities, such as for drive-by contributors
> submitting merge proposals entirely through git.
>

This is pretty exciting! Do you think your work will fulfil the goals of
the UDD project or is there still some stuff that's out of scope?


> We'll be talking about our work tomorrow, as part of the Ubuntu Online
> Summit. The session page is at
> http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/
> and is currently scheduled for 2016-11-15 18:00 UTC. Times may change,
> so be sure to check the schedule tomorrow.
>
> I originally wrote about this in August 2014
> (https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html).
> We've come on a long way since then. Our automated git imports preserve
> histories. Where relevant, Ubuntu packages are correctly parented from
> their Debian origins. We hope to start running this live soon, which
> will import package uploads into our git trees as they happen rather
> than on-demand. Once this is live, anyone will be able to easily clone
> from the "current" Ubuntu packaging git trees, which we think is useful
> in itself.
>
> If you're interested, we'd love your feedback. What are your use cases?
> What sort of workflows would you like to see? You can see some further
> notes of ours as they form in the pad on the session page linked above.
> What have we missed?
>

The two questions I have (which are touched on but not afaics really
answered in the notes are) 1) how does this work if I already maintain the
packaging for some package in git? 2) what about dgit?


> Note that developer time, as always, is limited. We've developed what we
> have so far to speed up our own work. Our use cases are probably quite
> different from non-core contributors. Possibly enabling the drive-by
> contribution use case is a happy consequence. Volunteers able to work on
> additional things are welcome to join us. However I am specifically
> looking for things we can tweak without much effort that will help
> others. I regret that we don't have the time to take on a big project
> that doesn't benefit our own use cases. So please understand that if you
> make a proposal that involves significant developer work, it is unlikely
> to happen unless you also find developers to volunteer their time to
> work on it.
>
> At the UOS session we'll be able to discuss this in real-time on Google
> Hangouts and concurrently on IRC. But our time in the session is limited
> to one hour, so replying to this thread to first distill any
> conversation would be helpful if possible.


Cheers,
mwh
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

git workflows for general Ubuntu development

[Robie Basak]

On the server team, we've been working on a process that uses git to do
our "Ubuntu merges". As a consequence, we now have a mechanism that can
import package histories into git on Launchpad. We think that this work
opens up a bunch of new possibilities, such as for drive-by contributors
submitting merge proposals entirely through git.

We'll be talking about our work tomorrow, as part of the Ubuntu Online
Summit. The session page is at
http://summit.ubuntu.com/uos-1611/meeting/22710/git-based-merge-workflow/
and is currently scheduled for 2016-11-15 18:00 UTC. Times may change,
so be sure to check the schedule tomorrow.

I originally wrote about this in August 2014
(https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html).
We've come on a long way since then. Our automated git imports preserve
histories. Where relevant, Ubuntu packages are correctly parented from
their Debian origins. We hope to start running this live soon, which
will import package uploads into our git trees as they happen rather
than on-demand. Once this is live, anyone will be able to easily clone
from the "current" Ubuntu packaging git trees, which we think is useful
in itself.

If you're interested, we'd love your feedback. What are your use cases?
What sort of workflows would you like to see? You can see some further
notes of ours as they form in the pad on the session page linked above.
What have we missed?

Note that developer time, as always, is limited. We've developed what we
have so far to speed up our own work. Our use cases are probably quite
different from non-core contributors. Possibly enabling the drive-by
contribution use case is a happy consequence. Volunteers able to work on
additional things are welcome to join us. However I am specifically
looking for things we can tweak without much effort that will help
others. I regret that we don't have the time to take on a big project
that doesn't benefit our own use cases. So please understand that if you
make a proposal that involves significant developer work, it is unlikely
to happen unless you also find developers to volunteer their time to
work on it.

At the UOS session we'll be able to discuss this in real-time on Google
Hangouts and concurrently on IRC. But our time in the session is limited
to one hour, so replying to this thread to first distill any
conversation would be helpful if possible.

Robie Basak
Ubuntu Server Team


signature.asc
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss