Good morning!
You must be so busy! But from what you are saying the process is
pretty much straight forward and you already have a good delivery
system (downloads on web2py.com). If we expand a little on that, we
may be able to settle a few issues quickly enough.
1. Michele's idea is perfect here. A simple bug tracking system built
on your great framework. Simple to start with (but made in such a way
that adding functionality is easy.
1.1. - include the date/time stamp in the version number (I.e. today;s
stable build is versionned: 1.83.2.20100815081630)
1.2. add the version numbers to nightly builds as posted.
2. simple bug tracking app:
a few fields to start with:
* "bug found in:" <drop down with available builds>
* "category:" <drop down of available categories> (i.e. web2py
classes, web2py on apache, localization, DB connection, etc... you
would know how to categorize)
" "logged by:" <logged-in user>
* "description:" TEXT field
* " How to reproduce:" TEXT field
* "bug status:" is_bug/is_not_bug
if "is_bug" then "status:" field:
"will fix for:" date/next major release/etc...
if :is_not_bug:" then: "resolution - description"
* admin (you or web2py test leads can move items from one category to
another if logged against wrong one
* "fix description:" TEXT field
* generate_ticket(): return ticket (number based on <"found in build
number">.loggedOnDate.userID (or something meaningfull)
anyways, whatever data the Form should be getting... nightly build
automation generates good build notes based on those ticket items. and
the Stable build contains the cumulative build notes (from stable
build to stable build). Users are then encouraged to grab latest and
greatest build (if they really want their big fix). This may be a
little easier to track if the bug has already been logged. And, you
have an easier time going through bugs and/or hand off some of this
work to one of your leads (sonce the bug history and criteria are all
in one place). Users have a better time in seeing that the big has
been fixed/will be fixed/rejected without you having to send emails
(some of the onus now goes to the user for status)
This could make things easy for you, I would really consider making
something that integrates all of your requirements in one place/app.
(build/reporting/bug_tracking/source code management)... This would be
a great opportunity to ask of your web2py super stars to come up with
an app that intagrates all of those items (either as one app, or as
multiples with good data sharing capabilities). There are good (and
free openSource bug tracking systems out there - but may be a little
more work to integrate?)... besides nothing like using/promoting you
own great fraework for showcasing :) )
Mart :)
On Aug 25, 9:45 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> we do use googlecode for not. Here is the current (imperfect) process:
>
> 1) people post a question about a possible bug
> 2) somebody checks that it is a bug, usually me
> 3) if the bug does not get fixed in 24h, the original poster opens a
> googlecode ticket
> 4) when the bug is fixed the ticket is closed
>
> because many bugs are dealt with in <24hrs there is no record. Because
> bugs are fixed in trunk and trunk takes a couple of weeks to become
> steable and because most users never upgrade to the latest stable,
> occasionally there are multiple questions related to the same fixed
> bug. I am not sure better workflow management fixes this latter
> problem.
>
> I have not read all messages on this thread carefully yet. Eventually
> I will but I am happy to hear more of your ideas.
>
> On Aug 24, 5:52 pm, Michele Comitini <michele.comit...@gmail.com>
> wrote:
>
> > Actually I would like to ask if bug tracking is used on web2py?
>
> > Code is available from either (btw Massimo how do you keep those 2 in
> > sync? just too curious :-) ):
> > a) googlecode (with hg)
> > b) launchpad (with bzr)
>
> > both have some sort of bugtracking ticket system I do not know which
> > one is best (or worst), we could start with one those, but
> > the choice must taken with care and other systems must be evaluated
> > (on: usability, independece, web2py phylosophy ...), and first
> > they must meet Massimo needs.
>
> > BTW: I would like to see a web2py application for doing serious
> > bugtracking in the future... so that submitting
> > a bug would be just one click on the ticket reported by any web2py
> > installation! mmm too easy... that would be dangerous! ;-)
>
> > ciao,
> > mic
>
> > 2010/8/24 mart <msenecal...@gmail.com>:
>
> > > I don't know if you are currently using a specific bug tracking
> > > system, but they are typically easy to interface with and made part of
> > > build/release & test processes/automation. I.e. As part of a release
> > > process, I would set rules with the source control system where non-
> > > bugTraking releated changes can either be automatically rejected, or
> > > moved to another set of prioritiesArea, etc... the build (or packaged
> > > fileset, or whatever the output is) contains a detailed inventory of
> > > bug fixes/features/etc... as part of an automated delivery system
> > > (these are part of the build notes)...
