Christian Mollekopf ha scritto: > Overall I just find the cost/benefit factor in the beginning of a > project not at all good when using KDE infrastructure. > I have to request repos and can't just create them, I have to request > tarballs to be uploaded instead of just uploading them, I have to apply > for CI instead of just doing it, etc. Personally, if I was not already > rooted in KDE I wouldn't bother and just use github. (I know that it may > be that not all of those friction points are by design, but more by lack > of manpower.)
You address few interesting point but I think that they are ortogonal to this discussion. Or better, that they can be discussed and solved independently without touching the application lifecycle. This is for repository creation (which I think it may be also blocked until we switch fully to phabricator, apart from the non-technical policy), more automation in the upload, and the requirement about the CIs (which I personally think should be enabled for every project). > > Now that equation starts to change later in the project if you i.e. join > regular releases, have translations etc. but initially it's IMO just > bad. That's of course exactly the baseline/dumpingground argument; > either you try to attract projects and thus lower the minimum bar as far > as possible, or you have some requirements. I don't think a bunch of > crappy repositories hurt a lot and could be kept in check IMO, so I > would go for the former, allowing projects to easily evolve and i.e. at > some stage decide to become part of an Applications release after > passing review. > If my project started on github though, and I consequently already setup > distribution channels etc externally, then that barrier is way higher. Being in a community has a cost, which is balanced by being in the community. > > But yeah, I'd be fine with any random project coming on KDE > infrastructure if it sees KDE as the place to be. Some might be shitty, > some might be great, some might have translations, some might not, some > might die after a couple of months, some might prosper for years. I > think it would be great to have more diversity and I don't really think > we have to protect the quality of anything and everything that is on KDE > infrastructure, that's what i.e. Applications and Frameworks releases > are good for. We are doing is already, and there will always be a cost (even with automation, I wouldn't open some process to people without a developer account). -- Luigi
