Re: [ql-users] SMSQ-E Development
In a message dated 19/11/02 01:17:14 GMT Standard Time, [EMAIL PROTECTED] writes: Wolfgang Lenerz writes: No. You would be in control of all relevant UPloads to the site. Will that be such a good idea? I can already see people protesting that I have too much control over what is happening on the website. You already have a lot of control ;) Only if that control is shown to be beneficial, efficient and fair will it have any meaning. Openness will provide continuous proof of that as well as many other benefits. A web-based framework as I have sketched seems to answer. However there is little point in discussing this further as neither I nor you are going to put this into practise, and no one else seems interested in even discussing the matter. No skin of my nose. Ill go along with any plan that does the job. Sorry for not adding my two-penneth before... I agree that a site (password protected) for people developing SMSQ/E and systems based on it would be of great benefit to the community. At the moment, there are several people with the source code, and it is impossible to know who is doing what with it. For all we know, there could be 3 people trying to tackle the problem of filenames on their own. Some form of forum is required where all those interested can detail what they are working on and bugs/problems found which need to be rectified. However, the question arises as to who will maintain the site. Any of the developers should be able to upload files to the site, including new web-pages, new parts of the operating system etc (although the latter would have to be kept in a separate "beta" area).. However, Wolfgang should be the only person who can upload the current SMSQ/E sources etc... NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it I think the best you can ever hope for is to have some control over the integrity of the sources. Which I won,'t if you can exchange them that easily. Again, I'm not saying this because I want absolute control over the sources, butif I don't have any, we can all forget the registrar... I agree with Wolfgang on this - that is why only he should be able to upload the official sources onto the site.. It should be agreed by all developers that beta versions on the site will not be used until submitted to the registrar (either as a binary or source code). cut -- Rich Mellor RWAP Software 35 Chantry Croft, Kinsley, Pontefract, West Yorkshire, WF9 5JH TEL: 01977 610509 http://hometown.aol.co.uk/rwapsoftware
Re: [ql-users] SMSQ-E Development
Wolfgang Lenerz writes: No. You would be in control of all relevant UPloads to the site. Will that be such a good idea? I can already see people protesting that I have too much control over what is happening on the website. You already have a lot of control ;) Only if that control is shown to be beneficial, efficient and fair will it have any meaning. Openness will provide continuous proof of that as well as many other benefits. A web-based framework as I have sketched seems to answer. However there is little point in discussing this further as neither I nor you are going to put this into practise, and no one else seems interested in even discussing the matter. No skin of my nose. Ill go along with any plan that does the job. So, what is the plan, guys? Or dyall think we can develop a complex, multi-component system, targeted at a variety of platforms and a multitude of users, put to a plethora of different uses - some of which may not even be thought of yet - simply with the aid of this list (sporting discussions ranging from hardware to haggis) plus the private communication between individual, voluntary developers and a benign registrar? They will anyway. Will they? But with a central, open site at least we'll all have the chance to see what the results of those discussions are as soon as the outcomes have been agreed. NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it I think the best you can ever hope for is to have some control over the integrity of the sources. Which I won,'t if you can exchange them that easily. Again, I'm not saying this because I want absolute control over the sources, butif I don't have any, we can all forget the registrar... Sorry if I didnt make myself clear... What facilities and improvements will be developed will be entirely up to the interests and abilities of the people involved. True - but then again, if I'm thje central hub, I *might* be able to push development more in one (common) direction. We'll see. At present there is virtually no control over who legal users are. If a reseller went down, or if there was a corrupt reseller (God forbid!) there is currently no way of knowing. So? I mean, tough luck. My proposal is that each user license would come with its own serial number that the customer could use to register with the database to allow free upgrade downloads or support entitlement. NO! I want to keep the commercial side and the development side TOTALLY separate. I may be responsible as software registrar to get the binaries to the resellers - but the relation between them and the users is NONE of my concern, and it shouldn't be. Support must be handled by the people who sold you your SMSQ/E. You are quite right. Suggestion withdrawn. Of cxourse, if a bug is discovered, I think veryone will try to correct it, but there is a difference between that and the support supplied by the resellers! I sincerely hope that in the event of a bug being discovered, not everyone will try to correct it ;) Per
Re: [ql-users] SMSQ-E Development
On 14 Nov 2002, at 1:39, P Witte wrote: (...) Quite some work has already been done by various people, such as tidying up the code to make it suitable for general distribution, adding various tools and help utilities, and Marcel has added some significant improvements to the code base which were previously only available to SMSQ-E for QPC. All well and good so far :) Yes, and until now my job consisted more or less to play catchup with the code supplied by Marcel (and Fabrizio). (...development being people driven) There is, of course, no way that I, nor anyone else, can force anybody a) to contribute b) to contribute in any given direction. I DO try to nudge people in the right direction, by asking whether they couldn't do some development in such and such area. As an example, I have asked one person whether he couldn't make the necessary developments for the home directory to be used by jobs. (You do remember that, don't you? :- I am in the process, however, of trying to collect the different ideas different people have given me at different times to have an overview of what should be done. In my opinion, there are, basically, three kinds of projects: 1 - Small improvements (e.g. Fabrizio's italian language support). By small I DO NOT mean unimportant - but they are improvements that can be handled by a single developper in not too much time. 2 - Important changes - the new WMAN and, possibly, rewriting the mass strorage device drivers for more/better/different/true etc directory support and longer filenames, come to mind. 3 - Adaptions to various machines. It is probable that many a development will need to be adapted to some machines more that to others. I had already mentioned the idea of a key developper for each machine, but that hasn't really been taken up. So how do we go about this? We can have a general scatter load approach, everybody doing something in the corner, alone - as you pointed out, this will peter out pretty quickly. Or, as you rightly suggest, we can have some form of centralisation, where, at the least, track is kept of the progress in different areas. The best way, IMHO, would be to have somebody to parcel out the work. However, in view of the fact that the QL scene is pretty individualistic, and that my perceived authority seems to be on the low side, I think this is rather irrealistic... So, your idea of a website could be a pretty good one. The thing that is stoppping me for the time being, is the feable number of developpers. Again, the question is whether it is worth it to go through all of that, just for four or five people. Ok, so the argument will be that if we don't do it that way, nobody else will participate etc I don't believe that for a second, I also don't believe that doing it this way will bring back the Q60 crowd into the fold. But - why not, if there is a sufficiently strong demand for it. (the website could): Hold general information about the project yes. List the sub-projects yes List planned developments yes List the developers and their areas yes - if the developers want. List progress information yes List the resellers and registrar yes Allow downloading of components to registered developers This is the area where I balk the most. By making the sources available to everyone, I still hope to draw people into development, who whould not, normally, have done so. Making a distinction between registered developers and those who are not (and don't have accessto everything) makes me pretty uneasy. As an example, I do not know whether Fabrizio would have become a registered developer? The fact is, that it was decided to keep destribution of the sources in a certain way. Doing it on a website means either detroying this way of duistributing the sources, or introducing a difference between normal QLer and registered developers. If there really is a majority opinion to do it that way (and I would like EVERYONE'S opinion on this) I'll bow to it, though. BTW, what do you mean by component? Moreover, one of the disadvantages of the website will, of course, be that some control is removed from me (at least that is a disadvantage in my eyes :-)). For the time being, most of the developers speak to me, and, as said above, I try to nudge them in a general direction. If we set up a website, the developers will speak to each other. I'm NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it Allow downloading of the latest binaries to registered users That would be a definite no. The users should get
Re: [ql-users] SMSQ-E Development
Wolfgang Lenerz writes: There is, of course, no way that I, nor anyone else, can force anybody a) to contribute b) to contribute in any given direction. I DO try to nudge people in the right direction, by asking whether they couldn't do some development in such and such area. As an example, I have asked one person whether he couldn't make the necessary developments for the home directory to be used by jobs. (You do remember that, don't you? :- Yeah, Ive got this guy in my cellar with the thumbscrews on. I think he'll soon crack ;) Per
Re: [ql-users] SMSQ-E Development
Wolfgang Lenerz writes: (...development being people driven) I am in the process, however, of trying to collect the different ideas different people have given me at different times to have an overview of what should be done. In my opinion, there are, basically, three kinds of projects: 1 - Small improvements (e.g. Fabrizio's italian language support). 2 - Important changes - the new WMAN and, possibly, rewriting the 3 - Adaptions to various machines. It is probable that many a You might add: 4 - Documentation (including design specs and structures) 5 - Support functions (eg the project web) So how do we go about this? We can have a general scatter load approach, everybody doing something in the corner, alone - as you pointed out, this will peter out pretty quickly. And could lead to political problems due to information black spots and a perceived lack of openness. (the website could): Allow downloading of components to registered developers This is the area where I balk the most. By making the sources available to everyone, I still hope to draw people into development, who whould not, normally, have done so. Making a distinction between registered developers and those who are not (and don't have accessto everything) makes me pretty uneasy. As an example, I do not know whether Fabrizio would have become a registered developer? Both modes of distribution could exist in parallel. There should be no need for immediate access to the latest sources for those who only have a casual interest, whilst for an active developer this is quite essential. The fact is, that it was decided to keep destribution of the sources in a certain way. Doing it on a website means either detroying this way of duistributing the sources, or introducing a difference between normal QLer and registered developers. If there really is a majority opinion to do it that way (and I would like EVERYONE'S opinion on this) I'll bow to it, though. BTW, what do you mean by component? See * below. Moreover, one of the disadvantages of the website will, of course, be that some control is removed from me (at least that is a disadvantage in my eyes :-)). No. You would be in control of all relevant UPloads to the site. For the time being, most of the developers speak to me, and, as said above, I try to nudge them in a general direction. If we set up a website, the developers will speak to each other. I'm They will anyway. But with a central, open site at least we'll all have the chance to see what the results of those discussions are as soon as the outcomes have been agreed. NOT saying that this is a bad thing but it will mean that development will be made on a more ad hoc basis. As the software registrar, with a mission to try to keep unified versions where possible (and thus, trying to steer the thing a bit), that must leave me with fixed feelings, of course since my power to influence things will be diminished (if it ever existed). But again, if this serves the community, I have no problems with it I think the best you can ever hope for is to have some control over the integrity of the sources. What facilities and improvements will be developed will be entirely up to the interests and abilities of the people involved. Allow downloading of the latest binaries to registered users That would be a definite no. The users should get their updates from the resellers. The developers don't need to download the binaries - recompiling everything is a five minutes process! At present there is virtually no control over who legal users are. If a reseller went down, or if there was a corrupt reseller (God forbid!) there is currently no way of knowing. My proposal is that each user license would come with its own serial number that the customer could use to register with the database to allow free upgrade downloads or support entitlement. Registration on the project web by users would, of course, be entirely voluntary. There is no privacy issue involved here, as the serial number only pertains to the user license. Obviously, if someone tried to register an invalid serial number, or one that is already in use, that would need to be investigated. Moreover, some kind of validation process must take place, to make sure that new versions are stable, before they are passed on to the user. Absolutely. This is your domain ;) Hold a support database (a la M$'s Knowledgebase) THAT is a LOT of work! ALL of this is a LOT of work. So is upgrading Wman and GD2! But this would be ideal for someone who would love to contribute and support, but is not able/willing to program in m68. A knowledgebase utility is an interesting programming project in itself. It neednt be created by the webmaster himself. Once up and running it could save resellers as well as punters a lot of hassle. It neednt all be done at once: in the mean time we have this list! * Components: My not too deep musings so far
