Downloading content from host of a game in lobby

[Tobi]

May I note some things:

There is no such thing as jurisdiction in open source wrt public discussions. For what you and I know, Tim may have been silently developing a lobby for a while already. No one can prove he hasn't, it only gets more plausible over time if he doesn't release anything.

For what I have observed, YokoZar did not start the discussion about the torrent thing, he only suggested that players be able to download maps from the host through the lobby interface. This could as well mean something like a /dcc send option for the host (1 on 1 file sending). Someone else, I'm not 100% sure who, immediately assumed he wanted a full fledged torrent implementation, probably because of discussions in the past.

By joining the discussion, you yourself choose to spent your time on it. It is unfair to blame the starter of a thread for wasting your time, while you could have chosen to ignore the discussion (as you told me a long time ago and it has saved me a lot of time already (ignoring the feature requests forum ftw )). In that case it would have drawn much less attention and the thread would have died much sooner.

Multiple private (development) forums exist. How can you know they don't exist anyway without having site administration rights? Most of them aren't needed really much though, which is a good thing and brings me to my last point:

I think it is a bad thing that discussions and brainstorming are forced to private channels or killed off altogether because users may start to expect the discussed things to be implemented in the near future.

In my experience public discussions motivates people to work on stuff, shows users and potential new developer that the community is alive and full of ideas, may inspire people to actually implement the suggested ideas, etc., etc.

[Tim Blokdijk]

Tim, your crossing the line.
By doing what exactly?
This is outside your juristiction. This is lobby related.
We don't work with jurisdictions. And from my perspective this is process related.

Linux lobby development is moving faster than ever and is fast approaching the tipping point were tasclients featureset has been totally replicated and improved upon.

At this critical time the issue of torrents arises, threatening to derail the entire process and at the same time create an entire development problem of its own.
Untrue, discussing a torrent system has no no direct effect on the development process. And yes, it brings with it a few technical things with it that need some thought, but not a level that I would call it a "problem".
There is a limited amount of people and resources. In case you havent noticed the spring lobby thread has already been derailed by this topic. Torrenting is a very strong feature request and discussing it like this gives the flase impression that its a planned feature and not a feature request. I know this because its happened before.
I will comment on the limited amount of people at the bottom.
Torrenting via lobby is on topic to some degree, but it can be a good idea to have one dedicated topic for it. We can state in that topic that it's only a discussion to see the (in)feasibility, and not a planned feature. That would solve any false impression.

