moc-svn.tcz - improper info file format

[bmarkus]

There is an improper info file for moc-svn.tcz and doesn't comply to TC standard and quality:

1) Description is extremely lon
2) Version is not indicated (no version number, SVN date, etc.)
3) Submissin date (current) improperly formatted, on the WEB results empty date field

 

Title:          moc-svn.tcz
Description:    MOC (music on console) is a console audio player for LINUX/UNIX designed to be powerful
      and easy to use. You just need to select a file from some directory using the menu similar to
      Midnight Commander, and MOC will start playing all files in this directory beginning from the
      chosen file. There is no need to create play lists like in other players. If you want to combine
      some files from one or few directories on one play list, you can do this. The play list will
      be remembered between runs or you can save it as an m3u file to load it whenever you want.
      
      Need the console where MOC is running for more important things? Need to close the X terminal emulator?
      You don't have to stop playing - just press q and the interface will be detached leaving the
      server running. You can attach it later, or you can attach one interface in the console, and
      another in the X terminal emulator, no need to switch just to play another file.
      
      MOC plays smoothly, regardless of system or I/O load because it uses the output buffer in a
      separate thread. It doesn't cause gaps between files, because the next file to be played is
      precached while playing the current file. Internet stream (Icecast, Shoutcast) are supported.
      Key mapping can be fully customized.
      
      Supported file formats are: mp3, Ogg Vorbis, FLAC, Musepack, Speex, WAVE, AIFF, AU (and other
      less popular formats supported by libsndfile. New formats support is under development.
Version:        svn
Author:         Damian Pietras
Original-site:  http://moc.daper.net
Copying-policy: GPL v2
Size:           196K
Extension_by:   blofsy
Comments:       Supported formats in this version: .ogg .flac .vw .mpc .mp3
      Source,licence and build instructions:
      svn://daper.net/moc/trunk
Current:        Wed Jul 28 18:58:56 CEST 2010, moc-svn svn

[blofsy]

1) I will take a look to the stuff you mentioned about the zero lenght file in the root.  ( if I have the time)
2) I didn't find any description regarding the proper formatting of the date or description of an extension. If something like that would be present I will of course create future extensions with that in mind.
3) There is no svn version simply because I don't have time for adding it manually and everything compiles automatically. If you don't like it this way I recommend you to request the deletion of this extension. MOC is pretty buggy and I don't use this package anymore and don't plan to maintain it either.

cheers

[Jason W]

I edited the moc-svn.tcz.info to conform more to standard.  In particular:

example date format is 2010/08/23  for Aug 23 2010. 

Short description, with the comments area for longer explanation.

In general, existing info files are good to use a guide for format.

[bmarkus]

Unfortunately I can't left uncommented this post because it shows few important points.

2) I didn't find any description regarding the proper formatting of the date or description of an extension. If something like that would be present I will of course create future extensions with that in mind.

Joining to a community first thing to do is to listen and learn its rules. Usually most important rules are not written, but followed by community members. It takes only
10 minutes to browse how extensions are submitted and while they represents different style easy to see what is common. Also different format can be seen at first glance browsing repository WEB.

If it is not important or not checked by the uploader it indicates a poor quality job and ignorance to community rules.

3) There is no svn version simply because I don't have time for adding it manually and everything compiles automatically. If you don't like it this way I recommend you to request the deletion of this extension. MOC is pretty buggy and I don't use this package anymore and don't plan to maintain it either.

Why the Hell an extension is submitted, if

1) It is already there in the repo
2) Why original maintainer is not asked or discussed wether there is a need for an update, why current is not updated, etc.
3) Why an extension is submitted if declared by the uploader to be buggy and he itself is not using it?

And finally, why such extensions are accepted and published without a minimal control by TC team? It is the SLAXish way of publishing community made module which finally kills SLAX and to destroy result reached till now.

[blofsy]

I edited the moc-svn.tcz.info to conform more to standard.  In particular:

example date format is 2010/08/23  for Aug 23 2010. 

Short description, with the comments area for longer explanation.

In general, existing info files are good to use a guide for format.

Ok, I will add this description to the wiki.

[Jason W]

Bmarkus, moc-svn.tcz did not overwrite your moc.tcz extension.  I removed moc.tcz upon your request, though I did not understand why you wanted it removed.   I am not aware of a rule that prevents an svn version of an extension to exist in addition to a stable version.  Between me and Curaga, there are at least 4 Mplayers, each a different build with a different purpose.  And you don't see Curaga and I fighting over that.  But if either of us had an issue, we could discuss it like adults.

I agree that info files should follow proper format, and the audit script even checks for proper field entries.  But it is not possible to check for every conceivable error that may occur.  It is always possible for errors to occur in life as well as in TC.

There have only been two of your extensions to date that I am aware of that were overwritten by an update from someone else.  When the first time happened, I wrote the sticky post on the subject.  And I have never heard of any occasion since then where anyone's extension was overwritten.  Until your "I am quitting" post.  

