brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: Apache Brooklyn 1.0 release
Date Thu, 05 Oct 2017 12:55:04 GMT
Hi all,

Improving our authentication is a good feature to have, but I don't think
it's a blocker to a 1.0 release. I'd love to see this feature, but I don't
think we need to hold back 1.0 for it (better to think such a feature
through properly than to try and rush it into the next release.)

Andrea, I've looked at readthedocs myself - I love the idea of making the
drudgery of doc generation tooling Somebody Else's Problem, but when I last
looked, it wasn't suited to the way our user guide was written. It would
have needed quite a lot of manual effort to migrate from our home-grown
tooling into the way that readthedocs wants things to be written. See my
response[1] to Thomas' thread for a bit more.

[1]
https://lists.apache.org/thread.html/15b819cdecdcb717aa45e2efc7e4e5d3f1fcd491d1255a8aa72cd1c7@%3Cdev.brooklyn.apache.org%3E

On 5 October 2017 at 11:22, Andrea Turli <andrea@cloudsoft.io> wrote:

> +1 to stronger authN
>
> FYI I've quickly tried readthedocs -- see
> https://readthedocs.org/projects/brooklyn-docs/ and it is nice and free,
> maybe we should consider it for the website. It is an hosted service well
> integrated with github which offers full text seatrch out of the box.
> Many others ASF projects already use them, it's maybe worth a try.
>
> My two cents,
> Andrea
>
>
>
> On 5 October 2017 at 12:07, Thomas Bouron <thomas.bouron@cloudsoftcorp.com
> >
> wrote:
>
> > I would agree with Geoff on the auth. I think it would be nice to move to
> > JWT for 1.0.
> >
> > I would also point out the Brooklyn website. I'm the one to blame on
> this,
> > I redesigned the home page but not the rest (mostly due to the currently
> > complexity of it)
> > I'll send a proposal on this today.
> >
> > Best.
> >
> > On Wed, 4 Oct 2017 at 17:57 Geoff Macartney <
> geoff.macartney@cloudsoft.io>
> > wrote:
> >
> > > +1 with observation that there are still some things we might want to
> do
> > > before making that 1.0 release. (In re. Richard's comment about "Are we
> > > feature complete", you may think we are not.)
> > >
> > > For example something I think it would be good to do before announcing
> a
> > > 1.0 is to get away from basic auth on the UI and REST API and having a
> > > session token based approach, perhaps based on JWT tokens.  (Don't like
> > > storing the auth credentials for the CLI)
> > >
> > > That's one example but you may have your own suggestions - shout out!
> > >
> > > Geoff
> > >
> > >
> > >
> > > On Wed, 4 Oct 2017 at 16:41 Richard Downer <richard@apache.org> wrote:
> > >
> > > > +1 with conditions :-)
> > > >
> > > > Yes, I'd like to see Apache Brooklyn 1.0 released. I'd suggest that
> we
> > > > would get ASF PR involved to generate a bit of buzz around this, and
> > > > possibly approach some of our commercial users and friends to chip in
> > > with
> > > > some PR too.
> > > >
> > > > But going to 1.0 (and generating some media buzz around it) brings
> > > > responsibilities. If the media buzz brings in new users, we want to
> > make
> > > > sure our usability is as high as possible - this covers the app
> itself,
> > > as
> > > > well as the website and the documentation.
> > > >
> > > > So to answer your question with some more questions...
> > > >
> > > > Are we feature-complete?
> > > >
> > > > Do we have great usability? Good user stories for all our types of
> > users?
> > > >
> > > > Are we happy to freeze our API in its current state?
> > > >
> > > > Are we happy to accept a stricter deprecation policy going forward?
> > > >
> > > > Is there nothing that we want to deprecate before 1.0? (That would
> > imply
> > > > another 0.x release cycle)
> > > >
> > > > Have we removed every deprecated thing that we can? (If something is
> > > > deprecated but cannot be removed, why?)
> > > >
> > > > Do we have great documentation?
> > > >
> > > > Do we have a great website?
> > > >
> > > > Does our documentation and examples reflect the "best" (not
> deprecated,
> > > > outdated or suboptimal) way of doing things?
> > > >
> > > > Will the blueprints in the wider community be compatible with the
> > > proposed
> > > > 1.0 release or do they need updating? (We will need to work with
> those
> > > > blueprint owners to get the blueprints updated.)
> > > >
> > > > Are we prepared to personally get involved in a media and visibility
> > > push?
> > > > (e.g. using our own Twitter, networks, getting more people involved
> in
> > > > managing the official Apache Brooklyn social media channels, etc.)
> > > >
> > > > Are we prepared - in the event of a successful media blitz - to
> handle
> > > more
> > > > users coming to this list, IRC, Twitter etc. looking for help?
> > > >
> > > >
> > > > If we can answer "yes" to all of these questions, then we are ready
> to
> > > > release 1.0. If any of these questions is answered "no" or "maybe"
> then
> > > we
> > > > should wait, or consider making a 0.13.0 release first.
> > > >
> > > > Richard.
> > > >
> > > >
> > > > On 3 October 2017 at 16:33, Duncan Godwin <drigodwin@apache.org>
> > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > Following the release last week of Apache Brooklyn 0.12.0 I propose
> > > that
> > > > we
> > > > > make the next version of Apache Brooklyn 1.0.0.
> > > > >
> > > > > Apache Brooklyn is robust, stable, feature rich and being used in
> > > > > production by multiple enterprises. Our deprecation policy means
we
> > > > haven't
> > > > > treated it like a 0.x release in a very long time.
> > > > >
> > > > > With 0.12.0, we did the last major thing needed before a 1.0
> release:
> > > we
> > > > > switched to Karaf as the primary distribution and we deprecated the
> > > > > "classic mode". What does everyone think?
> > > > >
> > > > > Many thanks
> > > > >
> > > > > Duncan
> > > > >
> > > >
> > >
> > --
> >
> > Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> > https://cloudsoft.io/
> > Github: https://github.com/tbouron
> > Twitter: https://twitter.com/eltibouron
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message