Tiny Core Extensions > TCE Bugs

moc-svn.tcz - improper info file format

<< < (2/2)

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

Navigation

[0] Message Index

[*] Previous page