Megarepo inclusion policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Megarepo inclusion policy

Julian Arni-2
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Nickolay Kudasov
Hi all,

My position regarding servant megarepo is that it should only contain core packages, essential to servant framework.

I consider the following packages "core":
  • servant
  • servant-server
  • servant-client
  • servant-foreign
  • servant-mock (soon to be servant-mock-server)
  • servant-mock-client (soon to appear)
  • servant-examples
  • servant-docs (although this one requires a bit more love to become practically useful, I think)
These packages are essentially individually packaged extra content types and I believe they should reside in a separate megarepo (servant-content-types?):
  • servant-blaze
  • servant-cassava
  • servant-lucid
These packages are extra client generators and are large enough for separate repos:
  • servant-js
  • servant-purescript
  • etc.
I do not think having servant-js in servant megarepo is a good idea.
Mainly because it's actually a collection of JS client generators: Angular, Axios, jQuery and vanilla JS.
I don't think it makes sense to include and maintain all four of these in the megarepo.

If we really want to have JS client generator in megarepo, I would prefer vanilla JS as JS-framework-free.

Regarding servant-swagger: it is sort of "extra documentation package", although it does not rely on servant-docs.
Besides, Swagger is just one of many API specification formats, so it makes little sense to make it "core".

In another thread servant-extras package has been proposed to collect potentially useful combinators (but which we aren't yet sure we want to absorb). I think this package should also have a separate repository.

 Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

​I think Stackage does this for us already semi-automatically!
If a new package version breaks some dependent packages, Stackage maintainers create an issue like this one where all packages that need to be updated are listed (with mentions of corresponding maintainers).

Kind regards,
Nick

On Sat, 16 Jan 2016 at 18:39 Julian Arni <[hidden email]> wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Julian Arni-2
Many fair points.

On Mon, Jan 18, 2016 at 12:40 AM, Nickolay Kudasov <[hidden email]> wrote:
Hi all,

My position regarding servant megarepo is that it should only contain core packages, essential to servant framework.

I consider the following packages "core":
  • servant
  • servant-server
  • servant-client
  • servant-foreign
  • servant-mock (soon to be servant-mock-server)
  • servant-mock-client (soon to appear)
  • servant-examples
  • servant-docs (although this one requires a bit more love to become practically useful, I think)
These packages are also the ones that are most directly affected by new combinators. In that sense, they are the ones where all of the pros and cons of a larger megarepos (except lock-step release) apply. That said, I agree.
 
These packages are essentially individually packaged extra content types and I believe they should reside in a separate megarepo (servant-content-types?):
  • servant-blaze
  • servant-cassava
  • servant-lucid

I agree with the idea of moving them out of the main repo. They don't even require updates that frequently based on other changes, so the benefit of having them in the megarepo is quite small.

These packages are extra client generators and are large enough for separate repos:
  • servant-js
  • servant-purescript
  • etc.
I'm inclined to agree.
 
I do not think having servant-js in servant megarepo is a good idea.
Mainly because it's actually a collection of JS client generators: Angular, Axios, jQuery and vanilla JS.
I don't think it makes sense to include and maintain all four of these in the megarepo.

If we really want to have JS client generator in megarepo, I would prefer vanilla JS as JS-framework-free.

Regarding servant-swagger: it is sort of "extra documentation package", although it does not rely on servant-docs.
Besides, Swagger is just one of many API specification formats, so it makes little sense to make it "core".

There is quite a bit of overlap between servant-docs and servant-swagger. While I agree that committing whole-heartedly to one API specification format is not great, it is bringing up the issue of whether effort that is spent on -docs couldn't be better spent on -swagger. -swagger buys us a lot more than just documentation, and in that sense it is a more 'useful' format for docs. That said, there are *many* things to consider here, and I think talking about too much is a bit premature.
 

In another thread servant-extras package has been proposed to collect potentially useful combinators (but which we aren't yet sure we want to absorb). I think this package should also have a separate repository.

 Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

​I think Stackage does this for us already semi-automatically!
If a new package version breaks some dependent packages, Stackage maintainers create an issue like this one where all packages that need to be updated are listed (with mentions of corresponding maintainers).

Fair enough.

I guess to summarize, I agree with all your proposals (though I have some things that I'd like to qualify about servant-extras, but I'll say them elsewhere).

Kind regards,
Nick

On Sat, 16 Jan 2016 at 18:39 Julian Arni <[hidden email]> wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Brandon Martin
In reply to this post by Nickolay Kudasov
This is a well done post. I agree whole heartedly. Well put Nick. 

--
Brandon Martin

On Jan 17, 2016, at 4:40 PM, Nickolay Kudasov <[hidden email]> wrote:

Hi all,

My position regarding servant megarepo is that it should only contain core packages, essential to servant framework.

I consider the following packages "core":
  • servant
  • servant-server
  • servant-client
  • servant-foreign
  • servant-mock (soon to be servant-mock-server)
  • servant-mock-client (soon to appear)
  • servant-examples
  • servant-docs (although this one requires a bit more love to become practically useful, I think)
These packages are essentially individually packaged extra content types and I believe they should reside in a separate megarepo (servant-content-types?):
  • servant-blaze
  • servant-cassava
  • servant-lucid
These packages are extra client generators and are large enough for separate repos:
  • servant-js
  • servant-purescript
  • etc.
I do not think having servant-js in servant megarepo is a good idea.
Mainly because it's actually a collection of JS client generators: Angular, Axios, jQuery and vanilla JS.
I don't think it makes sense to include and maintain all four of these in the megarepo.

If we really want to have JS client generator in megarepo, I would prefer vanilla JS as JS-framework-free.

Regarding servant-swagger: it is sort of "extra documentation package", although it does not rely on servant-docs.
Besides, Swagger is just one of many API specification formats, so it makes little sense to make it "core".

In another thread servant-extras package has been proposed to collect potentially useful combinators (but which we aren't yet sure we want to absorb). I think this package should also have a separate repository.

 Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

​I think Stackage does this for us already semi-automatically!
If a new package version breaks some dependent packages, Stackage maintainers create an issue like this one where all packages that need to be updated are listed (with mentions of corresponding maintainers).

Kind regards,
Nick

On Sat, 16 Jan 2016 at 18:39 Julian Arni <[hidden email]> wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--

--

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Sönke Hahn
+1 to what Nick said.

I would also be fine with moving `servant-docs` out of the main repo.

Cheers,
Sönke

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Yann Esposito
In reply to this post by Julian Arni-2
+1 for Nick comment.

And my 2cents, `servant-swagger` should really get more love. Personally I prefer to use `servant-swagger` to `servant-doc` even if the two packages don't target exactly the same use.

On Saturday, January 16, 2016 at 4:39:04 PM UTC+1, Julian Arni wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Nickolay Kudasov
Hi Yann,

Do you mean servant-swagger should be improved in some way?
Or that we should "promote" it to be more widely used?

Kind regards,
Nick

On Thu, 21 Jan 2016 at 18:23 Yann Esposito <[hidden email]> wrote:
+1 for Nick comment.

And my 2cents, `servant-swagger` should really get more love. Personally I prefer to use `servant-swagger` to `servant-doc` even if the two packages don't target exactly the same use.

On Saturday, January 16, 2016 at 4:39:04 PM UTC+1, Julian Arni wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--

--
Reply | Threaded
Open this post in threaded view
|

Re: Megarepo inclusion policy

Yann Esposito
I meant I would like it to be more promoted. swagger-ui / swagger completely changes the way you interact with your API, I really like it.

On Thursday, January 21, 2016 at 4:40:10 PM UTC+1, Nickolay Kudasov wrote:
Hi Yann,

Do you mean servant-swagger should be improved in some way?
Or that we should "promote" it to be more widely used?

Kind regards,
Nick

On Thu, 21 Jan 2016 at 18:23 Yann Esposito <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="1uZvvx41EQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">yann.e...@...> wrote:
+1 for Nick comment.

And my 2cents, `servant-swagger` should really get more love. Personally I prefer to use `servant-swagger` to `servant-doc` even if the two packages don't target exactly the same use.

On Saturday, January 16, 2016 at 4:39:04 PM UTC+1, Julian Arni wrote:
Hey list,

  A question that is becoming more relevant as the servant ecosystem grows is what packages to include in the servant megarepo. The advantage of including more packages is that breakage caused by changes to other packages (e.g., changes to 'servant' breaking 'servant-js') are caught by CI. A disadvantage (pointed out by Nickolay Kudasanov) is that release cycles must more or less proceed in lock-step, slowing everything down. Also, we to a large degree must then be responsible for maintainership. More neutrally, including more packages means that all contributors are responsible for updating all packages; this means contributing is a bigger effort, but also distributes the maintainership burden somewhat.
   What do people think about general guidelines about what to include? Recently this came up with servant-swagger (which we decided not to include) and to my mind is now coming up with servant-purescript (which would be the first non-JS language in the repo). Likely we would have a single policy for all (at least non-JS) languages, but this still doesn't help with the question of e.g. -swagger-like packages. Note that the recent servant-foreign package changes the calculus somewhat.
   Additionally, we may want to provide a service where authors of other packages can subscribe to a CI-like system that tries to build their packages (say once per day) with the latest master of the servant megarepo, and emails maintainers in case of breakage. But this is yet another architectural component that must be written and maintained.

Cheers,
  Julian

--

--