Re: Bundles in Agora

[Carnë Draug]

You forgot to include the mailing list

On 12 October 2012 23:44, Wendy Liu <address@hidden> wrote:
> Thanks to everyone who replied. One of the reasons I wanted feedback is
> because the feature specifications I've been given for Agora are not always
> complete, and so I have to do quite a bit of creative interpretation
> (sometimes, misinterpretation) from time to time. At times, this can result
> in me making design decisions that are not what is best for the Octave
> community, and since I'm not really part of the Octave community myself, I
> don't always realise this. So please, feel free to question any decision I
> make that you don't feel comfortable with -- I just want to make Agora
> useful for the community.
>
> In any case, a lot of good points were brought up, and I'm going to do my
> best to address them all now:
>
> On 9 October 2012 15:01, Juan Pablo Carbajal <address@hidden> wrote:
>>
>> Regarding the visualization of the contents of a Bundle. I think that
>> showing the list of files would be enough (avoiding unpacking, but
>> just listing the content), anyways I respect your design decision.
>> Would it be possible to get all the structure collapsed by default and
>> if the user wants to see the details of the file their can expand it?
>> Otherwise it is quite a cumbersome overview of the bundles (some of
>> them can have hundreds of files!).
>
>
> This sounds much better. I will definitely do this.
>
> On 9 October 2012 15:01, Juan Pablo Carbajal <address@hidden> wrote:
>>
>> Regarding your future stuff. "A bundle management system (so that
>> users can rename, delete, and add files after creating a bundle)", I
>> think wee need more basic functionality before this. For example I
>> think a good working situation would be to allow for the upload of a
>> new version of the bundle (so a completely new zip file), but not
>> editing the internals and to be able to see in your user account which
>> bundles you have uploaded. In this regard, adding more functionality
>> is for me (stress on the "me") secondary. Most important would be the
>> rating/feedback functionality. Nowadays we use the feature request
>> forum (https://sourceforge.net/p/octave/feature-requests/) and there
>> is always ping-pong of suggestions and new versions. This is for me of
>> utter importance because that is the first contact with developers or
>> people that have more experience coding for Octave.
>
>
> The rating/feedback functionality is a good idea. Do you have any thoughts
> on how it should work? For instance, should the rating be a number (say, out
> of 5), and should anonymous users be allowed to rate things? The more ideas
> you have for this the better!
>
> (I'll address the versioning feature later on.)
>
> On 9 October 2012 15:01, Juan Pablo Carbajal <address@hidden> wrote:
>>
>> Also, even before the "editing the internal of the bundle"
>> functionality, I would prioritize on the licensing part. That is,
>> offering the uploaders the possibility to add license files to their
>> bundles, chosen from a predefined list. Carnë has written code to do
>> this and also as the collection of "accepted" licenses in the folder
>> admin of Octave Forge.
>
>
> Sure, I can do that. I can't quite find the the code and list of licenses
> that you're talking about, though - is it in this folder?
> http://sourceforge.net/p/octave/code/11246/tree/trunk/octave-forge/admin/

He's talking about this script

http://sourceforge.net/p/octave/code/11207/tree/trunk/octave-forge/admin/copyright_fix.pl

There's a block of documentation on how it works near the top. Let me
know if you have problems understanding it.

> On 9 October 2012 16:10, Carnë Draug <address@hidden> wrote:
>>
>> You may want to take a look at how it's done in launchpad
>>
>> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/view/head:/apport/source_bzr.py
>> The line numbers have links, and you can copy and paste without
>> problem. I don't know the details of their solution but it works. And
>> it's free under AGPL.
>
>
> Thanks for the suggestion. Unfortunately, Launchpad doesn't appear to
> incorporate line-wrapping, meaning that if a line is too long for the code
> box (horizontally) then the user will just have to scroll. That was one of
> the earlier implementations I had (since line numbers are really easy to
> work with in that situation), and it was brought up on the mailing list that
> having to scroll horizontally could be cumbersome, which is why I re-did it
> this way. If you have any other ideas on this, though, I'd be glad to hear
> about them.
>
> On 9 October 2012 16:10, Carnë Draug <address@hidden> wrote:
>>
>> I don't think this was actually part of the original design.
>>
>> On 9 October 2012 21:01, Juan Pablo Carbajal <address@hidden> wrote:
>> > Regarding your future stuff. "A bundle management system (so that
>> > users can rename, delete, and add files after creating a bundle)"
>>
>> I second Juan that there's more important things and more: do NOT
>> implement this. After a release is made, it should not be changed.
>> What would happen if we went back, pulled down the 3.6.0 sources,
>> fixed a bug and released it again with the same version number? The
>> whole version system becomes useless.
>
>
> On 9 October 2012 17:48, c. <address@hidden> wrote:
>>
>>
>> On 9 Oct 2012, at 22:10, address@hidden wrote:
>>
>> > Regarding your future stuff. "A bundle management system (so that
>> > users can rename, delete, and add files after creating a bundle)", I
>> > think wee need more basic functionality before this.
>>
>> Actually, if possible I'd prefer if you could NOT implement this
>> functionality at all.
>> I'd rather have users upload complete releases of their bundles.
>> For managing incremental changes to single files I believe using a
>> revision control system
>> would more appropriate.
>>
>> That's just me though ...
>
>
> That's true. I didn't think about that. It was more of a passing thought I
> had about how to make it easier to manage bundles. But I agree, that is not
> a good idea. Just to make sure I understand what the desired functionality
> is: users should have to upload a new zip/tar/etc file to release a new
> version of their bundle? And version numbers should be 1, 2, 3 etc rather
> than, say, 3.6.0?

Yes. And the user should not be able to specify version numbers. They
are done automatically with each upload. He also should not be able to
put them down and replace with a different one.

> -Wendy