[geeklog-devel] Bugtracker (was: New GL default theme)

[Jeff Hare]

Hello Vinny,

  Thanks for the thoughtful comments.  As an observation, as GL1 has
matured, the critical security related patches have tapered off as well.
Credit the core team for 

It could be beneficial to set firmer goals, but if we're still looking at
10-12 mos release cycles, that's a pretty long cycle to control and keep on
track.  

>From the point in time where we determine what a release should contain, and
get that functionality implemented, all sorts of needs are usually applying
pressure to alter course.  Long release cycles tend to breed inflated
expectations, even when everyone initially agreed to the result.  ...we
customers frequently forget what we agreed to.  :)

Instead of a pure agile process with branch-per-feature and complex merging,
how about something along the lines of what we do today, just scope each
release or dot-release much narrower and do more of them.  (The security
patches shouldn't be too difficult to manage for the rare cases where we
need to issue them these days)

How about defining each release with one (or two at most) main showcase
features and as many filler fixes as possible within the timeframe of the
showcase features.   ...maybe issuing these 3 times a year?   I could wait 4
mos for a fix or feature, but annual releases usually means I'm off to fix
it myself and deal with the complications of upgrading next year.

What do you think?

-Jeff
 



-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: Tuesday, November 27, 2007 12:34 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Bugtracker (was: New GL default theme)

Some comments inline...

On Nov 27, 2007 7:10 AM, Jeff Hare <geeklog at thehares.com> wrote:
> BUG/ENHANCEMENT/PROJECT TRACKING
> ================================
> Getting Mantis (or something similar) up and running is a great step in
the
> right direction, assuming that anyone could create/be granted a login to
> report and query issues. That should help users of GL communicate their
> needs to the developers or determine whether an upgrade contains what they
> need.  It obviously helps GL developers set consumer expectations in a
> realistic way as well.
>
>   SUGGESTION:
>   ===========
> I'd like to see a way for plugin developers to be able to manage issues
> related to their plug-ins using the same bug tracking system.  After all,
as
> a consumer, I think of GL as one system with many developers.
>
Mantis is very full featured and there is no reason why this couldn't
be supported.  I think Mantis can even support different "trackers"
being owned by different people.  Allowing plugin developers to
control their own bug-trackers.  A good idea.  Before anyone else
jumps in and starts working on this, I'd like to hear from Dwight on
his progress.

>
> SOFTWARE DEVELOPMENT LIFE CYCLE:
> ================================
> ...
>
>   SUGGESTION:
>   ===========
> An Agile process where we focus on developing/testing/releasing smaller
> Feature sets & Fixes and have more frequent micro-releases that are
> supported and well tested would allow people to upgrade continuously if
they
> wanted to, or only when they see a new feature or repairs they require.
>
> I'd be much more happy as an admin to apply patch releases 4-8 times a
year
> if I knew I didn't have to do much besides add or overlay some code files
> and run an upgrade script.  Today, it's a stressful process of comparing
> file trees, remembering all the things I had to change over the past year
> and determining whether those fixes are still needed or not, etc..
>
> Another benefit of a more Agile process combined with Mantis would be that
> the "consumer" expectations for each release are automatically lowered to
> more realistic levels because releases are more frequent and much smaller
in
> scope.  Having a way to Ping / "Me too" an open issue would help
developers
> know which issues are hot.
>
> All that said, I want to commend all the developers for devoting amazingly
> huge amounts of their personal time on GL and hope these comments are
taken
> as a constructive straw-man for moving forward and easing some burdens,
and
> *not* a critique of today's process.
A long time ago we discussed doing something like this.  What
prevented us from heading down that route is how we manged
security/bug fixes.  Since we support Geeklog versions for a couple
years, every time there is a security fix or major bug fix Dirk ends
up creating about three (or more) releases.  If we did 4 or 8 releases
in a year, I think you can see how maintaining them for bug/security
fixes could end up being a nightmare.  The alternative is to only
deliver bug/security fixes for a few of those releases, but that would
force people to upgrade to a supported release when a bug/security fix
is released.  I think that would take away many of the advantages of
continuous releases.

Another problem with changing development models is the reputation
that Geeklog has for full featured, well tested releases.  Shorter
development cycles mean shorter test cycles.  Geeklog stands pretty
strongly for its security and reliability, I'd hate to see that
reputation hurt.

Lastly, right now we have a very simple (and straight forward) CVS
repository.  All development happens in the main trunk, and branches
are only used for bug/security fixes for past releases.  An Agile
development process would demand separate branches for every major
feature change and require a much more complex CM structure.   There
is nothing wrong with this, except that it takes a lot of time and
effort to maintain a complex repository well.  Can we commit to that
without causing a slowdown of our process (which would defeat the
purpose of changing in the first place).

I know that the current releases have been slow in coming.  In the
past we've tried to target a six month release cycle.  We've been a
little slow of late, with 12+ months between 1.4.1 and 1.5, and 10
months between 1.4 and 1.4.1.  Do you think it would be enough set
some firmer goals for the next release?  For instance, say today (or
when 1.5 is released) that we'll have a feature freeze for 1.5.1 no
later than 5/1/2008 and aim for a 6/1/2008 release (and then do our
best to stick to that).

-Vinny
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel