About voting for validated files, in order to create a beta-release, I plan to create a dedicated wiki page. Thinking again about using GC review tool, it won't help to centralize things (need to vote for each revision). And voting through a mailing thread won't help too (need to read the whole topic). With a wiki page, it's centralized, everybody brings his own vote on the page. Are you ok with this ?
Another question: who wants to vote ? (to know how many columns I need :)) Cheers, Seb On 4 oct, 08:13, "Joep Suijs" <[EMAIL PROTECTED]> wrote: > Go for 1, release soon. Call it beta to set expectations a bit low. > > I think for option 2, it takes 4 weeks to get to 80% and an other 4 > weeks to finish it. Time tends to go faster then progress ;-) > > Joep > > 2008/10/3, Sebastien Lelong <[EMAIL PROTECTED]>: > > > > > > I agree that the first release should include everything we have as far > > > as we are confident it works (but maybe not in all situations and not > > > for all combinations). Maybe we should make a poll here with the list of > > > the release candidates such that everybody can say yes/no/no-opinion. > > > I was thinking about using google code review tools (vote), but maybe > > it can be simpler here in the list. Using GC code review tool can help > > "concentrate", focus the information (votes, comments). > > > > We must make an 'attractive' announcement message in which we say that > > > we are proud to present the first release of Jallib and mention that we > > > have some libs (and docs?) in the pipeline which are not yet ready for > > > release, and that we are looking for more contributions. > > > Yes, and we also have to prepare the CHANGES file. This one can be > > used as part of the "we're proud to announce" message's content (as a > > summary, what did we do, what did we improve). > > > > And we should be prepared for support questions and bug reports! > > > Yes, I except more questions than bug reports :) > > > > I suppose we'll use the 'issue' feature of Google code to track bugs > > > etc. and have a list of default first line problem solvers for bugs. I > > > mean that for example problems with device files will be assigned to me, > > > and similarly for every library a predefined person will be addressed. > > > Maybe I can add a new type, so we know which issue are coming from > > jallist. What's your opinion ? Is the existing "Defect" be enough ? > > Maybe we could add a Source field: "Source-jallib", "Source-Jallib". > > > > > As I said, we still need to focus on validating process, test results, > > > > and ease the way new contributors could join. Once done, once > > > > released, I think we'll have a solid base so new users could adopt and/ > > > > or join jallib. > > > > Hopefully we'll attract new contributors! > > > My question now is: do you all want to: > > > 1. wait for test results page integration and a well validation > > process > > 2. start working of the release, without the test results. > > > I prefer 1., because it's a nice piece of information about what's > > been done, about the quality we provide. But I can understand some > > would want to skip it, *for now*, in favor of releasing now (or quite > > now) to meet our users. I'd say, very approximatively that 1. is 4- > > weeks of works, 2. is 2-weeks. So, 1. ? 2. (maybe a 3. I can't see ?) > > > > I read in Jallist that even Vasile doesn't currently know where to find > > > Jallib! He'll be informed very soon! > > > Yes, he will !!! > > > Cheers, > > Seb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