This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
"This big song and dance" is created by you.
Discussing a feature won't mean it's already planed but we can take it to the private dev forum (as it's not yet world readable) to solve that if you can't discuss this publicly?
No such private development forum exists, and any private discussion of the topic would be immediatly underlined with "Now is not the time, come back in 2-3 months time"
The "Subversion Repository" forum.
Why would it not be the right time to discuss a feature request?

What has Betalord to do with this at this point?
And what has a league to do with it?
Betalord started a thread indicating he wanted to build an integrated lobby ladder and tournemant system. In doing so he killed off Spring league mk II. Prior to that thread he had been planning it for at least 2 years dropping in to take out ladder startups so he could carry out his plan. Of course he never did anything and people are now expecting the feature. People have expectations and anyone moving into that field has to live up to them. This is comparable to the big song and dance yokoar has created by pushing hard with hsi feature request.
Would still not make it exactly relevant to this discussion. I agree that it's important to do the things you decide to do. Still I did not see anybody commit himself to a torrent system, you're mixing public commitment with open discussion.

And it's indeed not practical to have different treads about it. Maybe we should close a few and pick one?
Agreed, yokozar should have gone through the proper channels and created a thread in the feature request forum. Instead he chose to mention it at every available moment in as many threads as possible
Ok, I suggest to use http://spring.clan-sy.com/phpbb/viewtopic.php?t=11488 for the torrent discussion and continue the process discussion in this topic. I don't think it matters if the topic is not in the feature request forum but it can be moved if needed.

As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Yokozar did open a new topic and Tobi split off this one but other then that you are doing the singing and dancing.
This is a feature request. Past expereince shows it can be damaging and misleading to users.
If discussing possible features is damaging and misleading users we should protect them by explaining the (health) risk. I don't think that it's a good idea to drop discussion to protect our users from any possible negative effects.

Yokozar has made a big deal out of this unnecesarily and hasnt gotten the hint that now isnt the tiem to discuss it or that there may be things hes not aware of that I wont be putting in this thread, he chose to argue, so I proceded in attempting to quash the arguements.
Let me give you a hint: We don't work this way.
There is no reason not to discuss this now.
If you don't like to say something then you can't expect anybody to 'magically' understand your problem.
He did not chose to argue, he likes to discuss a feature.
If you would just discuss the arguments then things would be fine, the point is you try to actively derail the development process with remarks in CAPS and statements like "Nor do you realize just how much time and effort and motivation your draining just by pushing for it?". Do you realize how damaging things like that are?
And don't expect me to sit back and relax about stuff like that when I just spend a few weeks developing processes to prevent drama like that effecting Spring development.

Where is the future feature list? I read AFS Design drafts but that's mainly server side right?
AFS is generic. Any features implemented are to be given context by the lobby ntot he lobby server.
Then use the torrent discussion to set up a real roadmap with planed features.

Anyhow discussing a new feature should not effect any feature list in a negative way.
People's expectations should only have a limited effect on the roadmap, the developers have to set the goals. If other features would be set back then it can be a good idea to give this new idea a lower priority then those other features.
Because of the higher expections and anticipation caused by Yokozar throwing a spanner in the works, 1 on 1 file transfers has moved from a high priority to a low priority. Such a feature would no longer be seen as a complete feature but rather as a work in progress leading towards torrents. Users thus see the entire feature set differently. As a result, the numerous other features that are able to solve the problem det proposed have to be sidelined or scrapped
If torrents can indeed solve the problem effective then we would have no need for alternatives. And why would that be a problem?

Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
You read the development process, discussion is done before it gets confirmed and supported by the developers. So discussion of this feature is the right thing to do now. Once the discussion is done it's done. If we decide it's worthwhile it might be a while before a developer has time to implement it. I can make a summery of the discussion in a plan that can be pointed to if this idea would resurface once in a while.
Your site development process is for your site. Things work somewhat differently outside fo spring, especially where external tools such as lobbies AIs and other tools are concerned. Develoeprs tend not to make plans public unless things are iminent or they reach a stage were screenshots can be shown off
It's still for the site but it can and should be applied where multiple people work on something. The site is just the first place where it's used as I have good control over site development and as an effect can help people use it. Once it's working we can move to other parts, I know Tobi likes to use it for engine development.
And that's a good idea as everything within Spring is heavily interconnected and people will have to work together on things. You can't develop Spring without having effective communication, the dev. process makes it easier as it breaks it down in small steps that even people with lacking social skills should manage to follow. Anyway I'm around for a while to learn people how to use and refine it.
I know developers sometimes have the tendency to build the so called "Power Plants" (code for months and then drop a large diff) but that's considered bad practice in open source development. It's something we should try to prevent.

And who're users going to look to in a few weeks time when no progress emerges?
To that summery of the discussion I can write.
I've been doing this to people every week or two for quite a while now
More reason to have a solid discussion about the topic.

This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
You're overreacting it's untrue the development process should allow continued progress in parallel.
Our community simply isnt large enough for such an ideal. AFLobby is a 1 man show mostly, and there arent that many spring lobby developers either, there is a finite amount of time and resources and an immediate pressing featurelist from tasclient that needs implementing. Delays at this time in implementing the featureset can and have killed off lobby projects in the past. They demotivate and slow down progress from developers.
It's actually the other way around, the *developer* community is to large, we have multiple lobby implementations under active development but no processes to unify it into one effort. I wish I could put more emphasis on this but the current state of lobby development is such a good example of how badly we need a structured way of working together. And I don't mean we need to like each other. We can hate the guts out of each other, no problem.

[AF]

Tim, your crossing the line.
By doing what exactly?
This is outside your juristiction. This is lobby related.
We don't work with jurisdictions. And from my perspective this is process related.
AF|Let me rephrase: Its none of your beeswax, lobby development != spring development. Lobby development is not an open book were decisions are made by forum polls and general consensus in the community. Its usually managed and guided by the founder of the project.

To reiterate the point, Tobi is in charge of the spring project. There is no Spring client, rather its outsourced to another project ran by betalord, and as such Tobi can not directly order betalord to do anything unless it applies to the server ran by the spring project. There is no reason why betalord cnt just ignore everything we say, up sticks, remove spring support, and move to another engine. Thats his business. Yes tasclient may be opensource and if spring forked it if he ever did that then thats a spring project not a tasclient project.

So as of yet I havent seen any requirements by any lobby developer to follow spring development processes. Lobby developers have their own processes, and development itself isnt always on this forum, some projects havent even declared themselves on this forum.

So please dont patronize another opensource project because it doesnt follow your spring process to the letter.

This big song and dance created is giving the impression that torrents are coming. The language used assumes that this is a future planned feature, possibly already underway, and users are just starting to forget from the last time, its betalords ladder all over again, only this time nobody has made any commitment, and there are no existing rivals such as spring league, and the whole thing was spammed in 3 threads in different forums and continues to be proactively spread.
"This big song and dance" is created by you.
Discussing a feature won't mean it's already planed but we can take it to the private dev forum (as it's not yet world readable) to solve that if you can't discuss this publicly?
No such private development forum exists, and any private discussion of the topic would be immediatly underlined with "Now is not the time, come back in 2-3 months time"
The "Subversion Repository" forum.
Why would it not be the right time to discuss a feature request?
AF|This is not an svn issue

As a result, if yokozar continues to make such a big song and dance he risks tarring the future featurelist. I initially planned for 1<-> file transfers in AFLobby but because of the big song and dance over torrent sharing I have to scratch that from my planned feature list now because people will immediatly expect me to implement to torrent protocol and the necessary framework to support it which could set back my big features by several months which is unnacceptable.
Yokozar did open a new topic and Tobi split off this one but other then that you are doing the singing and dancing.
This is a feature request. Past expereince shows it can be damaging and misleading to users.
If discussing possible features is damaging and misleading users we should protect them by explaining the (health) risk. I don't think that it's a good idea to drop discussion to protect our users from any possible negative effects.
AF|Now is not the ideal time for this request.The ideal time for requesting this that would give the maximum opportunity of its implementation is during a lull in lobby development. Right now we're in the middle of a development boom, making big requests at this time then spreading them in order to realy push it is not good.

Yokozar has made a big deal out of this unnecesarily and hasnt gotten the hint that now isnt the tiem to discuss it or that there may be things hes not aware of that I wont be putting in this thread, he chose to argue, so I proceded in attempting to quash the arguements.
Let me give you a hint: We don't work this way.
There is no reason not to discuss this now.
If you don't like to say something then you can't expect anybody to 'magically' understand your problem.
He did not chose to argue, he likes to discuss a feature.
If you would just discuss the arguments then things would be fine, the point is you try to actively derail the development process with remarks in CAPS and statements like "Nor do you realize just how much time and effort and motivation your draining just by pushing for it?". Do you realize how damaging things like that are?
And don't expect me to sit back and relax about stuff like that when I just spend a few weeks developing processes to prevent drama like that effecting Spring development.
AF|Yokozar didnt work within your process and actively raised the request in multiple threads before starting his own thread, breaking common forum courtesy and accepted norms.

Anyhow discussing a new feature should not effect any feature list in a negative way.
People's expectations should only have a limited effect on the roadmap, the developers have to set the goals. If other features would be set back then it can be a good idea to give this new idea a lower priority then those other features.
Because of the higher expections and anticipation caused by Yokozar throwing a spanner in the works, 1 on 1 file transfers has moved from a high priority to a low priority. Such a feature would no longer be seen as a complete feature but rather as a work in progress leading towards torrents. Users thus see the entire feature set differently. As a result, the numerous other features that are able to solve the problem det proposed have to be sidelined or scrapped
If torrents can indeed solve the problem effective then we would have no need for alternatives. And why would that be a problem?
AF|Because there are numerous logical arguements against them that suggest they arent the solution, while at the same time discussion of torrents appears to be with the intent of them being eventually implemented. Its an unfair discussion as it aims to consolidate the request. To date nobody has suggested a viable alternative, and they do exist. The only alternative expressed has been direct transfers, for which nobody has shown any interest in and gone straight to torrents.

Whatsmore, community time and effort which could be better spent elsewhere is being channeled into discussion of the new feature that hasnt been announced confirmed or supported by any developer yet. Its vaporware, MOTD, and its now going to float around the forum and the lobby for months to come.
You read the development process, discussion is done before it gets confirmed and supported by the developers. So discussion of this feature is the right thing to do now. Once the discussion is done it's done. If we decide it's worthwhile it might be a while before a developer has time to implement it. I can make a summery of the discussion in a plan that can be pointed to if this idea would resurface once in a while.
Your site development process is for your site. Things work somewhat differently outside fo spring, especially where external tools such as lobbies AIs and other tools are concerned. Develoeprs tend not to make plans public unless things are iminent or they reach a stage were screenshots can be shown off
It's still for the site but it can and should be applied where multiple people work on something. The site is just the first place where it's used as I have good control over site development and as an effect can help people use it. Once it's working we can move to other parts, I know Tobi likes to use it for engine development.
And that's a good idea as everything within Spring is heavily interconnected and people will have to work together on things. You can't develop Spring without having effective communication, the dev. process makes it easier as it breaks it down in small steps that even people with lacking social skills should manage to follow. Anyway I'm around for a while to learn people how to use and refine it.
I know developers sometimes have the tendency to build the so called "Power Plants" (code for months and then drop a large diff) but that's considered bad practice in open source development. It's something we should try to prevent.
AF|Lobby development would slow down excessively if it followed your methodology. Theres no trust in your method save for public opinion on what the collective attitude will be towards a change. In a field with lots of small changes happening very quickly this process would bog down the speed unnecesarily.

On top of that developers may plan quite far ahead what they want in their projects, things that seem out of place now may seem irreplaceable at a later date.

With regard to power plant patches, experience shows lobby development outside of the official tasclient thread is fast, with lots of small patches and updates rather than a few huge updates, with upto date versions committed almost daily.

This huge push for this feature request is irresponsible and damaging. Now is not the time for it, especially not now.
You're overreacting it's untrue the development process should allow continued progress in parallel.
Our community simply isnt large enough for such an ideal. AFLobby is a 1 man show mostly, and there arent that many spring lobby developers either, there is a finite amount of time and resources and an immediate pressing featurelist from tasclient that needs implementing. Delays at this time in implementing the featureset can and have killed off lobby projects in the past. They demotivate and slow down progress from developers.
It's actually the other way around, the *developer* community is to large, we have multiple lobby implementations under active development but no processes to unify it into one effort. I wish I could put more emphasis on this but the current state of lobby development is such a good example of how badly we need a structured way of working together. And I don't mean we need to like each other. We can hate the guts out of each other, no problem.
AF|Actually, lobby development atm is quite healthy and is in the middle of a boom with the move towards completing tasclient featureset outside the tasclient codebase. The lobby scene is in dire need of innovation in User design and featuresets.

[jcnossen]

Kindof dropping in the discussion too late, but I still want to make my point..
Bandwidth is cheap these days, and I am working (hopefully with iamacup at some point when he has replaced his hardware) on a solution for auto downloading that should be integratable in lobbies and other software. In other words, there is no need for a torrent downloader.

[AF]

Jelmer, once again I have to stress that your lack of co-opeation with anyone else is very disturbing, especially if you plan to integrate this anywhere else.

[Peet]

edit: ehh, too flamey

[Snipawolf]

lol.. Gunna run out of colors soon.

I'll stick to my things and you guys can stick to yours >___>

[Comp1337]

I remember teh days of direct FU dl, never a problem with maps
Ah nostalgia

[tombom]

Jelmer, once again I have to stress that your lack of co-opeation with anyone else is very disturbing, especially if you plan to integrate this anywhere else.

I think there's nothing wrong with working on something privately for a while before mentioning it in public. You've gone really over the top in this thread and I have no idea what your problem is with it.

[Tim Blokdijk]

I explained what I needed to explain, I have nothing to add to it so I'm not going to give another in-line reply. But I do like to reply to this:

Jelmer, once again I have to stress that your lack of co-opeation with anyone else is very disturbing, especially if you plan to integrate this anywhere else.

If you would follow your own logic here then Jelmers work would be an external project and this would not be disturbing to you at all. And I sure hope this request is made at a good time as it might totally nuke Jelmers timetable. I sure would hate it if Jelmer would lose his cool now that the users would expect something from him.

Anyway, see my point? You yourself like to cooperate with other developers. >You< NEED structured development processes. Spring is to interconnected. There are no real islands where you can just do your thing without having to interact with other developers.
I can help you and others to use processes in an effectively way but then you have to accept them as a tool to coordinate changes that effect different aspects of the project that you do not control directly. You should not see it as a threat that takes away control over your projects.

[Neddie]

We need a centralized managing entity who will keep track of all of you, somebody who is not involved in engine development for either OSRTS/Command or Spring...

[j5mello]

hmm... interesting

Really AF I think you are making this out to be way more than it is. For one thing i think we can agree that the majority of players don't bother with the forums. For those that do, spending any amount of time here will show them that a feature request will go one of a couple of ways (starting with most likely and ending with least likely):

Code: Select all

1. The idea shows up, gets batted around by people only to fade off into obscurity and possilby be brought up again at some other point. (Can lead to #2 or #3)

2. The idea shows up, gets batted around by people and an interested contibutor like imba or KDR or Flozi or someone else picks up the idea and works on it.

3. The idea shows up, gets batted around by people and a core dev goes hell that sounds interesting and gives it a go.

Again anyone who spends a half decent amount of time here will know that #1 is 75% of ideas with #2 at 20% and #3 at 5%.

I seriously doubt anyone expects anything remotely like this in the next version. And, to be honest, if they do it would most likely because of your constant discussion of this subject. IF you would just walk away and get back to what you were doing this would die off i mean hell... Yoko hasn't posted in this thread in over a day. The only thing keeping it fresh is you and Tim's headbutting (which btw was annoying as hell to read).

Really the time it took both of you to type out that rainbow argument could have been better spent doing something way more useful, like say getting one more feature in the lobby or site done.

I think the players who read the forum know we are NOT getting torrent systems anytime soon, the rest are unaware of this whole damnable discussion. In fact I think that most of them don't care one way or the other. Sure it would make hosting easy but Spring isn't a simple beast. Never has been and probably never will. The sooner a player understands that the sooner they can stop whining about missing features and enjoy the ones that are there.

Whats even worse and as someone, i think tobi, pointed out what Yoko wanted was a feature you just bumped down the priority list because of some silly notion that people won't accept what you make as a final product but rather a setp to something else. Thats silly. Your the dev. If thats all you are giving them and they are unhappy well they can sit there and whine.

Thats the key thing AF. You are the dev. You work on the lobby. We should be grateful for the features you do give us and if were not well then thats makes us a whiney bunch of f**ks.

You do great work AF but you are way to emotinally involved in some of this stuff. This should be at best a fun waste of time and at worst a serious hobby along the lines of say minature painting or fishing. If this stuff isn't fun for you anymore maybe you need a break.

But then again... im just some faceless nameless person on the internet so why should my opinion even matter to you...

EDIT: OH SHIZZLE I GOTS MORE TO SAY OH NOEZ!!!!

Tim exactly what are you docs for exactly? Just the site? or is it for spring as a whole? Cause if you are trying to streamline spring development you might wanna reserve a room with really soft walls for later. If your not then I ask why you even bring up half of that stuff in regards to the thread.

jc its good to see that something is being worked on and I eagerly await it.

[Tim Blokdijk]

It's about this document.
And this doc is just for the site. I don't have the intention to streamline Spring development as a hole. But I do like to make it easy for other devs to implement it outside of site development. And no it's not going to be mandatory to use processes like this, but I do think most Spring developers will have to use some form of process to facilitate teamwork. As things just don't scale well otherwise. But that's more something in general, not directly related to this specific discussion with AF.

[AF]

Jelmer is writting the the intention of integration into other projects. He has not consulted with anyone at all about this save iamacup. To date no lobby developer, no dev has had any information save the basic 'package management + UF' description. No details have been given of any kind.

This means jelmer could be heading down a road that leads to a lot of unnecesary problems. Nowhere is there any consultation with content developers about how theyd like to package things, nowhere for developers to even see and prepare for integration.

This is unusual. In the past jelmer has posted and made a song and dance about big features and everyones gone hooray!

To me this is disturbing.

So this leaves several possible conclusions about what is happening:

• Jelmer considers this a minor feature and feels theres no need to say anything as a result. However this is plainly not a small feature and jelmer has said as much so this is unlikely.
• This has been gagged by someone else. Perhaps iamacup wants it kept quiet, perhaps a show and tell may reveal something else we're nto supposed to knwo yet.
• Perhaps jelmer is working with the CE server effort in C# that iamacup has been leading, feeling that the package system would be better suited for CE and spring support would be legacy, a test gound if you will. However this means that preferential treatment is taking palce and competition from AFS has been severely dented before it has a chance
• Jelmer hasnt implemented anything at all and isnt sure what hes doing, and is instead waiting for iamacup to hand over UF access.

Granted it is speculation, and who knows what jelmer is upto save for jelmer himself. However while jelmer keeps quiet, other rival systems are stuck, with their developers stuck in a limbo, wonering if theyre being made obsolete or wether they should continue to develop. This is what happened when betalord announced the integrated lobby which should have been finished a month or two ago earlier this year. All tournement and ladder projects immediatly fell apart in tis wake and havent recovered since. All thats left is ladder maintainenance for mod specific ladders that already existed.

While I believe my lobby is within my juristiction as project leader, I can choose what process I follow. However that doesnt stop me having opinions and thoughts about things outside my own code files, especially when they affect my own project.

Tim, you have outright attacked my position and expressed the opinion that my project is not a project in its own right and nor are the other lobbies, and that they fall under the control of the entire spring umbrella. You have attacked my methods based on the fact they dont match yours word for word, and attacked my expression of opinion. This is you offending me and crossing the line.

[Neddie]

You really, really need a facilitator. All of you. All of us.

If you want me to take on the role, I will drop an extraneous class and give you at least two hours a day, five days a week, starting August 27th.

[AF]

To be nannied would be insulting

[Neddie]

This is a project with no driving force, you have a head developer, but his job is to develop code and integrate it - you have nobody doing the necessary thin-line organization work. Just because you don't have a budget doesn't mean you can fly well without regulations.

[AF]

I will not watch my projects fall under someone elses control unwillingly. And I doubt other lobby developers will let it happen either.

[Neddie]

Oversight is not control, but if you would mistake it for such, I'll withdraw the offer. I'm paranoid and busy enough as it is.

[Snipawolf]

It is like morrowind.

Neddie is the overseer, who holds the whip, and you are the slave-argonian who is working in the fields.

Each developer has his own field of veggies to attend to, and the owner likes to have a good variety, so he needs all of you to work your best on your field, and if you don't...

I won't even go there.