extragear/multimedia/amarok/src [POSSIBLY UNSAFE]

Dan Meltzer parallelgrapefruit at gmail.com
Sun Nov 16 18:18:34 CET 2008


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.

Dan,
>
> leo
>
> ---
> Leo Franchi                             (650) 704 3680
> Tufts University 2010
>
> lfranchi at kde.org
> leonardo.franchi at tufts.edu
>
>


More information about the Amarok-devel mailing list