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

[Web Site Master]

I like the plugin bug tracker idea plus Mantis does support Bounties.

Sponsorships Support - users are able to place bounties or sponsorships for
specific issues, also developers can track such sponsorships / payments. 

Tom

-----Original Message-----
From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: November-27-07 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

__________ NOD32 2689 (20071127) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com