On 27/11/2009 15:16, Andrew M. Hettinger wrote: > > Robert Milkowski wrote on 11/26/2009 06:06:43 AM: > > > > On Thu, 26 Nov 2009, Amanda Waite wrote: > > > > > On 26/11/2009 11:01, Robert Milkowski wrote: > > >> Hi, > > >> > > >> > > >> What happens if there is a package already in /contrib and a > maintainer > > >> submits and updated spec and it build successfully. Is the > package then > > >> automatically pushed to /contrib? > > >> > > > > > > No, it has to go through the same voting process. There's nothing > automatic > > > about promotions to /contrib. > > > > > > Makes sense however I think that whoever reviews it if she/he thinks > there > > aren't any big changes one vote imho should be enough to get it > promoted > > again. > > > > I respectively disagree, for two reasons. > > First, the voting process is about testing and detection of bugs and > conflicts; the introduction of which is nearly as likely as in a > "version bump" as in a new package. Therefore I think two people > reviewing is important, even for updates. further, I would like to see > a policy to this effect in code, by having SJ clear out all votes any > time a change is made. >
I don't really have a problem with requiring 2 votes for updates, quality is king after all. But I'd prefer one extensive review to two hurried one, and the more reviews we have to do the more likely you'll be to get the latter. I do feel that we should share testing/review information in the way that George (Drapeau) does via his blog. Then a second reviewer could focus on what potentially may have been missed. > > > Secondly, (and this may be my misinterpretations of our rules, please > correct me on it if I'm incorrect) we have members who can submit > packages, review them, and vote on them. Therefore if only one vote is > required, there are those who could, in theory, promote an update with > no review. I don't even really like the idea of some only having one > person review (although AFAIK in practice this has never happened, but > I think it does with license approval, and I don't have such a problem > there). This could be addressed with the simple clarification of the > procedure "no voteing for promotion on your own package." > We aren't able to vote on our own packages, the UI won't allow it. That's the way it should be and we should extend it to validation. Regards Amanda > > > > > > > It's another of the process issues that I feel need to be ironed > out, the > > > list grows: > > > > > > - Building a tree of dependent packages without having to have > each one > > > promoted to /contrib before preceding to the next > > > - Simplified process for contributing updates to existing packages > (maybe > > > just a single review) > > > - Automated process for promoting to /contrib > > > - Flag in review table to show that a package is ready to be voted on > > > - OSRs still required for Sun employees contributing to SJ as > hobby projects > > > > > > > Agree. > > > > SJ is one of the best systems I've seen along this lines to encourage > input. This is the first time I've really felt that my contributions > where welcomed in a project of this nature, and for that I'm thankful, > but I also concur that formally addressing some of these points can > only improve the process. > > > A Hettinger > http://Prominic.NET || AHettinger at Prominic.NET > Tel: 866.339.3169 (toll free) -or- +1.217.356.2888 x.110 (int'l) > Fax: 866.372.3356 (toll free) -or- +1.217.356.3356 (int'l) >
