On Monday 02 June 2008 14:47, Florent Daigni?re wrote:
> * Matthew Toseland <toad at amphibian.dyndns.org> [2008-06-02 14:15:02]:
> 
> > Okay, what issues do we have here?
> > 
> > 1. The processes page takes longer than the copying files page. In fact, 
most 
> > of the time of the installer is occupied by the processes page.
> > 
> > IMHO the solution to this is to bundle everything which is essential with 
the 
> > base installer. Then the processes page will take much less time. Also we 
> > won't need a separate bundle-installer, so it will be easier to use in 
places 
> > where the Freenet website is blocked. The downside is the installer will 
be 
> > significantly bigger.
> 
> I'm not convinced about that

Why? It won't be huge, if we don't bundle any unnecessary Huge Stuff (see 
below). And it's not small now.
> 
> > 2. The installer shouldn't download Thingamablog and Thaw. They are huge, 
we 
> > have not audited the code, and users can get them if they want them. 
> > Debundling them would mean that as soon as we open the browser the 
Processes 
> > page will have completed, and the user can click Next and go on to 
creating 
> > icons. There seems to be a consensus on debundling, at least between Ian 
and 
> > Nextgens. :) I think a policy of not bundling anything we can't code 
review 
> > is reasonable, and clearly code reviewing Thingamablog for example would 
be a 
> > massive undertaking and isn't appropriate at this time. I do think we 
should 
> > keep the current plugins, however most of them are small. Even if we 
include 
> > the WoT plugin, that is also likely to be reasonably small for the 
> > foreseeable future.
> 
> Ok, let's get rid of them then

For reasons of code reviewability?

Further to the above, I do actually review Thingamablog commits, however I 
haven't reviewed the original, and it's not really widely enough used that we 
can assume it to be safe? However, I do disagree with Ian's assertion that 
nothing we don't own is reviewable: it is much easier to hide bugs in C 
because you have buffer overflows, format string vulnerabilities and so on. 
In Java, well written code *can* be reviewed, although of course more subtle 
bugs may slip through the net. Also I review jSite commits (I dunno whether 
the original on which the diffs are applied was reviewed though).
> 
> > 3. Is it possible to change the names of the two panels? Copying Files vs 
> > Setting Up Freenet, perhaps?
> 
> We could get rid of one of the panel before the processing one

Good idea.
> 
> > 4. Is it possible to open the browser after closing the installer rather 
than 
> > in the Processes page?
> 
> Not "cleanly" but we could do a workaround time-delaying the browser
> startup.

I'm not convinced that's better than the alternative.
> 
> > 5. Icons: We need proper icons for our various shortcuts. On unix the 
> > situation is worse: We have no icons. On Windows, Browse Freenet has the 
> > bunny icon and the rest don't have anything.
> 
> Well provide me icons and maybe I'll consider using them :p

https://bugs.freenetproject.org/view.php?id=2409
https://bugs.freenetproject.org/view.php?id=2026
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080602/d517c041/attachment.pgp>

Reply via email to