Monday, 17 July 2017

Re: Polling for opinions on removing vm-builder, sandbox-upgrader and auto-upgrade-tester

We're certainly continuing to use our version, and tweaking/adapting
as we go; anybody wants to submit bug reports (or patches!) is very
welcome. Some of the changes we've made to keep using the tool were
trivial, making it likely there are more active users than it appears
- anyone using vmbuilder is technical enough to see bug, find previous
report with simple fix, apply fix and continue being productive; and
not bother to report "me too" or similarly trackable behaviour.

So if you want to define us as "upstream" we'd be proud to be making a
contribution (but in the end we're just scratching our collective itch
and have found nothing that does it better in the context we work in
(small-medium size deployments on multiple sites)).

We'll review the open bugs on Launchpad and any we are up to
addressing, as sys admins rather than devs ;) , we'll open an issue
report on our fork (and report back to Launchpad once fixed?). Sound
like a way forward?


On 18 July 2017 at 06:41, Christian Ehrhardt
<[email protected]> wrote:
> On Fri, Jul 14, 2017 at 10:52 AM, Christian Ehrhardt
> <[email protected]> wrote:
>
>> Therefore this is a final poll for objections, before pushing harder on
>> the removal of the whole set of:
>> - vmbuilder
>> - sandbox-upgrader
>> - auto-upgrade-tester
>>
>
> On this thread there were no reports on any active users of the tools so
> far. Still looking for any feedback on that part - also a nack to confirm no
> more (or never) using it will help the decision.
>
>
> In addition it turns out that due to issues in vm-builder a removal was
> considered in zesty as well [1]
>
> Yet OTOH there was some feedback on a number of forks.
> - by Vacheslav Anzhiganov [2] [3] [4]
> - and Chris Puttick [5] [6]
>
> I appreciate that you two picked up the work on that, you might even combine
> your efforts.
> The latter seems slightly more active looking at the changes.
> Also Serge offered to help SRUing fixes if someone else ensures that the
> latest upstream works, thanks Serge!
> But since we need to make a decision I wanted to ask you two directly, if
> you are willing to continue to maintain it as "the upstream" of the project,
> handle bug reports and so on.
> - If you do so it would be great if you could pass through [7] and try to
> address some of them, coordinate with Serge and me to upload a new one to
> Artful after this and we can consider SRUs from there
> - If not - fine as well - we will remove it from the archive and it can
> continue to live outside of the archive (you could consider [8] as packaging
> alternative if you'd prefer a more direct way to deliver your code).
>
>
> [1]: https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/1618899
> [2]: https://launchpad.net/~vanzhiganov
> [3]: https://github.com/vmbuilder/vmbuilder
> [4]: https://pypi.python.org/pypi/VMBuilder
> [5]: https://launchpad.net/~cputtick
> [6]: https://github.com/newroco/vmbuilder
> [7]: https://bugs.launchpad.net/ubuntu/+source/vm-builder
> [8]: https://snapcraft.io/
>
>
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd



--
@putt1ck
putt1ck.blogspot.com
http://twoten.is
skype: putt1ck

Opinions in this email are my own and may not reflect that of my
clients, past employers, associates, friends, family, pets etc..

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel