On 10/3/07, ant elder <[EMAIL PROTECTED]> wrote: > On 10/2/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > > > On 10/2/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > > > i'm thinking more of a benevolent educator than traffic warden > > > > style reviewer role. > > > > > > When it comes to legal issues related to a release, the warden role is > > the > > > more appropriate. It benefits neither the project nor the ASF if we are > > lax > > > in that regard. > > > > > > Some of the things that they need to do are identified by RAT, and would > > be > > > non-issues if they would correct their build process to do them > > > automatically, e.g., inserting the license and disclaimer files where > > they > > > are supposed to go. > > > > i do believe that there's a definite problem here. there's too much > > energy wasted by everyone. > > > > the IPMC cannot actively oversee the code bases without automation. > > so, the only real oversight happens at release time. this is bad for > > everyone. really, we need to automatically scan and analyse the > > incubator codebases. > > > > i hope that http://wiki.apache.org/incubator/RatProposal may help > > > That RAT proposal looks really good, its just what we need. I can't promise > to contribute much code but i'd definitely hang around and help test it on > things.
hopefully it will be easy to contribute in small ways without too much effort. this is particularly important since a lot of meta-data needs to be collected. this probably isn't feasible without active help from contributors. for example, a good guessing algorithm for generated files needs good meta-data about the ways common programs mark files as generated. so release managers can contribute by submitting new patterns whenever RAT doesn't correctly recognize a generated file. another example, discordia aims to collect meta-data allowing artifacts to be matched to license meta-data. when release managers encounter a jar (or other binary artifact unknown to discordia) they can submit meta-data. > Until that gets implemented (or maybe as part of its design?) could there be > a wiki page documenting each rule RAT would check? RAT just automates tedious checks that reviewers carry out by hand. again, this is going to require collection of meta-data analysis rules for automation. > That way we could have a > complete list of each specific requirement in one place to make it easier > for both podlings and reviewers to check manually till RAT is done. If we > had such a list then it could be only the things documented there are > release blockers, or at least if a release is blocked the reason should get > added to the list so we eventually have a fairly compressive list of the > rules so everyone knows what to expect. different people have different ideas about what are blockers and IMHO this is good i've seen very few -1's, what's much more common is for people with criticisms to post them and not offer a vote i would expect a -1 only if the apache policies were broken > I'd have a go at creating such wiki page with the rules I know about if > people think its useful but i expect others would need to help out if its > going to get very comprehensive :) IMHO the wiki is just a distraction: the real problem is that the release management page is very unfinished. if there are people with time then improving would be great. volunteers? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
