extragear/multimedia/amarok/src [POSSIBLY UNSAFE]

[Alejandro Wainzinger]

On Sun, Nov 16, 2008 at 9:18 AM, Dan Meltzer
<parallelgrapefruit at gmail.com> wrote:
> On Sun, Nov 16, 2008 at 12:09 PM, Leo Franchi <lfranchi at kde.org> wrote:
>> On 16 Nov 2008, at 17:04, Dan Meltzer wrote:
>>
>>> On Sun, Nov 16, 2008 at 7:24 AM, Alejandro Daniel Wainzinger
>>> <aikawarazuni at gmail.com> wrote:
>>>>
>>>> SVN commit 884953 by awainzinger:
>>>>
>>>> Introducing the CollectionCapability.  Allows Collections to perform
>>>> actions on multiple items, and after revision of CollectionTreeView, will
>>>> streamline how actions are created.  Collections can now have Capabilities.
>>>>  IpodCollection is the first test driver for this, with ability to delete
>>>> multiple files at once.  No confirmation popup added yet, to keep
>>>> translators happy.  No regressions possible, since existing other
>>>> Collections will return 0 when asked for CollectionCapability.  Big commit,
>>>> may require clean rebuild.
>>>
>>> Didn't we all agree that this was a really good thing to save until
>>> _after_ 2.0 was released?  We're about to release an RC.
>>
>> Maybe it would be better to wait. But regarding what had been discussed, the
>> only thing that I can see from the thread is:
>>
>> a) you wanted it held from 2.0
>> b) others were opposed to delaying 2.0 for it
>>
>> but since we're not *delaying* 2.0, i dont think there was any consensus on
>> this issue at all. what do others think?
>
> Looking at the thread:
>
> Nikolaj voted for 2.0.1, or as soon as we could add it without
> affecting the release
> Jeff voted for roughly the same, but emphasised working on it as soon
> as the code freeze for 2.0 was over, and getting it into 2.0.1
>
> Now, heres the issue:
>
> The code freeze for 2.0 was in August.  It's now november.
> There are all sorts of bugs that could have been introduced with this
> commit.  It's brand new code, and we are really in a need to release
> this software.  One could argue that this is going to require another
> beta, as this code is untested by anyone but the author, and new code
> in a release canidate is not a great idea.  Beyond this code in
> particular, we need to look at the principle behind it.  It was
> agreed, in spirit if not in ironclad legalese, that new features
> (which this is) would not happen after the deadline without discussing
> them first.  The discussion agreed that it would make more sense to
> postpone this code until 2.0.1.. Yet, this morning, this code was
> committed without any further discussion beyond that.  We have rules
> about releases for a reason.  Let's follow them.

Since August, Amarok has moved from sqlite to mysqle, the playlist has
gotten major reworking, and so on, so I'm not sure we can argue that
we've been in code freeze.  It won't require another beta, since no
Collections other than the IpodCollection are currently affected.
Deletion of tracks was already implemented, just now it's more
convenient for iPods.

As mentioned before, I didn't see consensus on the matter in the
thread.  I also believe that people were referring to the total
reworking of the CollectionTreeView, including construction of
EditCapability-related actions etc., which I have not touched since I
am in agreement with the others that this should take place post-2.0.
Really, this only adds the support required for that reworking later
on, and adds deletion of multiple files for iPods now instead of
later.

Of course if there's a major objection to this commit, anybody else
please speak up.  I did not intend a rogue move here at all.

>
> Dan,
>>
>> leo
>>
>> ---
>> Leo Franchi                             (650) 704 3680
>> Tufts University 2010
>>
>> lfranchi at kde.org
>> leonardo.franchi at tufts.edu
>>
>>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>