On Wed, 8 Sep 2010 13:52:08 +0200, [email protected] wrote: > On Wednesday 8. September 2010 12.44.41 Tom Albers wrote: >> And I again will point you that the fact that at least I was under the >> impression that kde-scm-interest was a list about bikeshedding about >> which scm we should choose. Which I really don't care about. I never >> considered it the decision making list. I would be surprised if I were >> the >> only one. The list is not called [email protected], which I >> would have joined right from the start. > > The list was started to coordinate people with an interest in scm's. The
> result so far is that people that were like minded started doing work and > we > now have > * a conversion tool > * a consensus in those doing thework on how to split repositories > * a nice progress on getting the conversion done. > So calling this a bikeshedding list is not entirely fair, but it shows we > have > to do more work to make clear what our progress has been so far! Don't twist my words please. I've indicated that I assumed the list was about bikeshedding about the tool, and never considered it to be a decision making list. I still find the name of the list confusing. I've respect for all the work that has been done by you and others. > As such we, on this list, have a clear direction; the people that do the > work > have chosen one specific approach and are grouping their efforts to get > there. I heard that before, and although I do agree with the general 'who does the work decides', I don't think it applies 100% here. k-c-d was not informed or I don't recall a call on blogs like 'hey we decided to go for git, please come now to discuss the git details', i don't recall blogs explaining the setup either. Things that influence how we as KDE work need to be communicated well and people can not always be simply told to shut up because they don't do the work. If things influence big parts of KDE there needs to be a widespread support for the idea. > The approach we have been following is different from what sysadmin is > assuming > we have and is optimizing the sites for. If I understand the doc correctly. > Maybe sysadmin can write a proposal on what things would look like and how > we > can optimize things using the work already done. The exact list can be > extracted from the rules repo; > grep 'create repo' * | cut -d: -f2 | cut -d\ -f3 | sort | uniq As said before, look at the document, the problems we touch and find solutions for those. > I'll attach the result as a text file. > > Assume that the decision is what it was last week; to split as indicated > in > the attached file. How would that work for our setup? As said, if there was a decision (which is at least not what some people told me), you can change a decision before it is too late. We have indicated serious problems with the setup and we see more advantages in the split-approach. It is our right and duty to advise you all to change your minds. If we would not have done it, you would have blamed us after the implementation 'why did you not say so before'. I suggest and hope you drop the idea 'decision is made, i don't want to think about changing', and try to see what problems we face in implementing it. Imho it is a once in a lifetime decision and it should be taken with care. Having no energy to look at it from a new angle is no good reason to not do it. We also have the idea that the discussion in the past was also based on the though that we would loose the hierarchical structure by using split repositories. Now sysadmin has decided to launch projects.kde.org, this structure can be given this way, which means previous arguments in the discussions are now invalid. > As you guys seemed to not have been aware of the actual plan we have been > executing (as indicated in the document by the assumption that > kdeextragear > would have been one module) it would be nice if you could write another > email > that builds on top of our work and gives hints on small changes that may > make > everyones life better. > At least that would avoid discouraging people that already put in a lot of > time and have gone though this discussion too many times already. Again, we advise you to go for a split approach, if the list does not want that, it is fine. Just solve the problems we address in the document and accept the technical consequences it will have. To turn this around: don't discourage us to write such documents in the future, I think it contributes to the discussion and is therefore valueable. It's like making a decision between buying 2 new cars, you made a decision, go to the shop to buy it and the salesmen tells you there are technical advantages and disadvantages for the car you want. You can either fix the technical issues as good as you can or choose to ignore them and accept consequences or change your mind. But you seem to blame the salesmen that he is telling this to you. Best, -- Tom Albers KDE Sysadmin _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
