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
<mailto: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 <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
<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 <mailto:marten@xxxxxxxxxxxxxxx>
_________________________________________________
Mailing list: https://launchpad.net/~__openteachermaintainers
<https://launchpad.net/~openteachermaintainers>
Post to : openteachermaintainers@lists.__launchpad.net
<mailto:openteachermaintainers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~__openteachermaintainers
<https://launchpad.net/~openteachermaintainers>
More help : https://help.launchpad.net/__ListHelp
<https://help.launchpad.net/ListHelp>
