Community
Participate
Working Groups
Many modeling projects now have distinct releases, milestones, nightly update sites. Please allow these to be entered in the updatesiteurl project meta-data.
I assume that we'll need to annotate the sites (e.g. release, milestone, nightly, daily, integration, ... am I missing some?). Or should we try to imply the purpose based on naming convention?
(In reply to comment #1) > I assume that we'll need to annotate the sites (e.g. release, milestone, > nightly, daily, integration, ... am I missing some?). Or should we try to imply > the purpose based on naming convention? In general, this is a great idea! Thanks Edward. I'd suggest standardizing on the names "release", "maintenance", "milestone", and "integration" as the annotation for the feilds ... and encourage the use of those 4 ... but, maybe also have a few "free form" fields, where projects could enter their own description? (I left out nightly and daily since I don't think those are common ones that we should encourage general, "public" use of ... but, not sure what all projects do here, maybe some do).
I can filter the kinds of update sites we display on the project summary page and other foundation-generated pages. i.e. I could just not display "nightly" update sites on the project summary page, or maybe only show them if a committer is logged in, or something...
Yes, naming conventions should apply. I think nightly is quite important. Certainly for the committer community it is important sometimes to use an N-build in order to progress bugs at faster than milestine rate.
(In reply to comment #4) > Yes, naming conventions should apply. I've skipped right over requirements, and into technical implementation :-) Do you think we can get away with using convention to determine the type of update site? e.g. /modeling/gmt/umlx/milestone/updates is a milestone update site /modeling/gmt/umlx/milestone1/updates is a milestone update site /modeling/gmt/umlx/maintenance/updates is a maintenance update site /modeling/gmt/umlx/updates is a release update site (default) I can use regular expressions to detect certain patterns and categorize accordingly. Or do we need to get the user to explicitly indicate the type using a drop-down? Personally, I like any option that lets us get away with (a) minimizing changes in the portal code, and (b) makes it easier for the committers. Actually, I'd put these in the reverse order...
(In reply to comment #5) > /modeling/gmt/umlx/milestone/updates is a milestone update site > /modeling/gmt/umlx/milestone1/updates is a milestone update site > /modeling/gmt/umlx/maintenance/updates is a maintenance update site > /modeling/gmt/umlx/updates is a release update site (default) Mmm. GMT/UMLX is an embarrassing example. If you recognise say four encouraged names, and bin the rest in 'uncategorized' that will motivate projects to standardize. Some projects use 'releases'.
It wasn't my intent to "call you out" :-) I thought it might make it more concrete to use one of your own projects as an example... Wayne (In reply to comment #6) > Mmm. GMT/UMLX is an embarrassing example.
*** Bug 369751 has been marked as a duplicate of this bug. ***
I am not sure if I am understanding something completely wrong, but why wouldn't it suffice to simply list several update site urls without interpreting them? I think most of the update sites urls are reasonably named and people can quite well infer from the names what they will get. And why should we hide a nightly update site to our community? Doesn't that contradict openess?
I think that I can declare victory here. I implemented this as part of another related effort some time ago. I went with a simple implementation. You can define as many update sites as you'd like and call them whatever makes the most sense. You also have control over the order in which they are displayed. See Bug 430692 for an update to how we render the update site URLs.
IMHO the only thing one could still opt for is some kind of a description that could be displayed to further describe the contents in case that makes sense (e.g.: this site is automatically published every Friday, old builds will always be removed, etc.).
(In reply to Alexander Nyssen from comment #11) > IMHO the only thing one could still opt for is some kind of a description > that could be displayed to further describe the contents in case that makes > sense (e.g.: this site is automatically published every Friday, old builds > will always be removed, etc.). Please open a new bug.
