2012/1/27 Alexander Sack <a...@linaro.org>: > On Wed, Jan 25, 2012 at 7:14 PM, Christian Robottom Reis > <k...@linaro.org> wrote: >> On Tue, Jan 24, 2012 at 10:50:51AM -0500, Chris Lalancette wrote: > >>> 1) Attempt to reduce the number of trees on git.linaro.org. I >>> understand that there is probably a lot going on, but the sheer >>> number of trees makes it confusing. It might be a good idea to >>> remove some of the very stale or no longer active trees. >> >> What do Deepak and Loďc think of this in general? > > I would propose to: > * hide people/ trees and show them on people.git.linaro.org instead > of main git.linaro.org. At best git:// urls would be valid still > aftterwards > * hide the android/ trees and don't show them anywhere else; keep > git:// urls and/or http:// clone urls wprking too > > This would definitely air to breath and we can continue to improve > things from there. > >> >>> 2) Document on the wiki where the releases are built from, so there >>> is a running record per release >> >> Where would we record this, Deepak, Alexander, Loďc? > > I am thinking ... > > If it's about documenting released bits it's something that should > come out of our release process. The release team can bring that > together. For that the information needs to be shipped along- or > inside the source artifact. As one example, ubuntu packages having a > vcs-bzr field and a reasonable tagging/versioning scheme could > probably work, but we have to look case by case. > > Where are we putting it? > One place that comes to my mind is obviously the release wiki page: > https://wiki.linaro.org/Cycles/1201/Release/?
Another one is https://wiki.linaro.org/Cycles/ProjectsSummary I'd like to generate this table automatically to keep it up-to-date, based on inputs from packages meta data (using additional user-defined fields to debian/control file). _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
