Applications Lifecycle Policy

Luigi Toscano luigi.toscano at tiscali.it
Wed Jul 5 12:51:32 BST 2017


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



More information about the kde-community mailing list