On Thu, May 29, 2008 at 2:15 AM, John Summerfield <debian at herakles.homelinux.org> wrote: >> >> I dont agree with the 'Action to take' for a large number of packages >> there. eg. why should cft and facter be deleted ? and smolt is a part of the >> cobbler + func + smolt admin stack, and should stay together. > > If those packages are travelling together, then they should stay together. > However, if new cft appears without its companions, and gets no testing, > it's hard to justify its promotion. Well, that is for the builder to indicate. If he/she does not inform the rest about that we don't know that. So that is back to the communication part :-) > And this is just testing, deleting it here doesn't mean it vanishes from the > target repo. Correct. >> The biggest issue, as far as I can see it, is communitcation itself. > > Always, it's communication. > > I think email should _always_ go out, even if the builder doesn't intend it > to be promoted. If there's a point to putting it into the repo, it's to > share it, and if you want people to use it you have to tell them. Not completely true, some packages but through the built system are only meant for the builder (to test stuff, a new package not ready for general consumption, ...). It is the builder that decide when a package is ready for promotion to CentOSPlus or Extras and only then testing is needed IMHO. > The email must contain a summary of what's changed, and a summary of what > the package does. If I don't use it now, tell me why I might want to! Yep, true. > A lot of package descriptions are next to incomprehensible. Take this, from ...snip... > The email might link to a wiki, but don't expect users to use the wiki to > decide whether it's something they should test. > > I presume that these announcements would amount to quite a bit of email, > maybe enough to seriously change the nature of this list should they come > here. > > You might consider a new list, maybe "updates-announcements" where these > announcements go, and that responses be directed to this list. This list > might help where/if there are different packagers on different platforms: > Joe builds on IA32, Fred sees he needs to build on zSeries and Freda on > Power. > > Seed it with members of this list, it's little different from just sending > mail here, and gives users of this list the ability to opt out. This would > ensure there's a decent number of eyeballs seeing its contents from day one. > > The list description for the new list would recommend also subscribing to > this list, but I don't think everyone will want to. > > The description of this list should be updated to recommend new subscribers > also subscribe to updates-announcements so as to keep abreast of threatened > changes. Again, not everyone will want to. Looking at the amount of packages built, I do not think it will generate a huge amount of additional traffic, but still something to look out for. If the amount of traffic gets to high we should indeed consider a seperate list. > If there's a formal test procedure for a particular package, then this > should be described in its wiki document. I imagine some packages - gcc, > postgresql for example - might have established test cases to run, and > others might be added as new bugs are reported and resolved. Yes, we need test cases for the most common packages. Regards, Tim -- Tim Verhoeven - tim.verhoeven.be at gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. (Linus Torvalds)