Some Project Planning

[DoC hEx]

From reading some of the most recent posts it sounds like you guys need to sit down and do some Project Planning before you get to far into any development cycles.

Here’s my 2-cent:

This is just one way of doing it, but you guys really should spend a little time now deciding where it is exactly you see GKnot going, (i.e. long-term project goals). Then you should decide what should get done first and have a planned road to get you to your long-term project goals, taking small steps in each new version of GKnot.

You should start a new thread on this forum that lists future feature for GKnot. While all new feature requests should be made on the SourceForge project site Here (http://sourceforge.net/tracker/?atid=550087&group_id=77391&func=browse). Then take what’s listed there and decide in what order these new features will appear in GKnot, what version, and that is in line with the long-term goal.

This is an example, not a real plan I’ve just cut’n’pasted the current request list:

GKnot 0.28 alpha 3

713719 Removing comercials
713875 Support for CBR MP3 sound (and related)
713302 Support for codec image manipulation

GKnot 0.29

713779 Interface Filter Support
713882 Features that should increase user-friendliness

GKnot 0.30

712935 OGM Support


This way you can see where GKnot is heading and when a new feature will be implemented. It helps to stop feature creep, as once you decide that GKnot 0.29 is only going to have these features added, all other features can be included in the next versions, while the current beta can be tested and released. It also keeps the programmers focused on what should be done. Because, if you have lots of well intentioned programmers all coding without proper guidance it won’t take long before everybody is pissed off with each other as things won’t be progressing in a planned manner. Programmers should select what it is they want to work on, to make sure two people aren’t coding the same thing.

I’d like to help out with the coding in the project, but my Pascal’s a bit rusty at the moment, though I’m re-read my old books. Coding/Planning is my bread and butter, as I do a lot of development planning for banking software and have seen the inside of many projects from a logistics management point of view.

[DaveEL]

Originally posted by DoC hEx
From reading some of the most recent posts it sounds like you guys need to sit down and do some Project Planning before you get to far into any development cycles.


I’d like to help out with the coding in the project, but my Pascal’s a bit rusty at the moment, though I’m re-read my old books. Coding/Planning is my bread and butter, as I do a lot of development planning for banking software and have seen the inside of many projects from a logistics management point of view.

I personall agree, but as len0x is the only person doing any work and he prefers to work the current way i don't think anyone else has a right to stop him, when you have got your pascal up to scratch to the point you can contribute then feel free to start such organisational talks but until then what gets done, when and how it up to len0x.

In terms of the feature tracking priorities can already be assigned (ive already changed the priority of one of them) and target versions can be assigned via the group field so duplicating this information in a thread seems like a waste of time.

DaveEL

[len0x]

I'm actually looking at requests, don't worry.

Small cosmetic changes will go into 0.28 final if they are not too many of them.

I want to have 0.28 as stable as it could be, so testing is required... (actually as of alpha 4 I'm using it already for my scheduled encodes, I hope I eliminated most of the serious stuff,
but you never know...)

All the planning will go after that
(and we all can prioritized OGM/XVID/Profiles requests and discuss what's the best way to go about them)

It's just some stuff requires _serious_ rewriting (I mean from scratch) and the more support for different codecs/formats we have the more we have to rewrite afterwards (Unless we start right now and delay even support 5.0.3/4 for a while, which I don't want to do at the moment...)

[DoC hEx]

I’m not trying to step on anybody’s toes, I just want to make sure you can scale up the development as soon as you have more people. Also you need to have a list of things ‘to do’, so other people can see where help is required. This way somebody can say they’re going off to write “this feature”, and then when they’re done, it’s merge back into the main project source. Rather then people just stabbing at parts of the GKnot source, without anybody trying to make sure there is some planned way to modify code. Otherwise the source will end up a mess, someone needs to make sure that modifications are done in a structured way.

Also after you hack 0.28 with whatever features you want, you should sit down and see if parts of the code need to be completely rewritten! It will slow down initial releases, but you’ll end up with something that will scale better and will be easier to add new features. The fact that there is already a working version means you can see how it works and then recode it to be inline with a structured development plan.

Of course if you don’t have longer-term goals, then hacking is the way to go. But if you want to code something you need to plan! Otherwise the source code will suffocate itself, becoming impossible to maintain and more difficult to add new features.

[len0x]

Originally posted by DoC hEx
Also after you hack 0.28 with whatever features you want, you should sit down and see if parts of the code need to be completely rewritten! It will slow down initial releases, but you’ll end up with something that will scale better and will be easier to add new features. The fact that there is already a working version means you can see how it works and then recode it to be inline with a structured development plan.

Of course if you don’t have longer-term goals, then hacking is the way to go. But if you want to code something you need to plan! Otherwise the source code will suffocate itself, becoming impossible to maintain and more difficult to add new features.

It's actually excatly what I said here and in another thread.
I have ideas already what has to be rewriten (technical not for the common discussion), and I can discuss that with those who can do the programming...

I do understand how everything should work (I work in a software company), but also know that some things will never be done if you don't start :)

[DoC hEx]

I just want to make sure that it's not a pack of teenagers hacking GKnot to death. I'll say no more.

[DaveEL]

Actually hacking the code at this point is good is gives you a good idea of how things fit together and helps you to see what parts need rewriting.

DaveEL