Open Stack

Thanks Flavio,

I've logged https://bugs.launchpad.net/trove/+bug/1644851 for this and I 
assume that other projects which want to do this kind of manual cleanup can 
either use this bug or create their own.

-amrith

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: Friday, November 25, 2016 9:00 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata in
> README files
>
> On 25/11/16 13:46 +0000, Amrith Kumar wrote:
> >Flavio,
> >
> >I see a number of patches[1] which have been landed on this project but
> >I find that at least the ones that were landed for Trove, and a random
> >sampling of the others all to be different from what you proposed
> >below[2] in one important aspect.
> >
> >In [2] you proposed a structure where the title of the document; or the
> >first, and most prominent heading, would be the existing heading of the
> >document, and the tags would be below that. In [2] for example, that was:
> >
> >"kombu - Messaging library for Python"
> >
> >and the tags would be in smaller font below that.
>
> Hey Amrith,
>
> One reason it's different from Kombu is because Kombu uses shields as a
> backend for this SVGs, whereas we don't. We generate the badges
> ourselves[0], which probably ended up in some differences.
>
> The other main difference in the kombu case, there are multiple images in
> the README, wherease in our case there's one SVG containing multiple svgs.
> The motivation behind this is being able to update the badges without
> sending patches to projects everytime the governance repo is modified.
>
> This layout and format can of couse be modified, the font size and family 
> can
> be changed, etc. See[1].
>
> >What I see in [3] the patch for Trove and the proposed example [4] is:
> >
> >"Team and repository tags" as the first, and most conspicuous header,
> >and the header "Trove" below that.
> >
> >In some cases the second header is the same font as the "Team and
> >repository tags" header.
>
> I explained this a bit here[2]. The reason for prepending these secion to 
> the
> README's instead of finding a good place in it is that READMEs throughout
> OpenStack are quite different from each other and putting this at the top
> helped in making the process of adding the badges simpler.
>
> >I think this change (these 124 changes) as proposed are not consistent
> >with the proposal you made below, and certainly seem to be less
> >suitable than that proposal. The end product for the four trove
> >repositories [4], [5], [6], and [7]
> >
> >I think we should have a discussion on the ML whether we feel that this
> >new structure is the appropriate one, and before some projects approve
> >these changes and others don't that these be all marked WF-1.
>
> I honestly don't think the current proposal is bad, it's different from 
> Kombu
> for the reasons I mentioned above but it can be improved. Not that
> improving the badges and their layout doesn't require submitting these
> patches again. It'll be enough to modify the governance repo that generates
> these images.
>
> Hope this helps,
> Flavio
>
>
> [0]
> http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts
> /badges.py
> [1] https://review.openstack.org/#/c/399278/
> [2] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/107969.html
>
> >Thanks,
> >
> >-amrith
> >
> >[1] https://review.openstack.org/#/q/topic:project-badges
> >[2] https://github.com/celery/kombu/blob/master/README.rst
> >[3] https://review.openstack.org/#/c/402547/
> >[4]
> https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
> >[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
> >[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
> >[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Flavio Percoco [mailto:flavio at redhat.com]
> >> Sent: Thursday, October 13, 2016 7:07 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev at lists.openstack.org>
> >> Subject: Re: [openstack-dev] [all][tc] Exposing project team's
> >> metadata in README files
> >>
> >> On 12/10/16 11:01 -0400, Doug Hellmann wrote:
> >> >Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
> >> >> Greetings,
> >> >>
> >> >> One of the common complains about the existing project
> >> >> organization in the big tent is that it's difficult to wrap our
> >> >> heads around the many projects there are, their current state
> >> >> (in/out the big tent), their
> >> tags, etc.
> >> >>
> >> >> This information is available on the governance website[0]. Each
> >> >> official project team has a page there containing the information
> >> >> related to the deliverables managed by that team. Unfortunately, I
> >> >> don't think this page is checked often enough and I believe it's
> >> >> not known
> >> by everyone.
> >> >>
> >> >> In the hope that we can make this information clearer to people
> >> >> browsing the many repos (most likely on github), I'd like to
> >> >> propose that we include the information of each deliverable in the
> >> >> readme file. This information would be rendered along with the
> >> >> rest of the readme (at least on Github, which might not be our
> >> >> main repo but it's the
> >> place most humans go to to check our projects).
> >> >>
> >> >> Rather than duplicating this information, I'd like to find a way
> >> >> to just "include it" in the Readme file. As far as showing the
> >> >> "official" badge goes, I believe it'd be quite simple. We can do
> >> >> it the same way CI tags are exposed when using travis (just
> >> >> include an image). As for the rest of the tags, it might require some
> extra hacking.
> >> >>
> >> >> So, before I start digging more into this, I wanted to get other
> >> >> opinions/ideas on this topic and how we can make this information
> >> >> more evident to the rest of the community (and people not as
> >> >> familiar
> >> with our processes as some of us are).
> >> >>
> >> >> Thanks in advance,
> >> >> Flavio
> >> >>
> >> >> [0] http://governance.openstack.org/reference/projects/index.html
> >> >>
> >> >
> >> >Is your proposal that a tag like release:cycle-with-milestones would
> >> >result in a badge being added when the README.rst is rendered on
> >> >github.com? Would that work for git.openstack.org, too?
> >>
> >> I don't think it'd work for git.openstack.org because it doesn't
> >> render the README's[0] like github does. One thing I'd like to avoid
> >> is for this information to result in new changes to the README file
> >> everytime the tags are updated because I'd like for this information
> >> to not be duplicated and to make it clear that this information is
> >> not meant to be updated manually.
> >>
> >> Here's[1] an example of what it would look like (or kinda).
> >>
> >> [0] http://git.openstack.org/cgit/openstack/glance/tree/README.rst
> >> [1] https://github.com/celery/kombu/blob/master/README.rst
> >>
> >>
> >> >I agree that the governance site is not the best place to put the
> >> >info to make it discoverable. Do users look first at the source
> >> >repository, or at some other documentation?
> >>
> >> The feedback* I've gotten is that users normally look at repos first
> >> and they go from there to docs (which are normally linked in the
> >> README file).
> >>
> >> * Neither based on a survey nor on any empirical research. This is based
> on
> >>   hallway talks.
> >>
> >> Flavio
> >>
> >> --
> >> @flaper87
> >> Flavio Percoco
>
>
>
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> @flaper87
> Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4805 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161125/9e09f97c/attachment.bin>