[gobolinux-devel] Status of 014?

[Carlo Calica]

On 7/15/07, Lucas C. Villa Real <lucasvr at gobolinux.org> wrote:
>
> >     While it's too late in the process to implement now, may I make the
> > following suggestions for 015?
> >     1. Clear roadmap. Use the wiki for this. Once 014 is released, announce on
> > the forums and mailing lists that suggestions for 015 are open for a limited
> > time period (say one month). That way, everyone can contribute to what they
> > think should be in 015. Obviously, there will be items that won't be
> > attainable, but for the first month, let everyone brainstorm. If there are
> > people interested in implementing a functionality, that would also be the
> > place to volunteer. At the end of the month, go through the suggestions and
> > from that, create the roadmap.
>
> Good.
>

For 015 I'd like to see a branch.  The reason for this is to push
/System/Index and Compile 2.0 while allowing bugfixes for existing
code.  Also move the tools from savannah to svn.gobolinux.org

>
> What we were targetting in 013 was in fact a way to make it possible
> for anyone to reproduce the development environment, making it
> unnecessary for developers to "hold a token" while doing their
> changes. The development scripts have matured *a lot* since 012, up to
> the point where anyone can help. But yeah, I have to admit that we've
> not had a good organization in the sense of setting roadmaps and
> filling progress reports. I hope that once Carlo starts to focus on
> this, everything turns more transparent for everyone.
>

I'd like to see more people responsible for creating packages for the
ISO.  Only need a handful of people but it'll really help.  They'll
just u/l to a store and update a file in svn.  Then the dev scripts
can support automated weekly builds of the ISO.  Release early and
often.

We should take advantage of virtualization to provide a consistent
build environment for all packagers.  qemu images should be our
standard.  They'll work with qemu, kvm, lguest, (xen??).

Are CPU cycles an issue for anyone?  If so, a distcc  via vpn is a
possiblity but CPUs are really cheap.

> >     3. Clear release schedules. Rather than waiting for months on end between
> > releases that unexpectedly appear, create a schedule and stick to it. The
> > long wait periods just sap energy and excitement. Speaking personally, I
> > *need* a deadline if I really want to get work done. If I don't have a date,
> > then things tend to slip. Simply as a suggestion, here is a six-month
> > schedule that seems reasonable in its "do-ability":
> >     Jan 1-31: Community brainstorming time. Create roadmap and progress page
> > at the end of this time period.
> >     Feb. 1 - Apr 30: Chief development time; update progress page as things
> > develop.
> >     May 1: Beta release issued, so that everyone can "re-sync" with
> > development.
> >     May 21: RC1 released.
> >     Jun. 12 RC2 released.
> >     Jul. 1 Final released.
> >
> >     I put the releases three weeks apart, since that seems to be peak testing
> > time. People test it for a week, week and a half, and then generally move on.
> > With proper assignment, bug fixes can be prepared in time before the next
> > release. Whatever the dates are, what is important is that there are dates,
> > and that they are followed as closely as possible.
> >     What say you all?
>
> Sounds good. However, it's important to notice the number of people
> doing real development -- it doesn't help too much if we have
> deadlines set but only 3 or 4 part-time devs available for checking
> the bugtrack, answering to the mailing lists/forums, doing
> development, testing and all that stuff. The ISO process consumes a
> lot of time, unfortunately, so we just have to consider these real
> problems before setting any roadmaps.
>

automated snapshots of the ISO should help.  Strict time based
releases are difficult for a volunteer organization.  But feature
based releases can be the kiss of death too.



-- 
Carlo J. Calica