Just a thought, but Sept 1st is coming up. That's as good a release date for the next version of Sword as any at this point. However, if going with bi-annual, then I'd suggest maybe dates near the end of vacations from school semesters as there seem to be a number of students working on Sword. Maybe we can start actively scheduling bug squashing parties also.
<br><br>If this idea is of any worth, I'd also like to suggest that dates be chosen that overlap the winter and summer breaks of not only people in the Northern hemisphere but also the Southern.<br><br>-DJ<br><br><div>
<span class="gmail_quote">On 8/29/07, <b class="gmail_sendername">Troy A. Griffitts</b> <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Karl,<br><br>You are right. The Bibletime team has asked me to commit to a quarterly<br>release cycle. They have said that it would inspire more development if<br>developers knew their code would be released in a timely manner. I
<br>would like to release more often.<br><br>I hate releasing when I know there are outstanding issue. Maybe because<br>the releases have been so far apart and I feel if I don't get things in,<br>they won't be in for a long time.
<br><br>It all seems a catch 22. Developers don't contribute because they don't<br>see their work released. I won't release because developers won't<br>contribute and fix the outstanding bugs... yada yada. (Did you know
<br>'YADA' mean 'I Know' in Hebrew?)<br><br>So, I would like to commit to regular releases for your team, the<br>Bibletime team, and others using the engine. I don't think I could<br>commit to quarterly releases right now. I agree we definitely need to
<br>release more than once a year. Is there a middle ground we can<br>negotiate between quarterly and biannually?<br><br>Looking at <a href="http://fedoraproject.org">fedoraproject.org</a>, it looks like they have nearly annual
<br>release cycles. If we commit at least to twice a year, we will assure a<br>new release for each fedora release.<br><br>We also could be more disciplined doing point releases of bug fixes. I<br>have failed completely in this area. Every release has been when we
<br>feel we have enough new features to warrant a release.<br><br>I have also not been forced to be motivated because I use SVN for most<br>all of my work and release BibleCS compiled statically against SVN.<br><br>So, in response, I say "Yes, thank you for the kick in the butt (and the
<br>previous kick in the butt by Martin from Bibletime-- to which I had<br>mentally queue this message).<br><br>Let's negotiate a set release schedule target to shoot for.<br><br>Let's be more mindful of point releases between these target release dates.
<br><br>And of course I would appreciate leads to encourage our teams to check<br>the bug list and try to be proactive fixing engine bugs.<br><br>My apologies for the negligence.<br><br> -Troy.<br><br>PS. Jira (our bug tracker) seems to be down. We just did major server
<br>upgrades of Java and Tomcat. I'll see if I can get things back online<br>shortly.<br><br><br><br>Karl Kleinpaste wrote:<br>> I write here today as a sort of /agent provocateur/, hoping to get a bit<br>> of a rise out of...well, somebody, possibly several somebodies. The
<br>> formal idea of an /agent provocateur/ is someone actually in opposition<br>> to the organization's goals; that is not me, that is, I am of course<br>> supportive of Sword. But I am explicitly hoping to provoke conversation
<br>> and debate, and possibly argument, but ultimately action.<br>> ________________________________<br>><br>> In roughly 6 weeks, an entire year will have passed since the release of<br>>
1.5.9. Since that time, 3 or 4 releases of BibleTime have come out, 7<br>> releases of GnomeSword (none since March), 2 releases of MacSword, and<br>> (based on Crosswire front page info) at least a couple of BibleDesktop.
<br>><br>> We of GnomeSword have been in a holding pattern before making our next<br>> release for a while now, hoping for 1.5.10 to come out, which will<br>> provide certain needed bits of substructure that are available today
<br>> only to those who build Sword for themselves out of SVN. I know that<br>> the BibleTime folks are in a similar position.<br>><br>> As a wide-view matter of project policy, just-once-per-year release of<br>
> the underlying substrate upon which the UIs depend is simply nowhere<br>> near often enough. Shortly after the release of 1.5.9, the problem of<br>> bugs in "&entity;" handling arose; a number of other bugs have been
<br>> fixed, e.g. related to matters such as morph output, and a number of<br>> formatting glitches; several small but important (to us) features have<br>> been added, such as <figure>/<img> linkages for our UIs which handle
<br>> graphical content. And we, and more importantly our users, are being<br>> held back, in a practical sense, because no one can get at these<br>> features and bugfixes if they depend on the mere yearly releases of
<br>> Sword. Rather few folks are motivated to build backend libraries on<br>> their own, but everybody would be happy to upgrade automatically using<br>> their systems' package managers, if only there was something to upgrade.
<br>><br>> I know that this is technically volunteer work for all of us. I know<br>> that we do it when we have both motivation and time. I know that Troy<br>> in particular has had a hard school schedule and that the demands on him
<br>> for that are high. But on the other hand, I know that people actually<br>> do the things in which they invest themselves.<br>><br>> Shortly after the initial call for 1.5.10 -- already 10 weeks in the<br>
> past -- on request I filed a half dozen bug reports for things I knew<br>> needed attention. Troy and I spent a little time on 2 of them; as far<br>> as I know, the other 4 have received no attention at all, and none have
<br>> achieved resolution.<br>><br>> At this point, what I believe is needed in the short term is a new<br>> release "right away" (interpret those words in some appropriately fuzzy<br>> fashion) in order to get as much benefit as is immediately available
<br>> from today's SVN. Call it 1.5.10, or call it 1.5.9a if you like, but<br>> *call it*, and soon.<br>><br>> For the long term, I believe a more stringent, regular schedule for<br>> advancement and release is very badly needed. Today's offhand,
<br>> imprecise, uncertain, when-we-feel-like-it, when-we-get-around-to-it<br>> attitude is definitely hurting the projects, and makes all the projects<br>> unhealthy to one degree or another. Indeed, and frankly, it is
<br>> unprofessional. It makes the rest of us delay our work. It makes our<br>> work appear to be of lower quality than it ought by rights to appear,<br>> because the improvements to the substrate that will make our work look
<br>> good continue to be unavailable.<br>><br>> --karl<br>><br>> _______________________________________________<br>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org
</a><br>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>> Instructions to unsubscribe/change your settings at above page<br><br><br>_______________________________________________
<br>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel
</a><br>Instructions to unsubscribe/change your settings at above page<br></blockquote></div><br>