openteachermaintainers team mailing list archive

[Milan Boers <mail@xxxxxxxxxxxxx>]

Hi Marten, Cas,

A late reply from me.
For the first blueprint, I would say the first solution is a nicer
solution. We are occasionally seeing people with older OpenTeacher versions
encounter bugs that are already solved. That is why I think at least
notifying people of newer versions is, in general, a good idea. Whether
OpenTeacher can also automatically install them is not the most important
factor. It's not really critical for users to use the latest version, like
it is for applications with many security updates.

Closing the second blueprint is fine for me. I don't think the current
documentation is too long or obstructive.

Running over the blueprints seems like a good idea to me. I might like to
implement some if I find the motivation to work on OT again. I don't see
that happening in the near future, but maybe I will some time.

--
Milan


On Wed, Feb 19, 2014 at 8:10 PM, Marten de Vries <marten@xxxxxxxxxxxxxxx>wrote:

> Hi Cas, Milan,
>
> Today I gave the blueprints page a look, there are a few things in design
> stage that have not been discussed for quite a while. In this mail I give a
> summary of the last discussion so we can either discuss it further
> resulting in a design decision or close the blueprint. My opinions are
> below each subject, I'd like yours. :)
>
> *Blueprint 1:*
> Starting with: https://blueprints.launchpad.net/openteacher/+spec/update-
> manager - last part of the whiteboard:
> ' While this essentially worked (and I guess still works), it does depend
> on the module directory being writable. That means, we need to change the
> packagers quite a lot. Also, I still think Linux users don't like this.
> Maybe we should think about some alternate solutions:
> 1)
> - use repositories for linux distro's
> - use a small script that downloads new MSI's and upgrades them for windows
> - something similar for mac?
>
> Should be quite a lot easier now that we have automated packagers.
>
> 2)
> Do nothing. Essentially what we're doing now for already quite some
> releases :P.'
>
> I personally think option 2 might not be such a bad idea, although 1 is
> acceptable to me too (it's doable now that completely automatic packaging
> is completed)... The old solution is out for me (not surprising since I
> wrote that last piece of the whiteboard).
>
> *Blueprint 2:
> *https://blueprints.launchpad.net/openteacher/+spec/welcome-screen - I
> added a documentation button on the start screen instead, I think that's
> enough to close this one, but I'd like to hear your opinions.
>
> Most other blueprints (those with less priority I mean) seem like nice
> ideas to me, but for a lot of them I don't think I'll ever implement them.
> Maybe we should run over the list once (IRC meeting?) and just check if at
> least one of us might be interested somewhere in the (far) future, and if
> not, close them.
>
> Best regards,
>
> --
> Marten de Vries
> marten@xxxxxxxxxxxxxxx
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openteachermaintainers
> Post to     : openteachermaintainers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openteachermaintainers
> More help   : https://help.launchpad.net/ListHelp
>