Instead of contacting the submitter of moc-svn if you had concerns over the existence of an svn version, you simply told me to remove your extension.    And instead of either letting the submitter of windowlab know that you dont appreciate your stuff being overwritten or contacting a team member with your concern, you simply say "I quit".  You didn't give us a chance to correct the situation.  Before you posted in this thread today, I had already made it amply clear that I will personally check each extension submitted to make sure they won't  overwrite an existing one.  So I don't understand why that is not good enough for you.

You may ask why I didn't already have a check for maintainership in the audit script.  Checks are added when the need for them arises, its that simple.  And I still say that two extensions being overwritten this last year or so is a quickly correctable issue.  There would not need to be a scripted check in the audit routine if we were all able to communicate and resolve our issues like adults, anyway.  

[blofsy]

I have read the necessary posts in the forum and also in the wiki and abided by it. That's all there is to it. If you want more rules for extension making you are free to discuss and create them.

I submitted this extension because:
1) The 2 years old stable extension you submitted didn't staisfy my needs and while I compiled and created the extension I submitted it because it could be useful for others. I think there are ppl who can bear with the "so unbearable long" description. Don't misunderstand the situation I submitted an svn version of the extension and not the stable. Your extension is also in the repository. If it bothers you then say so I'm not here to steal your chance to maintain moc.
3) Because I tried the svn version and I found that it contains bugs that could be a problem for me I stopped using it. It doesn't mean that others won't find it useful. Btw. the stable version is buggy as well and it is still in the repository and no one is complaining about it.

Every extension I submitted was tested on a base system. If you can overcome such problems as long description you can use the software. ( despite that there could be bugs I didn't see during testing but it's obvious)

Lastly: If you don't like the way it is do something about it. For example you could create a template that would be used by others so every one of us could use it and problems like long description wouldn't be a problem anymore. And it would be wise to public it in the wiki and not on the forums. Furthermore if you don't like the moc-svn extension as it is and you want to do a better one feel free to do it. As I said I don't plan to maintain it anymore.

[Jason W]

Blosfy, you do need to learn to write correct info files.  Very long descriptions are not allowed as it interferes with the extension web page.  

And also be make sure that when an -svn extension is made, simply know that the person who maintains the main extension is ok with it.   Communication is vital on everyone's part.  


If this thread degenerates into a fight, it will be locked.

[Jason W]

Obviously, the last few posts, including my own, were spoken in frustration.  But each participant has made some valid points.   There is always room for improvement in all areas, and those areas that could use improvement need to be discussed. 

One is that the extension making process could be more documented.  Though the details of extension making are not quite the moving target they once were, I am sure there could be more specific things like the details of the info file.  I post in the forum as changes occur in the area of extension making, but I am sure more could be added to the wiki.  The community has done a good job at putting information in the wiki and keeping it current. 

Another is the issue of updating extensions that are not your own.  It has been discussed in other threads, but I would like to add some details.  As for extensions with the same name, it is a hard and fast rule not to submit a newer version or any update to an extension maintained by someone else.  But when we get into -svn extensions, or an extension that could be built as gtk1 as well as gtk2, then it gets into a grey area.  There are extensions where I have the gtk2 version and Juanito has the gtk1 version.  Usually that is no issue.  But I do ask that if you are building a gtk1 version of an app the already has a gtk2 or cli version in the repo, simply let the maintainer of the existing extension be aware of what you are doing so plans don't collide.  Same with an -svn versus a stable version.  I will make a point to extend the rule of not submitting a new version of someone elses existing extension to this grey area, but I do need to count on the community to follow this courtesy.  And if you see another version of an extension of yours in the repo under a different extension name, let me know if there is any issue in dealing with the other party.

Most of all, I appreciate all our contributors and I will strive to find solutions to any problems that come up and also to try to prevent new ones from occurring.  I don't want anyone here to feel like their efforts are being stepped on by me or anyone else.  My first obligation is to serve the community in it's effort to provide TC with it's vast repo, and to keep things working smoothly in that regard as possible.  I believe there is always a better way of doing things, and I want to hear if there is ever an issue with the way things are or if there is a way to improve the process.

 

[aus9]

hi

sorry if this appears to be hijack. It relates to maintainship so kinda related.

I am looking at the repository list.

I am aware that some members feel time pressures more keenly than others.

I am aware there is also a certain level of satisfaction in saying you are the maintainer of app X.

(virtually spank me if you disagree heh heh)

Now I am wondering out aloud......some packages might be better maintained if all done by the same maintainer?

Let me try a give examples?

xfe....all done by Jason W (I hope)

while ....xine* appears to have at least 2 maintainers.

while xfce4* appears to have 2 maintainers.

Now maybe....they prefer it that way....maybe the way they run stuff...using certain libs means they can only maintain some stuff and not all.

but as TC appears to be maturing fast...tczs exploding into infinity and beyond....what do you think?

Not that I am a maintainer.....but I think maintainer X could give up certain packages and take on certain packages ...if they agree?
Then our sweet moderator can change the  info file.....and maybe  more people may be happier?

regards