Amarok Testing (matej at laitl.cz)

[Matěj Laitl]

On 28. 11. 2012 Myriam Schweingruber wrote:
> On Wed, Nov 28, 2012 at 7:08 PM, Matěj Laitl <matej at laitl.cz> wrote:
> > On 28. 11. 2012 Myriam Schweingruber wrote:
> > > I think you misunderstand the reason I make a spreadsheet:
> > 
> > In fact, you gave no reason. :-)
> 
> Id did so in IRC, remember the #amarok.dev channel is where we talk
> about working on Amarok?

Myriam, you should have been a teacher, really! :-D

> > Hmm, I see. But what will be the *authoritative* source of information
> > currently available in [1]? I would certainly refuse to edit it in 2
> > places. In fact, I would refuse any violation of the DRY principle [2]
> > (DO read it!).
> > 
> > [1] http://amarok.community.kde.org/Development/Testing
> > [2] http://www.artima.com/intv/dry.html
> 
> The wiki, of course, and don't worry, once we have a spreadsheet I
> will happily volunteer to keep it updated.

Ohkay, ohkay ohkay, that's fine with me then!

Do you want me to try to hack a Python script to convert wiki source to CSV 
which can be imported by Google Docs? (if you plan to keep do spreadsheet up-
to-date, this would be a solution, with some downsides)

> But the sad truth is that the Testing thing in the wiki ias a very ugly
> draft I put together some time ago, none of the developers so far thought to
> give a hand on it,

I did! (and Bart did too a little) As a teacher, you should try to question 
and support your claims, perhaps by looking at the page history. :-)

> and who else than the developers are the ones who know what should
> be tested... the iPod section for example still talks about Winter
> 2011, go figure.

Right, but the "As of winter 2011, newest iPhones/iPod touches/iPod nano 
touches are not supported by libgpod" still holds even today. But I'll reword 
it to use libgpod version instead.

> I just can't maintain everything in the wiki, a
> minimum of help from the other team members is needed.

Yes, sure. In fact, this was my intent, to let developers have one good place 
to put non-code: the wiki.

> >> The final version of the spreadsheet is Open DOcument format can then
> >> be added to the source, but right now it needs to be made and I would
> >> really welcome some help...
> > 
> > ODS is a horrible thing to put under git. If a spreadsheet is really
> > advantageous over list-like [1], I think it should be done in the wiki. Or
> > added to Amarok source in some diff-able form, e.g. [3]. I will then
> > create a script to export it to a spreadsheet for you. :-)
> > 
> > [3] http://docutils.sourceforge.net/docs/user/rst/quickref.html#tables
> 
> Sorry, no, I am NOT volunteering to make that tables in the wiki, it
> is a giant PITA to make it in the wiki and I already have enough work.

I understand. But my point is void now when I know the current wiki page will 
remain authoritative.

> Spreadsheet is much faster and easier, and I don't see how an ODS
> document can not be put in git for reference. If you don't like it,
> please suggest something better that doesn't make the workload o
> triple.

If the info stays (and gets updated) in the wiki, I think there's no need to 
put a differently-formatted copy of that information into repository.

> > > if you were on IRC you would know what I am doing right now and why...
> > 
> > Sorry, I cannot be on IRC all the time. Its interactivity hurts my
> > productivity during the day.
> 
> You can just not look at it if you need to work, remember one can
> minimize windows on the screen :) But at least you would not miss half
> of the discussions going on

If the stuff matters, *please* post it to amarok-devel. Really, I really think 
that for non-trivial ideas, mailing lists are a much better place to formulate 
them, discuss and argue.

> PS. I have Konversation open and use the ZNC bouncer so at least I
> have the logs, but I don't have to look at it all the time and can
> work without it being disturbing.

I also suck at reading backlogs, but hey, I'll go forward and setup a bouncer 
now that awesome KDE Sysadmins (Hi Ben!) offer one.

Cheers,
		Matěj