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:fla...@redhat.com] > Sent: Friday, November 25, 2016 9:00 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@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:fla...@redhat.com] > >> Sent: Thursday, October 13, 2016 7:07 AM > >> To: OpenStack Development Mailing List (not for usage questions) > >> <openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > @flaper87 > Flavio Percoco
smime.p7s
Description: S/MIME cryptographic signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev