Re: [Fresco-devel] What needs to be done for M2?

Tobias Hunger <[email protected]>
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 22 November 2002 06:16, Stefan Seefeld wrote:
> I understand your feelings, and I'm very keen on working on some
> interesting stuff again, now that the ban is broken :)
> But lets not forget about the bugs. We have an issue tracker precisely
> to be able to track our work and to define upfront what goals we want
> to reach (and reaching them we call 'hitting a milestone'). That helps
> us focus on stuff and get things really done, not just started.

Yes. Having some of them as release critical for M1 helped a lot to get them 
fixed IMHO. We should definitly keep that.

> I agree, but only to a certain degree. I do think that there needs to
> be a barrier, i.e. things have to be discussed before they get committed.
> I agree that it is important to encourage people to contribute, but I'm
> totally against the idea of 'commit now, fix later'.

I think we all are to a certain degree:-) We do have the tendency to talk 
things over till nobody wants to do them anymore though. We need to do 
something about that...

> > Yikes. I think that expecting all of this will push M2 off the
> > timescale. Are we thinking of releasing M2 "soon"? That seems to be the
> > consensus, so to be more specific, do we plan to release M2 before, say,
> >  Feb. 2003?
>
> I would like to see a much more regular / frequent release cycle. May be
> three months is a good interval.

Yes, it is quite some work:-) But it is nothing too mayor. I'd like to stick 
to a 3/4 month cycle myself, but I do not consider a time-driven release plan 
to be feastable for us right now. There's just too many 'big issues' open 
that will not fit into such a short cycle with the limited manpower we have.

And nothing stops us from having more then one new release in the tracker 
anyway. Maybe we should have 10 or so and do some strategic long term 
planning by assigning tasks to all of them simultaniously?

> These tasks are pretty long and complex, so I don't expect them to
> be manageable in a three month timescale. And in general, I don't
> think we should focus only on those tasks we think we'll close before
> the next release, or else we'd not be able to work on long-term projects
> at all. But may be some progress could be visible after a while.
> What about 'task: provide a simple menu system' ?

Agreed. It's just that having a list of need to be done tasks and bugs that 
need to be fixed helps me to stay focused. From what I saw (release in two 
month after tracker was introduced while nobody had iny clue what needed to 
be done for month before) it's the same for other people on the project. I'd 
rather not loose that edge.

And right now Fresco is a bitch to debug. We defninitly need to work on that, 
that's why I picked the tasks listed in my original mail. I'll focus on those 
anyway:-)

So what is the consensus on having a more formalized release cycle approach? 
Like the implement tasks - feature freeze - fix bugs - release? I really 
would consider a feature freeze helpful: It makes fixing bugs so much more 
urgent for me that I actually fix some of them and stop putting that of till 
after the release. And even if we don't have users yet, having some bugs 
fixed before they are exposed to them will make it easier to sell Fresco to 
them later.

- -- 
Gruss,
Tobias

- ------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE93iI0v0FZW3NyoqURAkE0AKCqeM0yk328afmxAouLdBb0/y6BTACaArlG
auyEdi3qQ2M5g2VdImP9nk0=
=2/ks
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.