From micktwomey at gmail.com  Wed Nov  1 15:10:25 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 1 Nov 2006 14:10:25 +0000
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <45454854.2080402@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se>
	<1162162142.8245.12.camel@kwaaitjie>
	<200610301025.46223.anthony@interlink.com.au>
	<45454854.2080402@sympatico.ca>
Message-ID: <50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>

Hi,

It seems we still have two outstanding points we haven't agreed upon:

* Where to keep the source (I favour a plain subversion + python.org setup)
* What meta tracker to use (I agree with a plain roundup setup on the box)

There seems to be general consensus on everything else.

Oh, and hi, I'm Michael :)

mick

On 10/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Anthony Baxter wrote:
> > On Monday 30 October 2006 09:49, Roch? Compaan wrote:
> >>> * Where should we keep our tracker bugs? I'm happy to keep the
> >>>   http://efod.se/ptt/ (python-tracker-tracker) online if you like.
> >> Why not just use another roundup instance on the same box for this?
> >
> >
> > Why not just use the same tracker?
>
> At least initially that would be hard. We are still in the phase where
> we discuss schema changes, and so it is better to not have to do these
> changes on a live tracker. (Also, as mentioned before, where do you
> report a bug about the tracker being unreachable ?)
>
> For the meta-tracker we don't need anything but the most basic (default)
> setup, i.e. this thing can go live instantly.
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From forsberg at efod.se  Wed Nov  1 15:32:42 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 1 Nov 2006 15:32:42 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
Message-ID: <200611011532.42802.forsberg@efod.se>

onsdag 01 november 2006 15:10 skrev Michael Twomey:
> Hi,
>
> It seems we still have two outstanding points we haven't agreed upon:
>
> * Where to keep the source (I favour a plain subversion + python.org setup)

I agree. Using existing subversion infrastructure is a good thing. That way, 
we don't have to worry about backups and stuff. 

> * What meta tracker to use (I agree with a plain roundup setup on the box)

Me too. I think there's some confusion on what we mean here - the idea is 
_not_  to use the same tracker, but another independent tracker instance 
running on the same box. 

If the box hosting both trackers is down, it's better to tell the people 
hosting it than to add a bug to the meta tracker.

Until we get a meta tracker online, we can however still use the one on 
http://efod.se/ptt/.

> Oh, and hi, I'm Michael :)

Nice to meet you! :-)

Cheers,
\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Wed Nov  1 15:51:31 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 09:51:31 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <200611011532.42802.forsberg@efod.se>
References: <87odrv6k2y.fsf@uterus.efod.se>
	<45454854.2080402@sympatico.ca>	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
Message-ID: <4548B473.8020605@sympatico.ca>

Erik Forsberg wrote:
> onsdag 01 november 2006 15:10 skrev Michael Twomey:
>> Hi,
>>
>> It seems we still have two outstanding points we haven't agreed upon:
>>
>> * Where to keep the source (I favour a plain subversion + python.org setup)
> 
> I agree. Using existing subversion infrastructure is a good thing. That way, 
> we don't have to worry about backups and stuff. 

Right. Brett, do we need accounts on python.org for this ?

>> * What meta tracker to use (I agree with a plain roundup setup on the box)
> 
> Me too. I think there's some confusion on what we mean here - the idea is 
> _not_  to use the same tracker, but another independent tracker instance 
> running on the same box. 

I agree.

> If the box hosting both trackers is down, it's better to tell the people 
> hosting it than to add a bug to the meta tracker.

Indeed. It is my understanding that the state of the machine will be monitored
anyways, so we only have to worry about the state of the trackers. :-)

Roch?, please let us know how we can help setting such a meta-tracker up,
or what else you need from us to get started. Thanks !

> Until we get a meta tracker online, we can however still use the one on 
> http://efod.se/ptt/.
> 
>> Oh, and hi, I'm Michael :)
> 
> Nice to meet you! :-)

Likewise !

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Wed Nov  1 15:51:54 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 1 Nov 2006 06:51:54 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <200611011532.42802.forsberg@efod.se>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
Message-ID: <f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>

OK I'm on board on this. Subversion on python.org, separate tracker
instance.

I'd like to hear what had to be done for the 'contest-winning' prototype,
and what the feedback was on it. Can we just put that one up? How did the
data get migrated?

I'm sorry that I didn't pay attention during that period.

On 11/1/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> onsdag 01 november 2006 15:10 skrev Michael Twomey:
> > Hi,
> >
> > It seems we still have two outstanding points we haven't agreed upon:
> >
> > * Where to keep the source (I favour a plain subversion + python.orgsetup)
>
> I agree. Using existing subversion infrastructure is a good thing. That
> way,
> we don't have to worry about backups and stuff.
>
> > * What meta tracker to use (I agree with a plain roundup setup on the
> box)
>
> Me too. I think there's some confusion on what we mean here - the idea is
> _not_  to use the same tracker, but another independent tracker instance
> running on the same box.
>
> If the box hosting both trackers is down, it's better to tell the people
> hosting it than to add a bug to the meta tracker.
>
> Until we get a meta tracker online, we can however still use the one on
> http://efod.se/ptt/.
>
> > Oh, and hi, I'm Michael :)
>
> Nice to meet you! :-)
>
> Cheers,
> \EF
> --
> http://efod.se/
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/dae36c5a/attachment.htm 

From seefeld at sympatico.ca  Wed Nov  1 16:19:04 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 10:19:04 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se>
	<45454854.2080402@sympatico.ca>	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
Message-ID: <4548BAE8.1030109@sympatico.ca>

Paul Dubois wrote:
> OK I'm on board on this. Subversion on python.org, separate tracker
> instance.
> 
> I'd like to hear what had to be done for the 'contest-winning' prototype,
> and what the feedback was on it. Can we just put that one up? How did the
> data get migrated?

The tracker instance contains a custom schema, and custom html templates.

Data were imported with a script Erik wrote that extracted the content
from the sf.net tracker.


What I think we should do is this:

* get our meta-tracker up and running

* set up a subversion module for the tracker, and import the existing
  prototype

* set up the 'real' tracker instance based on the prototype, and create
  accounts for us admins, as well as reviewers for experimentation; allow
  us to reinitialize it as we make changes to the schema

* ask the various reviewers of the prototype to provide us a shopping list
  of things to enhance, or, better yet, let them participate in the discussions
  in the meta-tracker

* enhance the tracker incrementally, until everybody is satisfied

* do a final import of the data from sf.net, and do the final switch


Does this sound like a plan ?

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From micktwomey at gmail.com  Wed Nov  1 16:21:20 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 1 Nov 2006 15:21:20 +0000
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548BAE8.1030109@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
Message-ID: <50a522ca0611010721s51a2b192rc5201591ef63bda7@mail.gmail.com>

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Does this sound like a plan ?
>

This sounds like a reasonable plan to me.

mick

From amk at amk.ca  Wed Nov  1 16:40:34 2006
From: amk at amk.ca (A.M. Kuchling)
Date: Wed, 1 Nov 2006 10:40:34 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548B473.8020605@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<4548B473.8020605@sympatico.ca>
Message-ID: <20061101154034.GB8408@localhost.localdomain>

On Wed, Nov 01, 2006 at 09:51:31AM -0500, Stefan Seefeld wrote:
> Right. Brett, do we need accounts on python.org for this ?

Not necessarily.  

For Subversion on python.org, we have a setup that uses your SSH key
to identify you; everyone uses the URL
svn+ssh://python at svn.python.org/, but commit access doesn't imply you
have shell access.  

The Python source repository has a post-commit hook that automatically
installs new keys committed to a certain directory in Subversion;
other repositories lack the post-commit hook, so someone needs shell
access to update the list of keys when a new one is added.

--amk

From forsberg at efod.se  Wed Nov  1 16:53:05 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 16:53:05 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548BAE8.1030109@sympatico.ca> (Stefan Seefeld's message of
	"Wed, 01 Nov 2006 10:19:04 -0500")
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
Message-ID: <877iyf6u5a.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> The tracker instance contains a custom schema, and custom html templates.
>
> Data were imported with a script Erik wrote that extracted the content
> from the sf.net tracker.

..using the SourceForge Tools created by effbot, available at
http://effbot.org/zone/sandbox-sourceforge.htm. Rumours says that they
need to be updated to reflect site design changes on Sourceforge, but
that's a minor detail.

> What I think we should do is this:
>
> * get our meta-tracker up and running

Absolutely, and of course we should do this by importing the data from
http://efod.se/ptt/. 

[snip]

> Does this sound like a plan ?

Absolutely!

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSMLhrJurFAusidkRAipyAKDQXAyTtt+rhlaC4Pxnq+fxWZWMEwCeI6Kv
SgbiVgeGScMclyGASEEuQPM=
=uI5s
-----END PGP SIGNATURE-----

From forsberg at efod.se  Wed Nov  1 16:58:11 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 16:58:11 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548B473.8020605@sympatico.ca> (Stefan Seefeld's message of
	"Wed, 01 Nov 2006 09:51:31 -0500")
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
Message-ID: <873b936tws.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Right. Brett, do we need accounts on python.org for this ?

Speaking of accounts - are there any existing user database we should
use (some kind of "global python user database"), or should we go for
a tracker-specific user database as in the prototype?

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSMQSrJurFAusidkRAmiAAJ0c1JJ8ATEzq0P9+qwki7GQ5J0H/QCeK1aH
ogbzWQsSDlh8bP+TGdJq8OM=
=WVX3
-----END PGP SIGNATURE-----

From pfdubois at gmail.com  Wed Nov  1 17:01:42 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 1 Nov 2006 08:01:42 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548BAE8.1030109@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
Message-ID: <f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>

1. I strongly suggest the vendor-branch method I mentioned before. That
would mean that in this case you create a 'vendor' branch consisting of the
version of Roundup that you modified to make the prototype. Then branch it
to 'ours'. Submit the prototype as a change to 'ours'. Then we can start
modifying it as needed.

If we don't do this extra step, when a new Roundup comes out we have an
awful job putting those changes into 'ours'. But with this scheme, we check
the new Roundup into 'vendor' and integrate to 'ours' and let the
source-code management tools for resolving conflicts be our friend.

It is possible that this is what you meant but I want to be sure. I did not
do this when I first used Roundup and at the time Richard had no suggestion
for me as to how to solve the problem. I paid a big price. But this scheme
really does the trick.

2. On the existing metatracker I noted a couple of bugs for the data
migration. Are these something we need to work on?

3. Perhaps everybody but me knows, but what method of deployment are we
going to use? I have only done the stand-alone server running behind Apache
with a proxy-pass, and I don't know the pros and cons of the various
approaches.

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
> > OK I'm on board on this. Subversion on python.org, separate tracker
> > instance.
> >
> > I'd like to hear what had to be done for the 'contest-winning'
> prototype,
> > and what the feedback was on it. Can we just put that one up? How did
> the
> > data get migrated?
>
> The tracker instance contains a custom schema, and custom html templates.
>
> Data were imported with a script Erik wrote that extracted the content
> from the sf.net tracker.
>
>
> What I think we should do is this:
>
> * get our meta-tracker up and running
>
> * set up a subversion module for the tracker, and import the existing
>   prototype
>
> * set up the 'real' tracker instance based on the prototype, and create
>   accounts for us admins, as well as reviewers for experimentation; allow
>   us to reinitialize it as we make changes to the schema
>
> * ask the various reviewers of the prototype to provide us a shopping list
>   of things to enhance, or, better yet, let them participate in the
> discussions
>   in the meta-tracker
>
> * enhance the tracker incrementally, until everybody is satisfied
>
> * do a final import of the data from sf.net, and do the final switch
>
>
> Does this sound like a plan ?
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/43de4777/attachment.htm 

From skip at pobox.com  Wed Nov  1 17:04:33 2006
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 1 Nov 2006 10:04:33 -0600
Subject: [Tracker-discuss] Trackers for other Python-based projects
Message-ID: <17736.50577.723941.859233@montanaro.dyndns.org>

I don't want to try running before crawling, but it occurred to me the other
day that given the huge amount of time and effort it's taken so far for the
core Python gang to migrate from SF to *any* other tracker, it might be
worthwhile to offer bug trackers for other Python-based open-source projects
once things have stabilized.  I realize there are a number of issues which
need to be taken care of:

    * The folks hosting the Python bug tracker and the maintainers here
      would of course have to agree to the extra resource consumption.

    * It would only work if the current crop of maintainers isn't
      overloaded.  To alleviate this, I think any other hosted project
      tracker would have to "donate" someone (more likely some part of
      someone) to the cause.

    * Migration from other trackers would be needed (I gather Fredrik Lundh
      has already done most of the work for SF-hosted projects).  I'd
      specify the input format and let the other projects take care of
      getting their current tracker's data into that format.

On the plus side, it might attract more people into core Python development

Martin v. L?wis didn't seem to think that it would be a big deal from a
technical standpoint.  Of course, the maintainers here will ultimately be
the judge of that.

Skip

From micktwomey at gmail.com  Wed Nov  1 17:11:53 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 1 Nov 2006 16:11:53 +0000
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
Message-ID: <50a522ca0611010811h333a218fq2d7a7c1bd8803aed@mail.gmail.com>

On 11/1/06, Paul Dubois <pfdubois at gmail.com> wrote:
> 1. I strongly suggest the vendor-branch method I mentioned before. That
> would mean that in this case you create a 'vendor' branch consisting of the
> version of Roundup that you modified to make the prototype. Then branch it
> to 'ours'. Submit the prototype as a change to 'ours'. Then we can start
> modifying it as needed.
>

I agree with this approach.

I do something similar using mercurial + patch queues. I import
releases of roundup into a local mercurial repository, clone and apply
(updating as needed) any custom patches I have. Mostly they are custom
hacks for my particular site, but one or two are bugfixes I send back
to the roundup project.

> 3. Perhaps everybody but me knows, but what method of deployment are we
> going to use? I have only done the stand-alone server running behind Apache
> with a proxy-pass, and I don't know the pros and cons of the various
> approaches.
>

I've only used roundup with the proxy pass (actually mod_rewrite)
approach too. I think we should benchmark performance of different
configurations on the production box to establish what works well.

mick

From micktwomey at gmail.com  Wed Nov  1 17:17:47 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 1 Nov 2006 16:17:47 +0000
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <17736.50577.723941.859233@montanaro.dyndns.org>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
Message-ID: <50a522ca0611010817k6b887af8p7baa5c3941b00d2@mail.gmail.com>

On 11/1/06, skip at pobox.com <skip at pobox.com> wrote:
>     * It would only work if the current crop of maintainers isn't
>       overloaded.  To alleviate this, I think any other hosted project
>       tracker would have to "donate" someone (more likely some part of
>       someone) to the cause.
>

I think this is definitely needed if different python projects want to
use slightly different schemas or templates, someone needs to maintain
them when roundup gets upgraded.

>     * Migration from other trackers would be needed (I gather Fredrik Lundh
>       has already done most of the work for SF-hosted projects).  I'd
>       specify the input format and let the other projects take care of
>       getting their current tracker's data into that format.
>

Sounds like a good way to go.


I think this might be something we can keep in the back of our minds.
If we can come up with a schema which covers python's needs, and hits
the 80/20 point for other projects this can be a cheap win for the
python community.

One obvious project to get onto the python servers would be roundup
itself, it's been lacking a roundup based tracker (in a twist of
irony).

mick

From seefeld at sympatico.ca  Wed Nov  1 17:26:38 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 11:26:38 -0500
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <17736.50577.723941.859233@montanaro.dyndns.org>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
Message-ID: <4548CABE.3060801@sympatico.ca>

skip at pobox.com wrote:
> I don't want to try running before crawling, but it occurred to me the other
> day that given the huge amount of time and effort it's taken so far for the
> core Python gang to migrate from SF to *any* other tracker, it might be
> worthwhile to offer bug trackers for other Python-based open-source projects
> once things have stabilized.  I realize there are a number of issues which
> need to be taken care of:
> 
>     * The folks hosting the Python bug tracker and the maintainers here
>       would of course have to agree to the extra resource consumption.

I think this depends on what you mean by 'python-based'. We touched
the topic of added support for tasks, PEPs, etc., as well as separate
trackers for other python implementations (ipython, jython, etc.).

But I don't think offering support for arbitrary Free Software projects
that happen to use python internally is on the table.


Regards,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Wed Nov  1 17:32:04 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 11:32:04 -0500
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <50a522ca0611010817k6b887af8p7baa5c3941b00d2@mail.gmail.com>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
	<50a522ca0611010817k6b887af8p7baa5c3941b00d2@mail.gmail.com>
Message-ID: <4548CC04.60108@sympatico.ca>

Michael Twomey wrote:

> One obvious project to get onto the python servers would be roundup
> itself, it's been lacking a roundup based tracker (in a twist of
> irony).

Yes !

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From skip at pobox.com  Wed Nov  1 17:34:34 2006
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 1 Nov 2006 10:34:34 -0600
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <4548CABE.3060801@sympatico.ca>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
	<4548CABE.3060801@sympatico.ca>
Message-ID: <17736.52378.697954.775797@montanaro.dyndns.org>


    Stefan> I think this depends on what you mean by 'python-based'. We
    Stefan> touched the topic of added support for tasks, PEPs, etc., as
    Stefan> well as separate trackers for other python implementations
    Stefan> (ipython, jython, etc.).

    Stefan> But I don't think offering support for arbitrary Free Software
    Stefan> projects that happen to use python internally is on the table.

That was precisely what I was thinking of: matplotlib, SpamBayes, PIL, etc.

PIL and matplotlib provide significant functionality not found in core
Python.  SpamBayes is a very visible application written in Python.  Both
matplotlib and SpamBayes are hosted on SF so must tolerate the same problems
as other SF projects.  Roundup (mentioned by Michael?) is another candidate.

Skip


From forsberg at efod.se  Wed Nov  1 17:34:44 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 17:34:44 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
	(Paul Dubois's message of "Wed, 1 Nov 2006 08:01:42 -0800")
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
Message-ID: <87lkmvxh0b.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Paul Dubois" <pfdubois at gmail.com> writes:

> 1. I strongly suggest the vendor-branch method I mentioned before. That
> would mean that in this case you create a 'vendor' branch consisting of the
> version of Roundup that you modified to make the prototype. Then branch it
> to 'ours'. Submit the prototype as a change to 'ours'. Then we can start
> modifying it as needed.

I'm with you on this one. I use vendor branches extensively at work,
and it's a very good way of managing code in this kind of project. 

One of my colleagues has written a tool for automating this kind of
task that is superiour to svn_load_dirs.pl (which only does half the
job). Here's a mailing list post with source code:

http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=56591

> 2. On the existing metatracker I noted a couple of bugs for the data
> migration. Are these something we need to work on?

Yes. 

> 3. Perhaps everybody but me knows, but what method of deployment are we
> going to use? I have only done the stand-alone server running behind Apache
> with a proxy-pass, and I don't know the pros and cons of the various
> approaches.

This needs to be discussed. I don't know what's best practice for
large installations of roundup. I'm running the demo tracker
(http://efod.se/python-tracker) and the meta tracker
(http://efod.se/ptt) via mod_python.

I guess Richard and/or the roundup-users list might have something to
say here.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSMyjrJurFAusidkRAux6AKCDLjFRUKYrWz9deg7GXMKVwgoT/QCfXYUW
2xO3Yi1L6lxHt8qT7N7lmgI=
=ygib
-----END PGP SIGNATURE-----

From skip at pobox.com  Wed Nov  1 17:45:32 2006
From: skip at pobox.com (skip at pobox.com)
Date: Wed, 1 Nov 2006 10:45:32 -0600
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <17736.52378.697954.775797@montanaro.dyndns.org>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
	<4548CABE.3060801@sympatico.ca>
	<17736.52378.697954.775797@montanaro.dyndns.org>
Message-ID: <17736.53036.4527.582333@montanaro.dyndns.org>


    Stefan> well as separate trackers for other python implementations
    Stefan> (ipython, jython, etc.).

After hitting the 's'end button I realized that ipython isn't a separate
implementation of Python.  It is just an application which happens to be
written in Python and tightly integrates with it.

At any rate, I put the idea out there not to expect a decision immediately
or to distract the maintainers from more important tasks.  I just wanted to
plant the seed so decisions you make now can be made with that in mind, and
not inadvertently make it impossible to do downstream.

Skip

From seefeld at sympatico.ca  Wed Nov  1 18:49:12 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 12:49:12 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>	
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	
	<200611011532.42802.forsberg@efod.se>	
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>	
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
Message-ID: <4548DE18.7020702@sympatico.ca>

Paul Dubois wrote:
> 1. I strongly suggest the vendor-branch method I mentioned before. That
> would mean that in this case you create a 'vendor' branch consisting of the
> version of Roundup that you modified to make the prototype. Then branch it
> to 'ours'. Submit the prototype as a change to 'ours'. Then we can start
> modifying it as needed.

Just to clarify: nobody modified roundup in order to build the prototype.
I don't anticipate us making modifications to any given roundup release,
so I'm not sure that putting the roundup code itself into a vendor branch
would benefit us in any way.

What we did work on was the tracker instance, which (I believe) evolved
out of a 'demo tracker' that was generated by running some 'demo.py'
script that ships with roundup packages.
But since we are not going to merge changes made to the demo tracker
to our own tracker, I don't think working with vendor branches here
makes much sense either.

> If we don't do this extra step, when a new Roundup comes out we have an
> awful job putting those changes into 'ours'. But with this scheme, we check
> the new Roundup into 'vendor' and integrate to 'ours' and let the
> source-code management tools for resolving conflicts be our friend.

Again, we don't modify roundup ourselves, so upgrading to a new roundup
version will incure the same amount of work for us, no matter whether
we have a copy in a vendor branch or not.

> It is possible that this is what you meant but I want to be sure. I did not
> do this when I first used Roundup and at the time Richard had no suggestion
> for me as to how to solve the problem. I paid a big price. But this scheme
> really does the trick.

Hmm, may be I'm completely missing what you are talking about then.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...


From micktwomey at gmail.com  Wed Nov  1 18:59:14 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 1 Nov 2006 17:59:14 +0000
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548DE18.7020702@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
	<4548DE18.7020702@sympatico.ca>
Message-ID: <50a522ca0611010959u4b8a143cud187d5c097acefbf@mail.gmail.com>

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Just to clarify: nobody modified roundup in order to build the prototype.
> I don't anticipate us making modifications to any given roundup release,
> so I'm not sure that putting the roundup code itself into a vendor branch
> would benefit us in any way.
>

I think one line of thinking being advocated here is handling things
like critical bugfixes and backports. It might take us 5 days to
update the python tracker to the latest release of roundup, but we
might need to implement a critical security fix as soon as possible.
Using a vendor branch with a patch allows us to quickly push out a
fix.

You can argue that you can do ad hoc patches against a tarball, but
the vendor branch approach makes it easier for folks to work together
and track the changes being pushed out.

With a little bit of scripting the vendor branch approach should have
minimal difference to using the tarball releases, but should give us
the flexibility to do this kind of fix if we need to.

> Again, we don't modify roundup ourselves, so upgrading to a new roundup
> version will incure the same amount of work for us, no matter whether
> we have a copy in a vendor branch or not.
>

It's not impossible that we will need to modify roundup. Tracking it
in svn lets us feed back changes to core roundup development quite
easily.

At least, that's my take on this. I follow this approach for my work
roundup instance and I find it works quite well for me.

mick

From pfdubois at gmail.com  Wed Nov  1 19:00:01 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 1 Nov 2006 10:00:01 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548DE18.7020702@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
	<4548DE18.7020702@sympatico.ca>
Message-ID: <f74a6c2f0611011000g611159f5jbd8a370998766080@mail.gmail.com>

Roundup of course has two parts: the runtime and the template. Both get
modified when Richard improves Roundup. For example, there might be an error
on one of the classic template html pages or in a detector, or the runtime
supports some new feature to take advantage of.

Truth be told I have only once had to modify the runtime. However, like most
people I started with some instance of the classic template, and modified
it, and there are LOTS of times where new roundup releases have changes to
the classic template, often required to match the runtime. But unless you
use source code control, you don't know what they are.

If you started with the demo tracker you started with a slightly modified
version of 'classic'.
I'm suggesting that it is this classic template we need to start with so
that when new versions of it come out we're ok. I think in principle one
should track the release runtime too but it probably isn't necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/68b67f18/attachment.html 

From forsberg at efod.se  Wed Nov  1 19:09:33 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 19:09:33 +0100
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <17736.53036.4527.582333@montanaro.dyndns.org> (skip@pobox.com's
	message of "Wed, 1 Nov 2006 10:45:32 -0600")
References: <17736.50577.723941.859233@montanaro.dyndns.org>
	<4548CABE.3060801@sympatico.ca>
	<17736.52378.697954.775797@montanaro.dyndns.org>
	<17736.53036.4527.582333@montanaro.dyndns.org>
Message-ID: <87ac3bxcma.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

skip at pobox.com writes:

> At any rate, I put the idea out there not to expect a decision immediately
> or to distract the maintainers from more important tasks.  I just wanted to
> plant the seed so decisions you make now can be made with that in mind, and
> not inadvertently make it impossible to do downstream.

That's fine. 

I don't think we need to think that much about this at this time. Much
of the work ahead will be of the kind that will be useful for other
projects as well - the most obvious example being the tool for
converting from sf.net to roundup. 

But still, it's indeed good to have this possible future usage in mind. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSOLcrJurFAusidkRAigmAKDab6q/ltqMVbPTjk4Mw0STNpZePACcDLZq
Z9giezSLsmbwnBSFxZ18Xxs=
=uPFL
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Wed Nov  1 19:09:50 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 13:09:50 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <50a522ca0611010959u4b8a143cud187d5c097acefbf@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se>
	<45454854.2080402@sympatico.ca>	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	<200611011532.42802.forsberg@efod.se>	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>	<4548BAE8.1030109@sympatico.ca>	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>	<4548DE18.7020702@sympatico.ca>
	<50a522ca0611010959u4b8a143cud187d5c097acefbf@mail.gmail.com>
Message-ID: <4548E2EE.4010205@sympatico.ca>

Michael Twomey wrote:

> It's not impossible that we will need to modify roundup. Tracking it
> in svn lets us feed back changes to core roundup development quite
> easily.

OK then. I don't have a strong opinion, so if this doesn't incure too
much overhead for us it will just take up that little bit of extra
disk space.

I'm actually not that worried about roundup's own stability. It has
been in use for quite large communities, so this is not the first
'real-world' test.
Having roundup using a tracker there, too, may be a good incentive
for it to provide bugfix releases if we ask for them. :-)


Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Wed Nov  1 19:15:01 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 13:15:01 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611011000g611159f5jbd8a370998766080@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>	
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	
	<200611011532.42802.forsberg@efod.se>	
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>	
	<4548BAE8.1030109@sympatico.ca>	
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>	
	<4548DE18.7020702@sympatico.ca>
	<f74a6c2f0611011000g611159f5jbd8a370998766080@mail.gmail.com>
Message-ID: <4548E425.5000908@sympatico.ca>

Paul Dubois wrote:

> Truth be told I have only once had to modify the runtime. However, like
> most
> people I started with some instance of the classic template, and modified
> it, and there are LOTS of times where new roundup releases have changes to
> the classic template, often required to match the runtime. But unless you
> use source code control, you don't know what they are.

I don't think any changes to the runtime requires changes on the templates.
At least, that hasn't happened for a long time, as roundup grew more and
more stable. What happens, of course, is that the vanilla templates themselves
get more sophisticated over time.
However, as I expect us moving away from these default templates rather quickly,
I'm not sure merging in new features is the most efficient way to enhance our
templates.

> If you started with the demo tracker you started with a slightly modified
> version of 'classic'.
> I'm suggesting that it is this classic template we need to start with so
> that when new versions of it come out we're ok. I think in principle one
> should track the release runtime too but it probably isn't necessary.

I think we should start with the tracker instance we already have (which Erik
put together for the prototype, and to which I contributed some template
enhancements). There is no reason to start over again, in particular, as
criticism and enhancement requests were made based on that instance.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Wed Nov  1 19:21:35 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 1 Nov 2006 10:21:35 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548E425.5000908@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se>
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>
	<4548BAE8.1030109@sympatico.ca>
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>
	<4548DE18.7020702@sympatico.ca>
	<f74a6c2f0611011000g611159f5jbd8a370998766080@mail.gmail.com>
	<4548E425.5000908@sympatico.ca>
Message-ID: <f74a6c2f0611011021h320ace9q54285f8c5e9e07f0@mail.gmail.com>

I am *not* suggesting starting over. I am suggesting:

a. Check in the classic template from the roundup version you started with.
b. Branch it to 'ours'.
c. Check out all of ours, untar the prototype on top of it, and check it in.
d. Deploy the prototype.

When a new roundup is released, check the template portion in on top of (a)
and push changes to 'ours'. During resolution of these changes you can of
course decide you don't want them but at least you know what they are.

I don't think it has been a 'long time' since the classic template got
changed. I think it happens in almost every release.

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
>
> > Truth be told I have only once had to modify the runtime. However, like
> > most
> > people I started with some instance of the classic template, and
> modified
> > it, and there are LOTS of times where new roundup releases have changes
> to
> > the classic template, often required to match the runtime. But unless
> you
> > use source code control, you don't know what they are.
>
> I don't think any changes to the runtime requires changes on the
> templates.
> At least, that hasn't happened for a long time, as roundup grew more and
> more stable. What happens, of course, is that the vanilla templates
> themselves
> get more sophisticated over time.
> However, as I expect us moving away from these default templates rather
> quickly,
> I'm not sure merging in new features is the most efficient way to enhance
> our
> templates.
>
> > If you started with the demo tracker you started with a slightly
> modified
> > version of 'classic'.
> > I'm suggesting that it is this classic template we need to start with so
> > that when new versions of it come out we're ok. I think in principle one
> > should track the release runtime too but it probably isn't necessary.
>
> I think we should start with the tracker instance we already have (which
> Erik
> put together for the prototype, and to which I contributed some template
> enhancements). There is no reason to start over again, in particular, as
> criticism and enhancement requests were made based on that instance.
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/d8d6387f/attachment.htm 

From forsberg at efod.se  Wed Nov  1 19:32:03 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 19:32:03 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <1162162142.8245.12.camel@kwaaitjie> (=?iso-8859-1?Q?Roch=E9?=
	Compaan's message of "Mon, 30 Oct 2006 00:49:02 +0200")
References: <87odrv6k2y.fsf@uterus.efod.se>
	<1162162142.8245.12.camel@kwaaitjie>
Message-ID: <8764dzxbks.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roch? Compaan <roche at upfrontsystems.co.za> writes:

> Hi Erik, that's me :-)

Aha! :-)

[snip]

To me, it sounds like we've got everything we need on the
hardware/operating system side of things.

What's needed from the four of us to actually get access to the
machine? 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSOgirJurFAusidkRAoobAJ98W/LE6jF4Ub6G63drfdtTGukq0gCgpp6v
SkXVR7KktW+ErU5LlsOVdBg=
=STt7
-----END PGP SIGNATURE-----

From forsberg at efod.se  Wed Nov  1 19:45:27 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 19:45:27 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <20061101154034.GB8408@localhost.localdomain> (A. M. Kuchling's
	message of "Wed, 1 Nov 2006 10:40:34 -0500")
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
	<20061101154034.GB8408@localhost.localdomain>
Message-ID: <87wt6fvwe0.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"A.M. Kuchling" <amk at amk.ca> writes:

> On Wed, Nov 01, 2006 at 09:51:31AM -0500, Stefan Seefeld wrote:
>> Right. Brett, do we need accounts on python.org for this ?
>
> Not necessarily.  
>
> For Subversion on python.org, we have a setup that uses your SSH key
> to identify you; everyone uses the URL
> svn+ssh://python at svn.python.org/, but commit access doesn't imply you
> have shell access.  

Interesting setup. Is this documented somewhere? (just out of curiosity)

On a more on-topic matter, who can create a repository for us? (A.K.A,
who should I send the public part of my ssh key to?)

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSOtGrJurFAusidkRAt2uAJ0cX/oZ/E40eWh+77tFSqpGvD8sDgCcCBlj
isOvRGSvap/7hkXR5fdIF/8=
=W1wQ
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Wed Nov  1 19:50:08 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 13:50:08 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <f74a6c2f0611011021h320ace9q54285f8c5e9e07f0@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>	
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	
	<200611011532.42802.forsberg@efod.se>	
	<f74a6c2f0611010651g64d55783kc6c6b36f2fdfbcfb@mail.gmail.com>	
	<4548BAE8.1030109@sympatico.ca>	
	<f74a6c2f0611010801t2a7706a7l82b255dcf2620704@mail.gmail.com>	
	<4548DE18.7020702@sympatico.ca>	
	<f74a6c2f0611011000g611159f5jbd8a370998766080@mail.gmail.com>	
	<4548E425.5000908@sympatico.ca>
	<f74a6c2f0611011021h320ace9q54285f8c5e9e07f0@mail.gmail.com>
Message-ID: <4548EC60.2010401@sympatico.ca>

Paul Dubois wrote:
> I am *not* suggesting starting over. I am suggesting:
> 
> a. Check in the classic template from the roundup version you started with.
> b. Branch it to 'ours'.
> c. Check out all of ours, untar the prototype on top of it, and check it
> in.
> d. Deploy the prototype.
> 
> When a new roundup is released, check the template portion in on top of (a)
> and push changes to 'ours'. During resolution of these changes you can of
> course decide you don't want them but at least you know what they are.

OK, fine.

> I don't think it has been a 'long time' since the classic template got
> changed. I think it happens in almost every release.

True. I was talking about changes that were required to adjust to a backward
incompatible change in the runtime. Sorry if that wasn't clear.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Wed Nov  1 19:57:51 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 1 Nov 2006 10:57:51 -0800
Subject: [Tracker-discuss] Trackers for other Python-based projects
In-Reply-To: <17736.53036.4527.582333@montanaro.dyndns.org>
References: <17736.50577.723941.859233@montanaro.dyndns.org>
	<4548CABE.3060801@sympatico.ca>
	<17736.52378.697954.775797@montanaro.dyndns.org>
	<17736.53036.4527.582333@montanaro.dyndns.org>
Message-ID: <bbaeab100611011057r747da483u20d856d7eacd1b44@mail.gmail.com>

On 11/1/06, skip at pobox.com <skip at pobox.com> wrote:
>
>
>     Stefan> well as separate trackers for other python implementations
>     Stefan> (ipython, jython, etc.).
>
> After hitting the 's'end button I realized that ipython isn't a separate
> implementation of Python.  It is just an application which happens to be
> written in Python and tightly integrates with it.
>
> At any rate, I put the idea out there not to expect a decision immediately
> or to distract the maintainers from more important tasks.  I just wanted
> to
> plant the seed so decisions you make now can be made with that in mind,
> and
> not inadvertently make it impossible to do downstream.


It's definitely on my mind, Skip.  The Jython team has already approached me
about the possibility of having us set up a tracker for them (especially
since we already house their svn repository).

Your requirement that a group volunteer someone is definitely good.  The
only worry with that is whether that person will stay on.  One of the
reasons I mandated so many people for the python-dev tracker is just in case
anyone walks off the job early.  Now granted everyone I picked I either know
personally or have already shown their level of dedication so I am not
worried.  But the same cannot be said about other projects.

As for accepting more projects, if the guys say "sure", then I am all for
it.  We will most likely put in place some scheme for limiting what projects
we pick up (we do not need to become the SF of the Python world).  But I am
sure something like annual voting at the PSF members meeting or having the
PSF Infrastructure committee decide should be enough of a filter to keep
things under control.

Anyway, as you said, this is all step 62 whlie we are on 1.  =)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/2764328d/attachment.html 

From brett at python.org  Wed Nov  1 20:05:01 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 1 Nov 2006 11:05:01 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548B473.8020605@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
Message-ID: <bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Erik Forsberg wrote:
> > onsdag 01 november 2006 15:10 skrev Michael Twomey:
> >> Hi,
> >>
> >> It seems we still have two outstanding points we haven't agreed upon:
> >>
> >> * Where to keep the source (I favour a plain subversion + python.orgsetup)
> >
> > I agree. Using existing subversion infrastructure is a good thing. That
> way,
> > we don't have to worry about backups and stuff.
>
> Right. Brett, do we need accounts on python.org for this ?


Yep.  It just requires SSH 2 keys from each of you.  You can then email
python-dev with those keys and your first.last name and someone there will
install the keys for you.

>> * What meta tracker to use (I agree with a plain roundup setup on the
> box)
> >
> > Me too. I think there's some confusion on what we mean here - the idea
> is
> > _not_  to use the same tracker, but another independent tracker instance
> > running on the same box.
>
> I agree.


> If the box hosting both trackers is down, it's better to tell the people
> > hosting it than to add a bug to the meta tracker.
>
> Indeed. It is my understanding that the state of the machine will be
> monitored
> anyways, so we only have to worry about the state of the trackers. :-)


=)  Good point.

Roch?, please let us know how we can help setting such a meta-tracker up,
> or what else you need from us to get started. Thanks !
>
> > Until we get a meta tracker online, we can however still use the one on
> > http://efod.se/ptt/.
> >
> >> Oh, and hi, I'm Michael :)
> >
> > Nice to meet you! :-)
>
> Likewise !


Sorry guys for not doing better introductions.  =)

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/fd625c4d/attachment.htm 

From roche at upfrontsystems.co.za  Wed Nov  1 20:05:36 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Wed, 01 Nov 2006 20:05:36 +0100
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548B473.8020605@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
Message-ID: <1162407936.7576.6.camel@kwaaitjie>

On Wed, 2006-11-01 at 09:51 -0500, Stefan Seefeld wrote:
> Erik Forsberg wrote:
> > onsdag 01 november 2006 15:10 skrev Michael Twomey:
> >> Hi,
> >>
> >> It seems we still have two outstanding points we haven't agreed upon:
> >>
> >> * Where to keep the source (I favour a plain subversion + python.org setup)
> > 
> > I agree. Using existing subversion infrastructure is a good thing. That way, 
> > we don't have to worry about backups and stuff. 
> 
> Right. Brett, do we need accounts on python.org for this ?
> 
> >> * What meta tracker to use (I agree with a plain roundup setup on the box)
> > 
> > Me too. I think there's some confusion on what we mean here - the idea is 
> > _not_  to use the same tracker, but another independent tracker instance 
> > running on the same box. 
> 
> I agree.
> 
> > If the box hosting both trackers is down, it's better to tell the people 
> > hosting it than to add a bug to the meta tracker.
> 
> Indeed. It is my understanding that the state of the machine will be monitored
> anyways, so we only have to worry about the state of the trackers. :-)
> 
> Roch?, please let us know how we can help setting such a meta-tracker up,
> or what else you need from us to get started. Thanks !

I have ordered another server from Hetzner last week and am awaiting details
from them. Once this server is up and running we can get going with the
Roundup installation and setting up of trackers.

I am travelling at the moment after attending the Plone Conference in
Seattle last week. I will be back in South Africa next week so I might
not be as responsive as you would like me to be. I do check mail every
second day and will let you know as soon as Hetzner gives me the access
details for the server.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Wed Nov  1 20:14:05 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 01 Nov 2006 14:14:05 -0500
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>	
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>	
	<200611011532.42802.forsberg@efod.se>
	<4548B473.8020605@sympatico.ca>
	<bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>
Message-ID: <4548F1FD.5010505@sympatico.ca>

Brett Cannon wrote:
> On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:

>> Right. Brett, do we need accounts on python.org for this ?
> 
> 
> Yep.  It just requires SSH 2 keys from each of you.  You can then email
> python-dev with those keys and your first.last name and someone there will
> install the keys for you.

My key is at http://www3.sympatico.ca/seefeld/ssh.txt, I'm Stefan Seefeld.

Thanks !

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Wed Nov  1 20:14:29 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 1 Nov 2006 11:14:29 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <87wt6fvwe0.fsf@uterus.efod.se>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
	<20061101154034.GB8408@localhost.localdomain>
	<87wt6fvwe0.fsf@uterus.efod.se>
Message-ID: <bbaeab100611011114j7993de9q17b68cb5d7490938@mail.gmail.com>

On 11/1/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> "A.M. Kuchling" <amk at amk.ca> writes:
>
> > On Wed, Nov 01, 2006 at 09:51:31AM -0500, Stefan Seefeld wrote:
> >> Right. Brett, do we need accounts on python.org for this ?
> >
> > Not necessarily.
> >
> > For Subversion on python.org, we have a setup that uses your SSH key
> > to identify you; everyone uses the URL
> > svn+ssh://python at svn.python.org/, but commit access doesn't imply you
> > have shell access.
>
> Interesting setup. Is this documented somewhere? (just out of curiosity)


Not that I know of.  Martin v. L?wis set it up.

On a more on-topic matter, who can create a repository for us? (A.K.A,
> who should I send the public part of my ssh key to?)


Send it to python-dev with your first and last name (gets turned into your
account name) and state why you need access.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/b0be872f/attachment.html 

From brett at python.org  Wed Nov  1 20:17:56 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 1 Nov 2006 11:17:56 -0800
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <4548F1FD.5010505@sympatico.ca>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
	<bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>
	<4548F1FD.5010505@sympatico.ca>
Message-ID: <bbaeab100611011117j3b898bd7ocd01bfa12c7f7846@mail.gmail.com>

On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Brett Cannon wrote:
> > On 11/1/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> >> Right. Brett, do we need accounts on python.org for this ?
> >
> >
> > Yep.  It just requires SSH 2 keys from each of you.  You can then email
> > python-dev with those keys and your first.last name and someone there
> will
> > install the keys for you.
>
> My key is at http://www3.sympatico.ca/seefeld/ssh.txt, I'm Stefan Seefeld.
>
> Thanks !


Just to clarify, this is not for pydotorg but the svn.python.org.  The
admins for our future Roundup instance are going to keep their Roundup code
in svn so they need commit access.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/e2947c52/attachment.htm 

From forsberg at efod.se  Wed Nov  1 20:48:43 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 01 Nov 2006 20:48:43 +0100
Subject: [Tracker-discuss] [Brett Cannon] Re:  Getting Started
Message-ID: <87ac3bvtgk.fsf@uterus.efod.se>

An embedded message was scrubbed...
From: "Brett Cannon" <brett at python.org>
Subject: Re: [Tracker-discuss] Getting Started
Date: Wed, 1 Nov 2006 11:36:56 -0800
Size: 6395
Url: http://mail.python.org/pipermail/tracker-discuss/attachments/20061101/11bc8eec/attachment.mht 

From micktwomey at gmail.com  Thu Nov  2 12:09:05 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Thu, 2 Nov 2006 11:09:05 +0000
Subject: [Tracker-discuss] Getting Started
In-Reply-To: <bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>
References: <87odrv6k2y.fsf@uterus.efod.se> <45454854.2080402@sympatico.ca>
	<50a522ca0611010610uf598b0elc3142b9af9de5a43@mail.gmail.com>
	<200611011532.42802.forsberg@efod.se> <4548B473.8020605@sympatico.ca>
	<bbaeab100611011105o5cf20956vcbd19fd48a2ec68b@mail.gmail.com>
Message-ID: <50a522ca0611020309i5be21d99t8c39bbeb323289ed@mail.gmail.com>

On 11/1/06, Brett Cannon <brett at python.org> wrote:
> >
> > Right. Brett, do we need accounts on python.org for this ?
>
> Yep.  It just requires SSH 2 keys from each of you.  You can then email
> python-dev with those keys and your first.last name and someone there will
> install the keys for you.
>

I'll need svn access to svn.python.org too for the roundup tracker.

My key is over at http://translucentcode.org/mick/ssh_key.txt
firstname.lastname: michael.twomey

cheers,
  Michael

From martin at v.loewis.de  Fri Nov  3 10:01:42 2006
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 03 Nov 2006 10:01:42 +0100
Subject: [Tracker-discuss] SSH keys added
Message-ID: <454B0576.3040009@v.loewis.de>

I just added the keys for Stefan Seefeld and Michael Twomey
for access to the projects repository; you can access it
through svn+ssh://pythondev at svn.python.org/

Feel free to create a new folder in the root directory;
please don't stamp on anything else in the repository.

ViewCVS access is at

http://svn.python.org/view

and anonymous read access at

http://svn.python.org/projects

If I missed adding any key that had been posted, please
remind me.

Regards,
Martin

From forsberg at efod.se  Fri Nov  3 10:09:43 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Fri, 03 Nov 2006 10:09:43 +0100
Subject: [Tracker-discuss] SSH keys added
In-Reply-To: <454B0576.3040009@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Fri, 03 Nov 2006 10:01:42 +0100")
References: <454B0576.3040009@v.loewis.de>
Message-ID: <87u01gdhgo.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> If I missed adding any key that had been posted, please
> remind me.

I posted one as well, but since I'm not a member of python-dev, I
guess it got lost in the moderation process.

Anyway, my mail was quoted by Brett Cannon in a mail to python-dev, so here it is:

http://article.gmane.org/gmane.comp.python.devel/84716

Regards,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFSwdXrJurFAusidkRAkZrAJ0WFhz7Lw4VQTj8bOvhJ/0Z2K1lfwCcDUIO
xPeuTbOa6VW2cnzyhKCJdKc=
=eG+G
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Fri Nov  3 10:11:27 2006
From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 03 Nov 2006 10:11:27 +0100
Subject: [Tracker-discuss] Subversion setup (was: Getting Started)
Message-ID: <454B07BF.5060403@v.loewis.de>

> Interesting setup. Is this documented somewhere? (just out of
> curiosity)

Part of it is documented in PEP 347:

http://www.python.org/dev/peps/pep-0347/

Notice in particular the "Collecting SSH keys" section;
all you need is the authorized_keys file.

So not only do we not need to provide shell access; we also
have a single Unix user (pythondev) who has access to the
actual repository data. If somebody would manage to break
into this account, they would be restricted to the rights
of the pythondev user (who can't do much more than accessign
the subversion files).

Now (and that part isn't documented) managing the authorized_keys
file is tedious in itself, so I came up to use a (different)
subversion repository for it, whose content currently looks like that:

alex.martelli
andrew.dalke
andrew.kuchling
andrew.macintyre
andrew.mcnamara
anthony.baxter
armin.rigo
barry.warsaw
...

Each file contains the ssh keys of each user, and there is a Python
script to combine them into an authorized_keys file. This Python
script is run on post-commit to this subversion repository.

In this setup, everybody currently has write access to the entire
subversion repository. If access control would ever be necessary,
we could manage an access control file the same way.

> On a more on-topic matter, who can create a repository for us?
> (A.K.A, who should I send the public part of my ssh key to?)

You can send it to me.

Regards,
Martin

From seefeld at sympatico.ca  Fri Nov  3 15:37:27 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 03 Nov 2006 09:37:27 -0500
Subject: [Tracker-discuss] SSH keys added
In-Reply-To: <454B0576.3040009@v.loewis.de>
References: <454B0576.3040009@v.loewis.de>
Message-ID: <454B5427.2060902@sympatico.ca>

Martin v. L?wis wrote:
> I just added the keys for Stefan Seefeld and Michael Twomey
> for access to the projects repository; you can access it
> through svn+ssh://pythondev at svn.python.org/

Thanks. I can confirm that I now have (well, at least read)
access to the repository.

Erik, may I suggest that -- once you have access, too --
you create a top-level 'tracker/' directory, and then import the
current python tracker into 'tracker/trunk/' ?

In parallel we may put the 'classic' tracker from the current
roundup version into tracker/vendor/roundup-classic-<version>/ (or whichever
it was), so that we can track changes there, too.

Once the meta-tracker gets set up we can continue issue-specific
discussions there.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Fri Nov  3 21:42:55 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Fri, 03 Nov 2006 21:42:55 +0100
Subject: [Tracker-discuss] SSH keys added
In-Reply-To: <454B5427.2060902@sympatico.ca> (Stefan Seefeld's message of
	"Fri, 03 Nov 2006 09:37:27 -0500")
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
Message-ID: <871wokw9bk.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Martin v. L?wis wrote:
>> I just added the keys for Stefan Seefeld and Michael Twomey
>> for access to the projects repository; you can access it
>> through svn+ssh://pythondev at svn.python.org/
>
> Thanks. I can confirm that I now have (well, at least read)
> access to the repository.
>
> Erik, may I suggest that -- once you have access, too --
> you create a top-level 'tracker/' directory, and then import the
> current python tracker into 'tracker/trunk/' ?

Sure. You read my mind :-).

> In parallel we may put the 'classic' tracker from the current
> roundup version into tracker/vendor/roundup-classic-<version>/ (or whichever
> it was), so that we can track changes there, too.

I can do that too. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFS6nPrJurFAusidkRAv1bAJ4hWeuYkkycx62rpZ4RXtUJU7WvBQCeIy84
5W5vG8IKC9AQt4+Hglb/WUo=
=ekAa
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sat Nov  4 08:38:31 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 04 Nov 2006 08:38:31 +0100
Subject: [Tracker-discuss] SSH keys added
In-Reply-To: <87u01gdhgo.fsf@uterus.efod.se>
References: <454B0576.3040009@v.loewis.de> <87u01gdhgo.fsf@uterus.efod.se>
Message-ID: <454C4377.2050708@v.loewis.de>

Erik Forsberg schrieb:
> Anyway, my mail was quoted by Brett Cannon in a mail to python-dev, so here it is:
> 
> http://article.gmane.org/gmane.comp.python.devel/84716

Thanks, I just added it.

Regards,
Martin

From forsberg at efod.se  Sat Nov  4 08:53:26 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 04 Nov 2006 08:53:26 +0100
Subject: [Tracker-discuss] SSH keys added
In-Reply-To: <454C4377.2050708@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sat, 04 Nov 2006 08:38:31 +0100")
References: <454B0576.3040009@v.loewis.de> <87u01gdhgo.fsf@uterus.efod.se>
	<454C4377.2050708@v.loewis.de>
Message-ID: <87psc3vea1.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Erik Forsberg schrieb:
>> Anyway, my mail was quoted by Brett Cannon in a mail to python-dev, so here it is:
>> 
>> http://article.gmane.org/gmane.comp.python.devel/84716
>
> Thanks, I just added it.

Thankyou, seems to work.

One interesting thing is that my svn client (1.3.1) seems confused by
the subversion url used for the python repository in some cases:

svn ls svn+ssh://pythondev at svn.python.org
svn: Syntax error parsing revision 'svn.python.org'

'svn ls svn+ssh://pythondev at svn.python.org/python' works as intended, though. 

I solved the problem by adding a section to my ~/.ssh/config, stating
the default username for svn.python.org.

Ah well.. 

I'll start adding stuff this evening or sometime tomorrow.

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFTEb2rJurFAusidkRAlozAJ94TiptF3IBNA/3Yk8zS1praR2CKQCdEvIv
6qUIerMIF9HfDiSL5jW2GnA=
=WARF
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sun Nov  5 21:57:46 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 05 Nov 2006 21:57:46 +0100
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <871wokw9bk.fsf@uterus.efod.se> (Erik Forsberg's message of "Fri, 
	03 Nov 2006 21:42:55 +0100")
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se>
Message-ID: <87lkmpvcfp.fsf_-_@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Forsberg <forsberg at efod.se> writes:

>> Erik, may I suggest that -- once you have access, too --
>> you create a top-level 'tracker/' directory, and then import the
>> current python tracker into 'tracker/trunk/' ?
>
> Sure. You read my mind :-).
>
>> In parallel we may put the 'classic' tracker from the current
>> roundup version into tracker/vendor/roundup-classic-<version>/ (or whichever
>> it was), so that we can track changes there, too.
>
> I can do that too. 

svn+ssh://pythondev at svn.python.org/tracker directory created and
populated with a vendor import of roundup 1.1.2 (which was the version
the python-tracker instance was created with). 

A svn copy of /tracker/vendor/roundup/1.1.2 was then made to
/tracker/instances/python-dev. 

Changes made on the schema, initial_data and html templates was then
applied to to /tracker/instances/python-dev, and commited.

Tomorrow I'll continue by adding the conversion scripts, and make a
vendor drop of roundup 1.2.1 and bring in any relevant changes to
tracker/instances/python-dev.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFTlBKrJurFAusidkRAtm7AKDZBkIwLOq3DWHg4zwsLH7X7wBruQCgmp2Q
sKya1kTLu5E3SucSWqyuTyY=
=oGxc
-----END PGP SIGNATURE-----

From forsberg at efod.se  Tue Nov  7 17:51:28 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 07 Nov 2006 17:51:28 +0100
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <87lkmpvcfp.fsf_-_@uterus.efod.se> (Erik Forsberg's message of
	"Sun, 05 Nov 2006 21:57:46 +0100")
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>
Message-ID: <878xinyzcf.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Forsberg <forsberg at efod.se> writes:

> Tomorrow I'll continue by adding the conversion scripts, and make a
> vendor drop of roundup 1.2.1 and bring in any relevant changes to
> tracker/instances/python-dev.

This is what I've done so far:

1) A Vendor drop of roundup 1.1.2 was imported to
   /tracker/vendor/roundup/current 

2) The vendor drop was then copied (A.K.A tagged) to
   /tracker/vendor/roundup/1.1.2 

4) /tracker/vendor/roundup/current/templates/classic was copied to
   /tracker/instances/python-dev as a base for our templates.

5) The instance from the python-tracker module in the roundup CVS
   repo. at sourceforge was then copied on top of
   /tracker/instances/python-dev. This was then commited.

   This gave us a /tracker/instances/python-dev which is based on
   1.1.2 then modified. That means we can se what changes we made
   compared to the base templates.

6) A vendor drop of the current roundup was added to
   /tracker/vendor/roundup/current. It was then tagged as
   /tracker/vendor/roundup/1.2.1. 

7) svn merge \
   svn+ssh://svn.python.org/tracker/vendor/roundup/1.1.2/templates/classic\
   svn+ssh://svn.python.org/tracker/vendor/roundup/current \
   <working copy of /tracker/instances/python-dev>

   ..was run. This applies changes between 1.1.2 and 1.2.1 to our
   tracker instance. 

8) Conflicts in the python-dev tracker instance were resolved.

9) /tracker/instances/python-dev were commited after some testing to
   see that it works well with roundup 1.2.1.

10) Added importer sources to /tracker/importer.


Summarizing the structure in SVN:

instances       A directory for tracker instances. Currently with one
                subdirectory - python-dev. If we start maintaining
                multiple instances, this is where to add them.

vendor          Vendor branch of roundup, and possibly other.

importer        The importer. 

Now working on getting the importer to work again. It's been a while
since I ran it, and there's been a new release of the sourceforge
tools from effbot due to changes on the sourceforge web site.


Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFULmPrJurFAusidkRAvzaAKDIdAIRsNiz17uMaU38XPStLWFFgwCg0FDd
6jicszSVKwN8om+f2/D825s=
=msmh
-----END PGP SIGNATURE-----

From barry at python.org  Tue Nov  7 18:02:27 2006
From: barry at python.org (Barry Warsaw)
Date: Tue, 7 Nov 2006 12:02:27 -0500
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <878xinyzcf.fsf@uterus.efod.se>
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>
	<878xinyzcf.fsf@uterus.efod.se>
Message-ID: <203380F8-AF45-49F7-963E-A03DB1071834@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 7, 2006, at 11:51 AM, Erik Forsberg wrote:

> Now working on getting the importer to work again. It's been a while
> since I ran it, and there's been a new release of the sourceforge
> tools from effbot due to changes on the sourceforge web site.

Let me know how that goes.  I've been using r428 of /F's stuff and  
ran into several problems getting a clean export of the Mailman  
trackers.  I contacted Fredrik about that but I think he and I have  
both been too busy.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRVC8KHEjvBPtnXfVAQK8owP+IHEpTRN2Dth8eIIYT0HIpFNre3V+S7Yl
0F48z8zuv4gH8P9KAw6exqcxEwsfzeq6G8jwHrXNhU9MJ0NOO3reSb/XCG00OF8Y
Si9Y6Sy3R0g7SOrMYScdbylZQFqRlIPr8K/cDiWp83agGNXqkB+gCRRC2l6mSctn
yA/GkS4J37k=
=cUjN
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Tue Nov  7 18:11:12 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 07 Nov 2006 12:11:12 -0500
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <878xinyzcf.fsf@uterus.efod.se>
References: <454B0576.3040009@v.loewis.de>
	<454B5427.2060902@sympatico.ca>	<871wokw9bk.fsf@uterus.efod.se>
	<87lkmpvcfp.fsf_-_@uterus.efod.se> <878xinyzcf.fsf@uterus.efod.se>
Message-ID: <4550BE30.1040107@sympatico.ca>

Erik Forsberg wrote:
> Erik Forsberg <forsberg at efod.se> writes:
> 
>>> Tomorrow I'll continue by adding the conversion scripts, and make a
>>> vendor drop of roundup 1.2.1 and bring in any relevant changes to
>>> tracker/instances/python-dev.
> 
> This is what I've done so far:
> 
> 1) A Vendor drop of roundup 1.1.2 was imported to
>    /tracker/vendor/roundup/current 
> 
> 2) The vendor drop was then copied (A.K.A tagged) to
>    /tracker/vendor/roundup/1.1.2 
> 
> 4) /tracker/vendor/roundup/current/templates/classic was copied to
>    /tracker/instances/python-dev as a base for our templates.
> 
> 5) The instance from the python-tracker module in the roundup CVS
>    repo. at sourceforge was then copied on top of
>    /tracker/instances/python-dev. This was then commited.
> 
>    This gave us a /tracker/instances/python-dev which is based on
>    1.1.2 then modified. That means we can se what changes we made
>    compared to the base templates.
> 
> 6) A vendor drop of the current roundup was added to
>    /tracker/vendor/roundup/current. It was then tagged as
>    /tracker/vendor/roundup/1.2.1. 
> 
> 7) svn merge \
>    svn+ssh://svn.python.org/tracker/vendor/roundup/1.1.2/templates/classic\
>    svn+ssh://svn.python.org/tracker/vendor/roundup/current \
>    <working copy of /tracker/instances/python-dev>
> 
>    ..was run. This applies changes between 1.1.2 and 1.2.1 to our
>    tracker instance. 
> 
> 8) Conflicts in the python-dev tracker instance were resolved.
> 
> 9) /tracker/instances/python-dev were commited after some testing to
>    see that it works well with roundup 1.2.1.
> 
> 10) Added importer sources to /tracker/importer.

Awesome !

> Summarizing the structure in SVN:
> 
> instances       A directory for tracker instances. Currently with one
>                 subdirectory - python-dev. If we start maintaining
>                 multiple instances, this is where to add them.
> 
> vendor          Vendor branch of roundup, and possibly other.
> 
> importer        The importer. 
> 
> Now working on getting the importer to work again. It's been a while
> since I ran it, and there's been a new release of the sourceforge
> tools from effbot due to changes on the sourceforge web site.

Great. I'm now looking forward to get access to the meta-tracker so
we can start talking about adjustments.

Also: I think it would be convenient to hardcode a number of users
into the dbinit.py script (with differing roles), so we have a quick
and reproducible way to set up a local clone of the tracker for testing.

Martin: did anything change in the authentication setup ? A couple of
days ago I could browse the repository, but right now it appears
svn.python.org doesn't accept my key any more.

I get:

[stefan at quasimodo projects]$ svn ls svn+ssh://svn.python.org/tracker
Permission denied (publickey,keyboard-interactive).
svn: Connection closed unexpectedly

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From micktwomey at gmail.com  Tue Nov  7 18:24:44 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Tue, 7 Nov 2006 17:24:44 +0000
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <4550BE30.1040107@sympatico.ca>
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>
	<878xinyzcf.fsf@uterus.efod.se> <4550BE30.1040107@sympatico.ca>
Message-ID: <50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>

On 11/7/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Awesome !
>

I agree, I've got the code checked out, I just need to setup my own
instance to play with.

> I get:
>
> [stefan at quasimodo projects]$ svn ls svn+ssh://svn.python.org/tracker
> Permission denied (publickey,keyboard-interactive).
> svn: Connection closed unexpectedly
>

I think you are missing the pythondev username, i.e.
svn+ssh://pythondev at svn.python.org

cheers,
  mick

From martin at v.loewis.de  Tue Nov  7 18:53:07 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 07 Nov 2006 18:53:07 +0100
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <4550BE30.1040107@sympatico.ca>
References: <454B0576.3040009@v.loewis.de>	<454B5427.2060902@sympatico.ca>	<871wokw9bk.fsf@uterus.efod.se>	<87lkmpvcfp.fsf_-_@uterus.efod.se>
	<878xinyzcf.fsf@uterus.efod.se> <4550BE30.1040107@sympatico.ca>
Message-ID: <4550C803.8040402@v.loewis.de>

Stefan Seefeld schrieb:
> Martin: did anything change in the authentication setup ? A couple of
> days ago I could browse the repository, but right now it appears
> svn.python.org doesn't accept my key any more.

No; you can see the list of authorized committers here:

http://www.python.org/dev/committers

(there is no way to verifying your keys anonymously - you'd have to
 ask).

> I get:
> 
> [stefan at quasimodo projects]$ svn ls svn+ssh://svn.python.org/tracker
> Permission denied (publickey,keyboard-interactive).
> svn: Connection closed unexpectedly

Ah, please add pythondev@ into the URL. As an intermediate step, do

martin at mira:~$ ssh pythondev at svn.python.org
( success ( 1 2 ( ANONYMOUS EXTERNAL ) ( edit-pipeline ) ) )
Ctrl-C

Regards,
Martin

From seefeld at sympatico.ca  Tue Nov  7 18:52:35 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 07 Nov 2006 12:52:35 -0500
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>	
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>	
	<878xinyzcf.fsf@uterus.efod.se> <4550BE30.1040107@sympatico.ca>
	<50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>
Message-ID: <4550C7E3.2080402@sympatico.ca>

Michael Twomey wrote:
> On 11/7/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:

>> I get:
>>
>> [stefan at quasimodo projects]$ svn ls svn+ssh://svn.python.org/tracker
>> Permission denied (publickey,keyboard-interactive).
>> svn: Connection closed unexpectedly
>>
> 
> I think you are missing the pythondev username, i.e.
> svn+ssh://pythondev at svn.python.org

Duh ! :-)

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Tue Nov  7 19:34:54 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Tue, 7 Nov 2006 10:34:54 -0800
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <4550C7E3.2080402@sympatico.ca>
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>
	<878xinyzcf.fsf@uterus.efod.se> <4550BE30.1040107@sympatico.ca>
	<50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>
	<4550C7E3.2080402@sympatico.ca>
Message-ID: <f74a6c2f0611071034i729f82b9vb1e897cd0b696712@mail.gmail.com>

tracker-discuss seems to be set for a default of reply to author instead of
reply to group.

Martin gave me some help and I should get my key to him tomorrow; I have
been a little tied up. Thanks for the work done so far.

I should explain that I'm semi-retired and as of June I'm going to be
completely retired so I'm setting up to help from home/Windows rather than
the usual work/Linux and there are some things I'm just not used to doing
that way, such as ssh -- we have those one-time password devices where I
work. So the good news is I will have plenty of time, but the bad news is I
know what I'm doing even less than usual.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061107/8f46be68/attachment.htm 

From seefeld at sympatico.ca  Tue Nov  7 19:58:57 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 07 Nov 2006 13:58:57 -0500
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <f74a6c2f0611071034i729f82b9vb1e897cd0b696712@mail.gmail.com>
References: <454B0576.3040009@v.loewis.de>
	<454B5427.2060902@sympatico.ca>	<871wokw9bk.fsf@uterus.efod.se>
	<87lkmpvcfp.fsf_-_@uterus.efod.se>	<878xinyzcf.fsf@uterus.efod.se>
	<4550BE30.1040107@sympatico.ca>	<50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>	<4550C7E3.2080402@sympatico.ca>
	<f74a6c2f0611071034i729f82b9vb1e897cd0b696712@mail.gmail.com>
Message-ID: <4550D771.4000904@sympatico.ca>

Paul Dubois wrote:

> I should explain that I'm semi-retired and as of June I'm going to be
> completely retired so I'm setting up to help from home/Windows rather than
> the usual work/Linux and there are some things I'm just not used to doing
> that way, such as ssh -- we have those one-time password devices where I
> work. So the good news is I will have plenty of time, but the bad news is I
> know what I'm doing even less than usual.

On windows machines I typically set up at least a minimal cygwin installation,
with ssh, svn, python, etc.
In such an environment you shouldn't see any difference as far as roundup
is concerned. (In fact I'm convinced you can install all these tools for
windows, native, too, I just prefer the command line.)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Tue Nov  7 20:29:16 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 07 Nov 2006 20:29:16 +0100
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <4550D771.4000904@sympatico.ca>
References: <454B0576.3040009@v.loewis.de>	<454B5427.2060902@sympatico.ca>	<871wokw9bk.fsf@uterus.efod.se>	<87lkmpvcfp.fsf_-_@uterus.efod.se>	<878xinyzcf.fsf@uterus.efod.se>	<4550BE30.1040107@sympatico.ca>	<50a522ca0611070924w741dfbefta892ee45bb562b9a@mail.gmail.com>	<4550C7E3.2080402@sympatico.ca>	<f74a6c2f0611071034i729f82b9vb1e897cd0b696712@mail.gmail.com>
	<4550D771.4000904@sympatico.ca>
Message-ID: <4550DE8C.2020904@v.loewis.de>

Stefan Seefeld schrieb:
>> I should explain that I'm semi-retired and as of June I'm going to be
>> completely retired so I'm setting up to help from home/Windows rather than
>> the usual work/Linux and there are some things I'm just not used to doing
>> that way, such as ssh -- we have those one-time password devices where I
>> work. So the good news is I will have plenty of time, but the bad news is I
>> know what I'm doing even less than usual.
> 
> On windows machines I typically set up at least a minimal cygwin installation,
> with ssh, svn, python, etc.
> In such an environment you shouldn't see any difference as far as roundup
> is concerned. (In fact I'm convinced you can install all these tools for
> windows, native, too, I just prefer the command line.)

I suggested Paul to use Putty; that works just fine as well (and also
integrates easily with Tortoise).

Regards,
Martin

From forsberg at efod.se  Tue Nov  7 20:51:17 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 07 Nov 2006 20:51:17 +0100
Subject: [Tracker-discuss] Import work begun.
In-Reply-To: <203380F8-AF45-49F7-963E-A03DB1071834@python.org> (Barry Warsaw's
	message of "Tue, 7 Nov 2006 12:02:27 -0500")
References: <454B0576.3040009@v.loewis.de> <454B5427.2060902@sympatico.ca>
	<871wokw9bk.fsf@uterus.efod.se> <87lkmpvcfp.fsf_-_@uterus.efod.se>
	<878xinyzcf.fsf@uterus.efod.se>
	<203380F8-AF45-49F7-963E-A03DB1071834@python.org>
Message-ID: <87mz73xcga.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Barry Warsaw <barry at python.org> writes:

> On Nov 7, 2006, at 11:51 AM, Erik Forsberg wrote:
>
>> Now working on getting the importer to work again. It's been a while
>> since I ran it, and there's been a new release of the sourceforge
>> tools from effbot due to changes on the sourceforge web site.
>
> Let me know how that goes.  I've been using r428 of /F's stuff and
> ran into several problems getting a clean export of the Mailman
> trackers.  I contacted Fredrik about that but I think he and I have
> both been too busy.

Well, it didn't work for me either - failed to find the description as
well as the comments. Here's a patch to fix that:

- --snip--
Index: extract.py
===================================================================
- --- extract.py	(revision 428)
+++ extract.py	(working copy)
@@ -95,13 +95,13 @@
     table = elem.find("table")
 
     # locate the description
- -    for tr in table:
+    for tr in table[1:]:
         if len(tr) == 1 and tr[0].get("colspan") == "2":
             # map <br> to newlines
             for br in tr.findall(".//br"):
                 br.text = chr(0) # temporarily use NULL as line terminator
- -                if br.tail and br.tail.startswith("\n"):
- -                    br.tail = br.tail[1:] # trip extra newlines
+                if br.tail and br.tail.startswith("\r\n"):
+                    br.tail = br.tail[2:] # trip extra newlines
             text = gettext(tr)
             if text.startswith("\n\n\t\t\t"):
                 text = text[5:]
@@ -128,7 +128,7 @@
         elif td and td[0].tag == "h3":
             key = gettext(td[0]).strip()
             if key == "Followups:":
- -                for i, e in enumerate(td.findall("table/tr/td")):
+                for i, e in enumerate(td.findall("p/table/tr/td")):
                     if i:
                         data = getcomment(e)
                         result.setdefault("comments", []).append(data)
- --snap--

I'm not sure this solves all possible scraping trouble, but at least
it's a start.

Cc to Fredrik to let him update his repo. And please spell my surname
correctly in the commit message this time ;-).

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFUOO1rJurFAusidkRAqhxAKCRHDFxLnj2a6rncWjHpkG3nsIbNQCgiCRF
EIiB5y3i8iWebF9WomI9KAA=
=GguG
-----END PGP SIGNATURE-----

From roche at upfrontsystems.co.za  Wed Nov  8 13:42:57 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Wed, 08 Nov 2006 14:42:57 +0200
Subject: [Tracker-discuss] Progress with server
Message-ID: <1162989777.23819.17.camel@localhost.localdomain>

Hi there

I'm finally back at the office today. The server that we ordered from
Hetzner was available from last Thursday. Our sysadmin is currently
finalising the install on the server and it should be ready by tomorrow.

Can you please let me know which users should have access to the box and
where I can get their SSH keys.

-- 
Roch? Compaan
Upfront Systems                 http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Wed Nov  8 14:25:16 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 08 Nov 2006 08:25:16 -0500
Subject: [Tracker-discuss] Progress with server
In-Reply-To: <1162989777.23819.17.camel@localhost.localdomain>
References: <1162989777.23819.17.camel@localhost.localdomain>
Message-ID: <4551DABC.4040707@sympatico.ca>

Roch? Compaan wrote:
> Hi there
> 
> I'm finally back at the office today. The server that we ordered from
> Hetzner was available from last Thursday. Our sysadmin is currently
> finalising the install on the server and it should be ready by tomorrow.

Great !

> Can you please let me know which users should have access to the box and
> where I can get their SSH keys.

Here is mine: Stefan Seefeld, ssh key at http://www3.sympatico.ca/seefeld/ssh.txt

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Wed Nov  8 16:59:24 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 08 Nov 2006 16:59:24 +0100
Subject: [Tracker-discuss] Progress with server
In-Reply-To: <1162989777.23819.17.camel@localhost.localdomain>
	(=?iso-8859-1?Q?Roch=E9?=
	Compaan's message of "Wed, 08 Nov 2006 14:42:57 +0200")
References: <1162989777.23819.17.camel@localhost.localdomain>
Message-ID: <87bqnix737.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roch? Compaan <roche at upfrontsystems.co.za> writes:

> Hi there
>
> I'm finally back at the office today. The server that we ordered from
> Hetzner was available from last Thursday. Our sysadmin is currently
> finalising the install on the server and it should be ready by tomorrow.
>
> Can you please let me know which users should have access to the box and
> where I can get their SSH keys.

http://efod.se/about/ptkey.pub

Prefered username: forsberg

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFUf7crJurFAusidkRAqN3AJ9QBeBBzDM1oT0SggwnlcNAFQ0C2QCePnt6
4oNlpZtkmTkSGoCh4MWej3o=
=Pshl
-----END PGP SIGNATURE-----

From micktwomey at gmail.com  Wed Nov  8 17:05:48 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Wed, 8 Nov 2006 16:05:48 +0000
Subject: [Tracker-discuss] Progress with server
In-Reply-To: <4551DABC.4040707@sympatico.ca>
References: <1162989777.23819.17.camel@localhost.localdomain>
	<4551DABC.4040707@sympatico.ca>
Message-ID: <50a522ca0611080805q7c26476dqc5202c769e641194@mail.gmail.com>

On 11/8/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Roch? Compaan wrote:
> > Can you please let me know which users should have access to the box and
> > where I can get their SSH keys.
>

My key (Michael Twomey) is here: http://translucentcode.org/mick/ssh_key.txt

cheers,
  Michael

From pfdubois at gmail.com  Wed Nov  8 20:36:13 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 8 Nov 2006 11:36:13 -0800
Subject: [Tracker-discuss] Progress with server
In-Reply-To: <1162989777.23819.17.camel@localhost.localdomain>
References: <1162989777.23819.17.camel@localhost.localdomain>
Message-ID: <f74a6c2f0611081136p36fdea8dnf9b66afd0a4e5cd@mail.gmail.com>

Paul Dubois
Preferred user name dubois
key attached

On 11/8/06, Roch? Compaan <roche at upfrontsystems.co.za> wrote:
>
> Hi there
>
> I'm finally back at the office today. The server that we ordered from
> Hetzner was available from last Thursday. Our sysadmin is currently
> finalising the install on the server and it should be ready by tomorrow.
>
> Can you please let me know which users should have access to the box and
> where I can get their SSH keys.
>
> --
> Roch? Compaan
> Upfront Systems                 http://www.upfrontsystems.co.za
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061108/0a27a24c/attachment.htm 
-------------- next part --------------
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20061108"
AAAAB3NzaC1yc2EAAAABJQAAAIEAvQqtFuNPP7AhhpYtps8BC3os9vuq/yY5OZ0K
M/U7+ALvn1YrUacZwbcw0AD7X+LgnPZ8sHoK4YGf+rXWbIuQFu1V8gYhU+fS2QWw
ONlKGgbcPAwAH2opRTkq1CsV4DdNu/KjDxpZARKuqRJKsmd973Lq8HaWws3WmvrA
5eH/En0=
---- END SSH2 PUBLIC KEY ----

From brett at python.org  Wed Nov  8 20:52:01 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 8 Nov 2006 11:52:01 -0800
Subject: [Tracker-discuss] Progress with server
In-Reply-To: <1162989777.23819.17.camel@localhost.localdomain>
References: <1162989777.23819.17.camel@localhost.localdomain>
Message-ID: <bbaeab100611081152v50d302d6g4519e8d517d28874@mail.gmail.com>

On 11/8/06, Roch? Compaan <roche at upfrontsystems.co.za> wrote:
>
> Hi there
>
> I'm finally back at the office today. The server that we ordered from
> Hetzner was available from last Thursday. Our sysadmin is currently
> finalising the install on the server and it should be ready by tomorrow.
>
> Can you please let me know which users should have access to the box and
> where I can get their SSH keys.


The people who should have initial access to the box are Stefan Seefeld,
Erik Forsberg, Michael Twomey, and Paul DuBois.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061108/bf694eb0/attachment.html 

From pfdubois at gmail.com  Thu Nov  9 06:51:25 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 8 Nov 2006 21:51:25 -0800
Subject: [Tracker-discuss] triage team?
Message-ID: <f74a6c2f0611082151n7ee6b677p8b48633e2bc15719@mail.gmail.com>

Do the developers want a triage team (a list of people who receive email
when a new issue is opened?). (As typically implemented this does not put
them on the nosy list for the issue, just makes sure somebody sees every new
issue).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061108/7e01ae0d/attachment.htm 

From pfdubois at gmail.com  Thu Nov  9 06:52:28 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 8 Nov 2006 21:52:28 -0800
Subject: [Tracker-discuss] got it
In-Reply-To: <4552B75A.1070609@v.loewis.de>
References: <f74a6c2f0611081854s6ab9821bxd766b22d520027f7@mail.gmail.com>
	<4552B75A.1070609@v.loewis.de>
Message-ID: <f74a6c2f0611082152x1c275ba1ie3cb0849fdd81e63@mail.gmail.com>

I can confirm that I can check out, etc. Thanks for the help, Martin!

On 11/8/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Paul Dubois schrieb:
> > When I finally got the typo out, and figured out that pageant didn't
> > have my key after a reboot, things seem ok now. At least I can browse it
> > now.
>
> That's true. If you want it to load the key automatically at startup,
> you need to give the file name in the command line. In the Autostart
> item, look at properties, Target. I put there
>
> "C:\Program Files\PuTTY\pageant.exe" C:\loewis\.ssh\identity.ppk
>
> HTH,
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061108/0469b505/attachment.html 

From martin at v.loewis.de  Thu Nov  9 07:00:26 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 09 Nov 2006 07:00:26 +0100
Subject: [Tracker-discuss] triage team?
In-Reply-To: <f74a6c2f0611082151n7ee6b677p8b48633e2bc15719@mail.gmail.com>
References: <f74a6c2f0611082151n7ee6b677p8b48633e2bc15719@mail.gmail.com>
Message-ID: <4552C3FA.1010306@v.loewis.de>

Paul Dubois schrieb:
> Do the developers want a triage team (a list of people who receive email
> when a new issue is opened?). (As typically implemented this does not
> put them on the nosy list for the issue, just makes sure somebody sees
> every new issue).

There currently is a mailing list for that: python-bugs-list at python.org.
You can see the archive at

http://mail.python.org/pipermail/python-bugs-list/

We definitely want to keep it; it is currently configured to get *all*
changes to issues (not just when an report is added). Whether this is
also needed should be discussed (by default, it should continue to work
the way it always did, but if roundup offers alternative features, we
may want to use them).

Regards,
Martin

From pfdubois at gmail.com  Thu Nov  9 07:31:40 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 8 Nov 2006 22:31:40 -0800
Subject: [Tracker-discuss] triage and other matters
Message-ID: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>

My experience, even on a smaller (much!) tracker, is that sending all
changes to everyone on a list will wear out the people on that list. With
roundup I think it works best to send the *new* issues to that list and then
let the nosy mechanism do its thing. The nosy mechanism is *the* genius
invention in Roundup, I believe.

One can combine that with a periodic 'roundup-reminder' script or two on a
cron job; this sends a list to each developer of the open issues assigned to
them, and another can send a list of unassigned issues to some set of
people. I run these twice a month, for example, with the entire development
team getting the 'unassigned' list.

This brings me to an observation: the tracker as checked in consists of the
'template' area but does not have a spot for the rest of what one needs: the
crontab, server-ctl, server configuration file, etc. I usually have those in
the parent directory of the tracker but perhaps it is too late for that.
Anyway, we need a spot for this meta-stuff.

On 11/8/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Paul Dubois schrieb:
> > Do the developers want a triage team (a list of people who receive email
> > when a new issue is opened?). (As typically implemented this does not
> > put them on the nosy list for the issue, just makes sure somebody sees
> > every new issue).
>
> There currently is a mailing list for that: python-bugs-list at python.org.
> You can see the archive at
>
> http://mail.python.org/pipermail/python-bugs-list/
>
> We definitely want to keep it; it is currently configured to get *all*
> changes to issues (not just when an report is added). Whether this is
> also needed should be discussed (by default, it should continue to work
> the way it always did, but if roundup offers alternative features, we
> may want to use them).
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061108/3171c5a0/attachment.htm 

From roche at upfrontsystems.co.za  Thu Nov  9 10:19:54 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 09 Nov 2006 11:19:54 +0200
Subject: [Tracker-discuss] Server is ready
Message-ID: <1163063994.24779.30.camel@localhost.localdomain>

The server is ready. Our sysadmin has a few questions, like which
roundup to install and where to install it. Can the list moderator add
him to the list - his name is Izak Burger. He has already added the SSH
keys you gave to the server, which is currently reachable at
psf.upfronthosting.co.za.

This how we currently install roundup:

We don't install Roundup using debs, we install it from source
in /home/roundup owned by the roundup user. I suppose we must check out
a version from SVN?

We use Postfix as MTA that delivers to different trackers using 
.forward+trackername files in the roundup user's home directory. Do you
want deliver mail directly to Roundup or have read from a IMAP mailbox?

So far we have used the roundup server behind apache and that seems to
work quite well. Do you recommend we use mod_python?

We use both mysql and postgres as backend. One of our developers
recently fixed postgres' full text searching for Roundup so that might
make it a better option. Which do you prefer?

Are there any other setup dances you can think of?

-- 
Roch? Compaan
Upfront Systems                 http://www.upfrontsystems.co.za


From izak at upfrontsystems.co.za  Thu Nov  9 11:06:40 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Thu, 09 Nov 2006 12:06:40 +0200
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <1163063994.24779.30.camel@localhost.localdomain>
References: <1163063994.24779.30.camel@localhost.localdomain>
Message-ID: <4552FDB0.4010805@upfrontsystems.co.za>

Hi all,

Roch? Compaan wrote:
> The server is ready. Our sysadmin has a few questions, like which
> roundup to install and where to install it. Can the list moderator add
> him to the list - his name is Izak Burger. He has already added the SSH
> keys you gave to the server, which is currently reachable at
> psf.upfronthosting.co.za.

I used the usernames you asked for, otherwise I used those I found 
inside the public ssh keys.  I had to convert Paul's key with ssh-keygen 
to something openssh understands.  Also installed sudo and set it up so 
you have full rights.  Let me know if anything doesn't work.

> This how we currently install roundup:
> 
> We don't install Roundup using debs, we install it from source
> in /home/roundup owned by the roundup user. 

Traditionally we've always done it that way, and even though I prefer 
using debian packages (I roll my own if required) I think the 
traditional way will suit you better.

> So far we have used the roundup server behind apache and that seems to
> work quite well. Do you recommend we use mod_python?

I'm familiar with using apache or squid as a reverse proxy/accelerator. 
  Might need some details on a mod_python setup.

> We use both mysql and postgres as backend. One of our developers
> recently fixed postgres' full text searching for Roundup so that might
> make it a better option. Which do you prefer?

Personally I prefer postgresql, but it is up to you.  I know both 
databases well.

regards,
Izak

From izak at upfrontsystems.co.za  Thu Nov  9 11:44:59 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Thu, 09 Nov 2006 12:44:59 +0200
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <4552FDB0.4010805@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
Message-ID: <455306AB.607@upfrontsystems.co.za>

I forgot to mention, we run ssh on port 222.

From skip at pobox.com  Thu Nov  9 13:15:54 2006
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 9 Nov 2006 06:15:54 -0600
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
Message-ID: <17747.7162.693180.645987@montanaro.dyndns.org>


    Paul> My experience, even on a smaller (much!) tracker, is that sending
    Paul> all changes to everyone on a list will wear out the people on that
    Paul> list.

It's not a problem for me with the python-bugs list.  I am subscribed in
digest mode.  I get one or two messages a day and can just skim the subjects
looking for something I am interested in or think I can do something about.

Skip

From seefeld at sympatico.ca  Thu Nov  9 13:25:47 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 09 Nov 2006 07:25:47 -0500
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <4552FDB0.4010805@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
Message-ID: <45531E4B.1070202@sympatico.ca>

Izak Burger wrote:
> Hi all,
> 
> Roch? Compaan wrote:
>> The server is ready. Our sysadmin has a few questions, like which
>> roundup to install and where to install it. Can the list moderator add
>> him to the list - his name is Izak Burger. He has already added the SSH
>> keys you gave to the server, which is currently reachable at
>> psf.upfronthosting.co.za.
> 
> I used the usernames you asked for, otherwise I used those I found 
> inside the public ssh keys.  I had to convert Paul's key with ssh-keygen 
> to something openssh understands.  Also installed sudo and set it up so 
> you have full rights.  Let me know if anything doesn't work.

I can confirm that I'm able to login. Thanks a lot !

>> This how we currently install roundup:
>>
>> We don't install Roundup using debs, we install it from source
>> in /home/roundup owned by the roundup user. 
> 
> Traditionally we've always done it that way, and even though I prefer 
> using debian packages (I roll my own if required) I think the 
> traditional way will suit you better.

Yes, I agree. I just noticed roundup 1.3.0 was released, with a lot of
bug fixes, as usual.

>> So far we have used the roundup server behind apache and that seems to
>> work quite well. Do you recommend we use mod_python?
> 
> I'm familiar with using apache or squid as a reverse proxy/accelerator. 
>   Might need some details on a mod_python setup.
> 
>> We use both mysql and postgres as backend. One of our developers
>> recently fixed postgres' full text searching for Roundup so that might
>> make it a better option. Which do you prefer?
> 
> Personally I prefer postgresql, but it is up to you.  I know both 
> databases well.

Yes, I think for the python tracker we'd like both, mod_python as well as
postgresql.

However, we'd also like to have a 'meta tracker' where we can discuss
the configuration and tuning of the python tracker itself. This meta
tracker can be a vanilla 'classic' (demo) tracker without any tuning,
i.e. nothing that requires extra admin work to set up.
As soon as we can get that meta tracker up and running, we are ready
to discuss the work on the python tracker.

So: can you please set up a very simple meta tracker for us, and ideally
subscribe yourself so you can participate in discussions, if any issues
involve administrative aspects ?

Thanks,
		Stefan



-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Thu Nov  9 14:35:58 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 09 Nov 2006 15:35:58 +0200
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <45531E4B.1070202@sympatico.ca>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za> <45531E4B.1070202@sympatico.ca>
Message-ID: <1163079358.24779.52.camel@localhost.localdomain>

[Resending to list - forgot to CC list when I replied to Stefan]

On Thu, 2006-11-09 at 07:25 -0500, Stefan Seefeld wrote:
> Izak Burger wrote:
> > Hi all,
> > 
> > Roch? Compaan wrote:
> >> The server is ready. Our sysadmin has a few questions, like which
> >> roundup to install and where to install it. Can the list moderator add
> >> him to the list - his name is Izak Burger. He has already added the SSH
> >> keys you gave to the server, which is currently reachable at
> >> psf.upfronthosting.co.za.
> > 
> > I used the usernames you asked for, otherwise I used those I found 
> > inside the public ssh keys.  I had to convert Paul's key with ssh-keygen 
> > to something openssh understands.  Also installed sudo and set it up so 
> > you have full rights.  Let me know if anything doesn't work.
> 
> I can confirm that I'm able to login. Thanks a lot !
> 
> >> This how we currently install roundup:
> >>
> >> We don't install Roundup using debs, we install it from source
> >> in /home/roundup owned by the roundup user. 
> > 
> > Traditionally we've always done it that way, and even though I prefer 
> > using debian packages (I roll my own if required) I think the 
> > traditional way will suit you better.
> 
> Yes, I agree. I just noticed roundup 1.3.0 was released, with a lot of
> bug fixes, as usual.
> 
> >> So far we have used the roundup server behind apache and that seems to
> >> work quite well. Do you recommend we use mod_python?
> > 
> > I'm familiar with using apache or squid as a reverse proxy/accelerator. 
> >   Might need some details on a mod_python setup.
> > 
> >> We use both mysql and postgres as backend. One of our developers
> >> recently fixed postgres' full text searching for Roundup so that might
> >> make it a better option. Which do you prefer?
> > 
> > Personally I prefer postgresql, but it is up to you.  I know both 
> > databases well.
> 
> Yes, I think for the python tracker we'd like both, mod_python as well as
> postgresql.
> 
> However, we'd also like to have a 'meta tracker' where we can discuss
> the configuration and tuning of the python tracker itself. This meta
> tracker can be a vanilla 'classic' (demo) tracker without any tuning,
> i.e. nothing that requires extra admin work to set up.
> As soon as we can get that meta tracker up and running, we are ready
> to discuss the work on the python tracker.
> 
> So: can you please set up a very simple meta tracker for us, and ideally
> subscribe yourself so you can participate in discussions, if any issues
> involve administrative aspects ?

Ok to summarise then, we're going to install the just released Roundup
1.3 using mod_python behind apache and postgresql as backend. When that
is done we'll setup a vanilla 'classic' meta tracker.

What must the web address of the web tracker be. For now we'll just make
it metatracker.psf.upfronthosting.co.za until you point the
bugs.python.org domain at the server.

Btw, I am going to ask Izak to setup a demo of our tracker skin as well
- it's reminiscent of the old skin that Kaping Yee developed and
highlights priority clearly with color. If you don't like it we can
chuck it away.

-- 
Roch? Compaan
Upfront Systems                 http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Thu Nov  9 14:58:58 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 09 Nov 2006 08:58:58 -0500
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <1163079358.24779.52.camel@localhost.localdomain>
References: <1163063994.24779.30.camel@localhost.localdomain>	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
Message-ID: <45533422.4070008@sympatico.ca>

Roch? Compaan wrote:

>> So: can you please set up a very simple meta tracker for us, and ideally
>> subscribe yourself so you can participate in discussions, if any issues
>> involve administrative aspects ?
> 
> Ok to summarise then, we're going to install the just released Roundup
> 1.3 using mod_python behind apache and postgresql as backend. When that
> is done we'll setup a vanilla 'classic' meta tracker.

Great. (For avoidance of doubt: for the meta tracker the default 'anydb'
backend would work just as well.)

> What must the web address of the web tracker be. For now we'll just make
> it metatracker.psf.upfronthosting.co.za until you point the
> bugs.python.org domain at the server.

OK.

> Btw, I am going to ask Izak to setup a demo of our tracker skin as well
> - it's reminiscent of the old skin that Kaping Yee developed and
> highlights priority clearly with color. If you don't like it we can
> chuck it away.

Thanks ! Please don't put any efford into the meta tracker, it's really
just for us admins and python-tracker reviewers to use. It doesn't need
to be beautiful or particularly fast. The closer it is to the roundup
demo tracker the better, since it makes upgrading easier.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Thu Nov  9 15:04:22 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 9 Nov 2006 15:04:22 +0100
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <1163079358.24779.52.camel@localhost.localdomain>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
Message-ID: <200611091504.22907.forsberg@efod.se>

torsdag 09 november 2006 14:35 skrev Roch? Compaan:
> Ok to summarise then, we're going to install the just released Roundup
> 1.3 using mod_python behind apache and postgresql as backend. When that
> is done we'll setup a vanilla 'classic' meta tracker.

Sounds good. I'll export the contents of http://efod.se/ptt to import in this 
tracker. 

Cheers,
\EF
-- 
http://efod.se/

From izak at upfrontsystems.co.za  Thu Nov  9 16:05:39 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Thu, 09 Nov 2006 17:05:39 +0200
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <45531E4B.1070202@sympatico.ca>
References: <1163063994.24779.30.camel@localhost.localdomain>	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
Message-ID: <455343C3.2010409@upfrontsystems.co.za>

Stefan Seefeld wrote:
> I can confirm that I'm able to login. Thanks a lot !

One more thing.  At the moment users can sudo without a password.  We 
want to lock this down a bit more, so would you all please run the command:

     sudo passwd username

On your relevant usernames to set a password.  At the moment the 
accounts are all locked.  Once that is in place I will make sudo prompt 
for a password.

regards,
Izak

From pfdubois at gmail.com  Thu Nov  9 16:20:40 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 9 Nov 2006 07:20:40 -0800
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <200611091504.22907.forsberg@efod.se>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
	<200611091504.22907.forsberg@efod.se>
Message-ID: <f74a6c2f0611090720y6888596dsce70df85e35739a9@mail.gmail.com>

I did not succeed at logging in. It asks for a user name and I put
paul.dubois. Then it asks me for a password. I did not use a passphrase when
I generated the key so I tried just return. Access denied.

Putty has a lot of controls in the 'ssh' options section and I'm not at all
convinced I know how to set them. I tried several variations. putty is
working fine to my work where I use a one-time password generator but not a
key.

Putty is running "pageant" as an 'ssh authentication agent'. I have verified
that it has loaded my key.

On 11/9/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> torsdag 09 november 2006 14:35 skrev Roch? Compaan:
> > Ok to summarise then, we're going to install the just released Roundup
> > 1.3 using mod_python behind apache and postgresql as backend. When that
> > is done we'll setup a vanilla 'classic' meta tracker.
>
> Sounds good. I'll export the contents of http://efod.se/ptt to import in
> this
> tracker.
>
> Cheers,
> \EF
> --
> http://efod.se/
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/969d7a97/attachment.htm 

From seefeld at sympatico.ca  Thu Nov  9 16:48:08 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 09 Nov 2006 10:48:08 -0500
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <455343C3.2010409@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>	<4552FDB0.4010805@upfrontsystems.co.za>	<45531E4B.1070202@sympatico.ca>
	<455343C3.2010409@upfrontsystems.co.za>
Message-ID: <45534DB8.20808@sympatico.ca>

Izak Burger wrote:

> One more thing.  At the moment users can sudo without a password.  We 
> want to lock this down a bit more, so would you all please run the command:
> 
>      sudo passwd username

Done.

Thanks,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From micktwomey at gmail.com  Thu Nov  9 16:58:24 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Thu, 9 Nov 2006 15:58:24 +0000
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <455343C3.2010409@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<455343C3.2010409@upfrontsystems.co.za>
Message-ID: <50a522ca0611090758o283edbf0h31f1da824e1d8ef0@mail.gmail.com>

On 11/9/06, Izak Burger <izak at upfrontsystems.co.za> wrote:
> One more thing.  At the moment users can sudo without a password.  We
> want to lock this down a bit more, so would you all please run the command:
>
>      sudo passwd username
>

I'm having difficulty reaching the machine from work, I'll try again
when I get home, so don't lock it down just yet :)

It's probable there is some routing funniness from my office to the
machine. I can ping it without any problems but ssh times out (I tried
ports 22 and 222).

mick

From forsberg at efod.se  Thu Nov  9 17:32:10 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 09 Nov 2006 17:32:10 +0100
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <1163079358.24779.52.camel@localhost.localdomain>
	(=?iso-8859-1?Q?Roch=E9?=
	Compaan's message of "Thu, 09 Nov 2006 15:35:58 +0200")
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
Message-ID: <87zmb0wph1.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roch? Compaan <roche at upfrontsystems.co.za> writes:

> Ok to summarise then, we're going to install the just released Roundup
> 1.3 using mod_python behind apache and postgresql as backend. When that
> is done we'll setup a vanilla 'classic' meta tracker.

Sounds good. 

Btw, it would be nice to get some clarifications on the areas of
responsibility. What is included in the hosting offer, and what is
left to the tracker team? 

I'm don't want to draw any hard lines, I just thought some guidelines
would ease our work. Cooperation is the keyword! :-)

> What must the web address of the web tracker be. For now we'll just make
> it metatracker.psf.upfronthosting.co.za until you point the
> bugs.python.org domain at the server.

My idea on this is to let http://bugs.python.org/ be a simple index
page, much like http://wiki.python.org/, listing the trackers
available on the host. This way, if we choose to support jython, foo,
bar or some other project in the future, it's just a matter of adding
the tracker there after setting it up.

Mail addresses on the form <trackername>@bugs.python.org can then be
used for the mail interface.

This is however one of the things we should let the people from
python-dev decide. 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFU1gJrJurFAusidkRAhBXAKDZ7n7k4rFfFkeZ0iBvZcB9hv4LowCgy9KD
QMQRL00UlWrQZYg/ZV8pswc=
=zuDA
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Thu Nov  9 17:40:08 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 09 Nov 2006 11:40:08 -0500
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <87zmb0wph1.fsf@uterus.efod.se>
References: <1163063994.24779.30.camel@localhost.localdomain>	<4552FDB0.4010805@upfrontsystems.co.za>	<45531E4B.1070202@sympatico.ca>	<1163079358.24779.52.camel@localhost.localdomain>
	<87zmb0wph1.fsf@uterus.efod.se>
Message-ID: <455359E8.8030208@sympatico.ca>

Erik Forsberg wrote:
> Roch? Compaan <roche at upfrontsystems.co.za> writes:

>>> What must the web address of the web tracker be. For now we'll just make
>>> it metatracker.psf.upfronthosting.co.za until you point the
>>> bugs.python.org domain at the server.
> 
> My idea on this is to let http://bugs.python.org/ be a simple index
> page, much like http://wiki.python.org/, listing the trackers
> available on the host. This way, if we choose to support jython, foo,
> bar or some other project in the future, it's just a matter of adding
> the tracker there after setting it up.

Right. In fact, I think 'issues.python.org' or 'tracker.python.org' would
be more suitable, since not everything tracked will be a bug.

> Mail addresses on the form <trackername>@bugs.python.org can then be
> used for the mail interface.

Or simply bugs at python.org, peps at python.org, etc. to get routed to the
appropriate tracker instance on this machine.

> This is however one of the things we should let the people from
> python-dev decide. 

I agree. Luckily, it doesn't really affect the tracker tuning, it's
only a handfull of entries in the config file...

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov  9 17:56:30 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 9 Nov 2006 08:56:30 -0800
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <45534A53.1050309@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
	<200611091504.22907.forsberg@efod.se>
	<f74a6c2f0611090720y6888596dsce70df85e35739a9@mail.gmail.com>
	<45534A53.1050309@upfrontsystems.co.za>
Message-ID: <f74a6c2f0611090856kf80825fg53f3e96434263b52@mail.gmail.com>

I am an idiot. I'll try it when I get home from work.


On 11/9/06, Izak Burger <izak at upfrontsystems.co.za> wrote:
>
> Paul Dubois wrote:
> > I did not succeed at logging in.
>
> Your username is dubois (as requested).
>
> > Putty has a lot of controls in the 'ssh' options section and I'm not at
> > all convinced I know how to set them. I tried several variations. putty
> > is working fine to my work where I use a one-time password generator but
> > not a key.
> >
> > Putty is running "pageant" as an 'ssh authentication agent'. I have
> > verified that it has loaded my key.
>
> It should work if you specify the correct username, unless there is a
> problem with the key.  If you still cannot log in, I'll set a password
> and mail it to you in some or other secure fashion.
>
> regards,
> Izak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/27a9d439/attachment.htm 

From kbk at shore.net  Thu Nov  9 17:57:17 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 09 Nov 2006 11:57:17 -0500
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	(Paul Dubois's message of "Wed, 8 Nov 2006 22:31:40 -0800")
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
Message-ID: <87d57weexe.fsf@hydra.bayview.thirdcreek.com>

> On 11/8/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>
>> Paul Dubois schrieb:
>> > Do the developers want a triage team (a list of people who receive
>> > email when a new issue is opened?). (As typically implemented this
>> > does not put them on the nosy list for the issue, just makes sure
>> > somebody sees every new issue).
>>
>> There currently is a mailing list for that:
>> python-bugs-list at python.org.  You can see the archive at
>>
>> http://mail.python.org/pipermail/python-bugs-list/
>>
>> We definitely want to keep it; it is currently configured to get
>> *all* changes to issues (not just when an report is added). Whether
>> this is also needed should be discussed (by default, it should
>> continue to work the way it always did, but if roundup offers
>> alternative features, we may want to use them).
===========================
"Paul Dubois" <pfdubois at gmail.com> writes:

> My experience, even on a smaller (much!) tracker, is that sending all
> changes to everyone on a list will wear out the people on that
> list. With roundup I think it works best to send the *new* issues to
> that list and then let the nosy mechanism do its thing. The nosy
> mechanism is *the* genius invention in Roundup, I believe.

There is the additional issue of the weekly Patch/Bug status report.
Currently, this is created by analyzing the mail from the bugs and
patches lists for opened/reopened and closed items, plus a simple scrape
of the total number of open/closed issues from a SF webpage.

I suppose there is a way to get this information from the Roundup
database, but it seems like a total rewrite of the report would be
needed to do that.

-- 
KBK

From micktwomey at gmail.com  Thu Nov  9 18:11:15 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Thu, 9 Nov 2006 17:11:15 +0000
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <87d57weexe.fsf@hydra.bayview.thirdcreek.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<87d57weexe.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <50a522ca0611090911j1c4ec28u6d54c093b8a77b78@mail.gmail.com>

On 11/9/06, Kurt B. Kaiser <kbk at shore.net> wrote:
> There is the additional issue of the weekly Patch/Bug status report.
> Currently, this is created by analyzing the mail from the bugs and
> patches lists for opened/reopened and closed items, plus a simple scrape
> of the total number of open/closed issues from a SF webpage.
>
> I suppose there is a way to get this information from the Roundup
> database, but it seems like a total rewrite of the report would be
> needed to do that.
>

I've got a similar report running in my work. I have a simple python
cron job which opens up the roundup instance and does a few queries
and produces a report of outstanding issues.

Is the code for the existing report lying around somewhere? We can
start rewriting it as a roundup query even with the schema still in
flux.

cheers,
  mick

From forsberg at efod.se  Thu Nov  9 18:26:08 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 09 Nov 2006 18:26:08 +0100
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <200611091504.22907.forsberg@efod.se> (Erik Forsberg's message of
	"Thu, 9 Nov 2006 15:04:22 +0100")
References: <1163063994.24779.30.camel@localhost.localdomain>
	<45531E4B.1070202@sympatico.ca>
	<1163079358.24779.52.camel@localhost.localdomain>
	<200611091504.22907.forsberg@efod.se>
Message-ID: <87slgswmz3.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Forsberg <forsberg at efod.se> writes:

> torsdag 09 november 2006 14:35 skrev Roch? Compaan:
>> Ok to summarise then, we're going to install the just released Roundup
>> 1.3 using mod_python behind apache and postgresql as backend. When that
>> is done we'll setup a vanilla 'classic' meta tracker.
>
> Sounds good. I'll export the contents of http://efod.se/ptt to import in this > tracker. 

~forsberg/ptt-export on psf now contains an export of
http://efod.se/ptt for import into the new tracker once it's ready.

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFU2SvrJurFAusidkRAqc0AKDkKg0wRGlg79TrKMoTiE46jM1CKgCgxNsZ
nsXCY7wzEN/YJorp+F+HV7E=
=oRJM
-----END PGP SIGNATURE-----

From forsberg at efod.se  Thu Nov  9 18:33:26 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 09 Nov 2006 18:33:26 +0100
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <455343C3.2010409@upfrontsystems.co.za> (Izak Burger's message of
	"Thu, 09 Nov 2006 17:05:39 +0200")
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<455343C3.2010409@upfrontsystems.co.za>
Message-ID: <87odrgwmmx.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Izak Burger <izak at upfrontsystems.co.za> writes:

> One more thing.  At the moment users can sudo without a password.  We 
> want to lock this down a bit more, so would you all please run the command:
>
>      sudo passwd username

Done. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD4DBQFFU2ZlrJurFAusidkRAiyAAKC9BA3DWgsS4t9V5QXskADmq/KOJwCY6n/R
VUyo3rcF/erNWGosU/RoMA==
=VQ6S
-----END PGP SIGNATURE-----

From g.brandl at gmx.net  Thu Nov  9 19:34:00 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 09 Nov 2006 19:34:00 +0100
Subject: [Tracker-discuss] triage team?
In-Reply-To: <4552C3FA.1010306@v.loewis.de>
References: <f74a6c2f0611082151n7ee6b677p8b48633e2bc15719@mail.gmail.com>
	<4552C3FA.1010306@v.loewis.de>
Message-ID: <45537498.1050802@gmx.net>

Martin v. L?wis schrieb:
> Paul Dubois schrieb:
>> Do the developers want a triage team (a list of people who receive email
>> when a new issue is opened?). (As typically implemented this does not
>> put them on the nosy list for the issue, just makes sure somebody sees
>> every new issue).
> 
> There currently is a mailing list for that: python-bugs-list at python.org.
> You can see the archive at
> 
> http://mail.python.org/pipermail/python-bugs-list/
> 
> We definitely want to keep it; it is currently configured to get *all*
> changes to issues (not just when an report is added). Whether this is
> also needed should be discussed (by default, it should continue to work
> the way it always did, but if roundup offers alternative features, we
> may want to use them).

Definitely a +1 on that. I read the mailing list via gmane, which is very
comfortable (and does not clutter up my mailbox), and I would very much
like to continue doing that.

What should be discontinued, of course, is the extra list for patches.
When both issue types are unified, it doesn't make sense to keep
separated lists.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/54c49b65/attachment-0001.pgp 

From martin at v.loewis.de  Thu Nov  9 19:59:34 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 09 Nov 2006 19:59:34 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
Message-ID: <45537A96.3050200@v.loewis.de>

Paul Dubois schrieb:
> My experience, even on a smaller (much!) tracker, is that sending all
> changes to everyone on a list will wear out the people on that list.
> With roundup I think it works best to send the *new* issues to that list
> and then let the nosy mechanism do its thing. The nosy mechanism is
> *the* genius invention in Roundup, I believe.

Ok, it's fine with me: the tracker team should come up with a policy,
and then present this policy to python-dev. Current subscribers
should know that the information volume changes, and what they should
do to get added to the nosy list of some item.

FWIW, I don't subscribe to python-bugs-list at all. Instead, I get
auto-assigned for a few areas (Tkinter in particular), and check
the bugs website more-or-less regularly.

Regards,
Martin

From forsberg at efod.se  Thu Nov  9 20:05:11 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 09 Nov 2006 20:05:11 +0100
Subject: [Tracker-discuss] triage team?
In-Reply-To: <4552C3FA.1010306@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Thu, 09 Nov 2006 07:00:26 +0100")
References: <f74a6c2f0611082151n7ee6b677p8b48633e2bc15719@mail.gmail.com>
	<4552C3FA.1010306@v.loewis.de>
Message-ID: <87k624wie0.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> We definitely want to keep it; it is currently configured to get *all*
> changes to issues (not just when an report is added). Whether this is
> also needed should be discussed (by default, it should continue to work
> the way it always did, but if roundup offers alternative features, we
> may want to use them).

Basically, roundup can be told to do basically anything at any type of
change. It's just a matter of writing a detector (a piece of python
code) that triggers on the exact behaviour where some kind of action
should be run.

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFU3vmrJurFAusidkRApAXAKDE6NUq+QjN068TEg4D6giocYRM7QCgibpn
+0jGynrkgcw+uQXK6BLEtX0=
=pvIm
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Thu Nov  9 20:25:27 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 09 Nov 2006 20:25:27 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <87d57weexe.fsf@hydra.bayview.thirdcreek.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<87d57weexe.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <455380A7.9010503@v.loewis.de>

Kurt B. Kaiser schrieb:
> I suppose there is a way to get this information from the Roundup
> database, but it seems like a total rewrite of the report would be
> needed to do that.

I think this is fairly easy to do on the machine where the tracker
runs, and much more complicated off-site. So I would like to add
this to the task list of the tracker conversion project.

While we are at it: the sf redirector (python.org/sf/<id>) must
also be converted.

Regards,
Martin


From brett at python.org  Thu Nov  9 20:51:42 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 9 Nov 2006 11:51:42 -0800
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <45537A96.3050200@v.loewis.de>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<45537A96.3050200@v.loewis.de>
Message-ID: <bbaeab100611091151t53b9d501h21ec28ba0cdadc1e@mail.gmail.com>

On 11/9/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Paul Dubois schrieb:
> > My experience, even on a smaller (much!) tracker, is that sending all
> > changes to everyone on a list will wear out the people on that list.
> > With roundup I think it works best to send the *new* issues to that list
> > and then let the nosy mechanism do its thing. The nosy mechanism is
> > *the* genius invention in Roundup, I believe.
>
> Ok, it's fine with me: the tracker team should come up with a policy,
> and then present this policy to python-dev. Current subscribers
> should know that the information volume changes, and what they should
> do to get added to the nosy list of some item.
>
> FWIW, I don't subscribe to python-bugs-list at all. Instead, I get
> auto-assigned for a few areas (Tkinter in particular), and check
> the bugs website more-or-less regularly.


Can we offer both?  I know Tim Peters requested back in the day to have the
bugs list only send an email when a bug is opened, but enough people wanted
an email for every activity that the list was not changed.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/6fcc0a5a/attachment.htm 

From martin at v.loewis.de  Thu Nov  9 21:03:32 2006
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 09 Nov 2006 21:03:32 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <bbaeab100611091151t53b9d501h21ec28ba0cdadc1e@mail.gmail.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>	
	<45537A96.3050200@v.loewis.de>
	<bbaeab100611091151t53b9d501h21ec28ba0cdadc1e@mail.gmail.com>
Message-ID: <45538994.50306@v.loewis.de>

Brett Cannon schrieb:
> Can we offer both?  I know Tim Peters requested back in the day to have
> the bugs list only send an email when a bug is opened, but enough people
> wanted an email for every activity that the list was not changed.

I think we can have all we want. We could have two lists, in which
case a second list name is needed, and a decision whether the existing
list becomes the one with more traffic, or the one with less traffic.

Regards,
Martin

From brett at python.org  Thu Nov  9 21:05:55 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 9 Nov 2006 12:05:55 -0800
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <45538994.50306@v.loewis.de>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<45537A96.3050200@v.loewis.de>
	<bbaeab100611091151t53b9d501h21ec28ba0cdadc1e@mail.gmail.com>
	<45538994.50306@v.loewis.de>
Message-ID: <bbaeab100611091205l2f57cf8aoe194b064ad9426ac@mail.gmail.com>

On 11/9/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Brett Cannon schrieb:
> > Can we offer both?  I know Tim Peters requested back in the day to have
> > the bugs list only send an email when a bug is opened, but enough people
> > wanted an email for every activity that the list was not changed.
>
> I think we can have all we want. We could have two lists, in which
> case a second list name is needed, and a decision whether the existing
> list becomes the one with more traffic, or the one with less traffic.


I say the current list stays as-is and we add a list named new-bugs-announce
or such that gets an email for each new issue created only.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/ac141f00/attachment.html 

From g.brandl at gmx.net  Thu Nov  9 21:13:45 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 09 Nov 2006 21:13:45 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <bbaeab100611091205l2f57cf8aoe194b064ad9426ac@mail.gmail.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>	<45537A96.3050200@v.loewis.de>	<bbaeab100611091151t53b9d501h21ec28ba0cdadc1e@mail.gmail.com>	<45538994.50306@v.loewis.de>
	<bbaeab100611091205l2f57cf8aoe194b064ad9426ac@mail.gmail.com>
Message-ID: <45538BF9.9070109@gmx.net>

Brett Cannon schrieb:
> 
> 
> On 11/9/06, *"Martin v. L?wis"* <martin at v.loewis.de
> <mailto:martin at v.loewis.de>> wrote:
> 
>     Brett Cannon schrieb:
>     > Can we offer both?  I know Tim Peters requested back in the day to
>     have
>     > the bugs list only send an email when a bug is opened, but enough
>     people
>     > wanted an email for every activity that the list was not changed.
> 
>     I think we can have all we want. We could have two lists, in which
>     case a second list name is needed, and a decision whether the existing
>     list becomes the one with more traffic, or the one with less traffic. 
> 
> 
> I say the current list stays as-is and we add a list named
> new-bugs-announce or such that gets an email for each new issue created
> only.

Sounds like a good solution to me.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/d39b1f9f/attachment.pgp 

From forsberg at efod.se  Thu Nov  9 21:47:38 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 09 Nov 2006 21:47:38 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <50a522ca0611090911j1c4ec28u6d54c093b8a77b78@mail.gmail.com>
	(Michael Twomey's message of "Thu, 9 Nov 2006 17:11:15 +0000")
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<87d57weexe.fsf@hydra.bayview.thirdcreek.com>
	<50a522ca0611090911j1c4ec28u6d54c093b8a77b78@mail.gmail.com>
Message-ID: <87d57wwdn9.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Michael Twomey" <micktwomey at gmail.com> writes:

> Is the code for the existing report lying around somewhere? 

I would also like to see it - it would be useful to get a list of bugs
that have changed since last time the import was run, to avoid having
to scrape so much of sourceforge.

Unfortunately, the sourceforge tracker index doesn't list when bugs
was last changed... at least not from what I can see. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFU5PorJurFAusidkRAmD2AKDLX3Ljs3/xd0Ig5wT/j7OYNSwseQCfXcU9
jbxdGbQ57nOBmOTehRejI+A=
=EIjr
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Thu Nov  9 21:58:32 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 09 Nov 2006 15:58:32 -0500
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
Message-ID: <45539678.3030409@sympatico.ca>

Paul Dubois wrote:
> My experience, even on a smaller (much!) tracker, is that sending all
> changes to everyone on a list will wear out the people on that list. With
> roundup I think it works best to send the *new* issues to that list and
> then
> let the nosy mechanism do its thing. The nosy mechanism is *the* genius
> invention in Roundup, I believe.

I'm not quite sure. For users it should make no difference, whether they
get added to some send-me-a-mail-for-each-new-issue detector inside
roundup, or whether they subscribe to a mailing list this detector sends
the notification to.
I believe it's more a question of scale. If the list is small, it's
simpler to handle by roundup internally, but if it gets bigger, it may not.

Don't forget that the list itself exist for this very purpose, so if people
subscribe, it's because they really want this notificaion.

(The list of course needs to be read-only, without archives, etc.)

On the other hand, It may make sense to triage the issues in terms
of topic/component/platform/whatever and then let users subscribe only
to a subset of issues, based on those attributes.
I think there the power of roundup is much more useful.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov  9 22:46:46 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 9 Nov 2006 13:46:46 -0800
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <45539678.3030409@sympatico.ca>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<45539678.3030409@sympatico.ca>
Message-ID: <f74a6c2f0611091346o36db63dg98052a3a97aec809@mail.gmail.com>

I apparently was not clear. I'm not suggesting some sort of fancy mechanism
to manage the triage list inside Roundup. (Triage list being my term for the
set of people who get notified of new issues.)

Obviously, the triage list can just be a normal mailing list; and the
suggestion that we have two, one for 'new issues' and one for 'everything',
is fine too. I can't believe anybody wants to read every message about every
issue, even if in digest form, but there is no problem sending it if that is
what they want.

Again, I'm just saying that nosy lists are Roundup's most powerful and
effective feature, and I believe that most people who get used to nosy lists
are not going to want to be on the 'everything' list any more. When we
present the tracker to the community we will want to make clear the new mode
of operation that nosy lists make possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/d7ec142b/attachment.htm 

From micktwomey at gmail.com  Thu Nov  9 23:19:05 2006
From: micktwomey at gmail.com (Michael Twomey)
Date: Thu, 9 Nov 2006 22:19:05 +0000
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <50a522ca0611090758o283edbf0h31f1da824e1d8ef0@mail.gmail.com>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<455343C3.2010409@upfrontsystems.co.za>
	<50a522ca0611090758o283edbf0h31f1da824e1d8ef0@mail.gmail.com>
Message-ID: <50a522ca0611091419v1f03c03bv910b3662b002955a@mail.gmail.com>

On 11/9/06, Michael Twomey <micktwomey at gmail.com> wrote:
> On 11/9/06, Izak Burger <izak at upfrontsystems.co.za> wrote:
> > One more thing.  At the moment users can sudo without a password.  We
> > want to lock this down a bit more, so would you all please run the command:
> >
> >      sudo passwd username
> >
>

Ok, I've changed my password.

Seems my work network doesn't like ssh to some places, I'll have to
find out why.

cheers,
  Michael

From pfdubois at gmail.com  Fri Nov 10 02:29:02 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 9 Nov 2006 17:29:02 -0800
Subject: [Tracker-discuss] Server is ready
In-Reply-To: <455343C3.2010409@upfrontsystems.co.za>
References: <1163063994.24779.30.camel@localhost.localdomain>
	<4552FDB0.4010805@upfrontsystems.co.za>
	<45531E4B.1070202@sympatico.ca>
	<455343C3.2010409@upfrontsystems.co.za>
Message-ID: <f74a6c2f0611091729l3be9b30dwb99df3bdbba50cf0@mail.gmail.com>

Login and sudo passwd done.

On 11/9/06, Izak Burger <izak at upfrontsystems.co.za> wrote:
>
> Stefan Seefeld wrote:
> > I can confirm that I'm able to login. Thanks a lot !
>
> One more thing.  At the moment users can sudo without a password.  We
> want to lock this down a bit more, so would you all please run the
> command:
>
>      sudo passwd username
>
> On your relevant usernames to set a password.  At the moment the
> accounts are all locked.  Once that is in place I will make sudo prompt
> for a password.
>
> regards,
> Izak
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061109/e2eb12d4/attachment.html 

From roche at upfrontsystems.co.za  Fri Nov 10 20:54:44 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Fri, 10 Nov 2006 21:54:44 +0200
Subject: [Tracker-discuss] Roundup installed
Message-ID: <1163188484.7826.36.camel@kwaaitjie>

Izak has completed the installation of Apache, Postfix and Roundup.

It is running at http://psf.upfronthosting.co.za/roundup/meta/ and you
should be able to register as a user.

Submitting issues via the web doesn't work at the moment due to a
permission error. This reminded me why we prefer using the roundup
server - it can run as the roundup user and it saves you the hassle of
permissions dances with Apache. Mail delivery works fine.

mod_python scripts should also be executing as the roundup user but the
SuexecUserGroup directive is ignored at the moment (most probably
because of restrictive compile options that we are violating). We need
to checkout the debian compile options for Apache.

Changing the group of the "db/files" directory to www-data and setting
the sticky bit doesn't solve the problem either, although this is a path
to be avoided

If anybody else wants to debug this or offer advise they are welcome.

As far as responsibilities on the server goes, my feeling is that we can
all help. It is probably simpler if we (Upfront Systems) look after the
maintenance and security of the server and the rest of the
administrators look at roundup. We would like to help with Roundup as
far as we can though. We can coordinate the effort using a tracker but
let's spell this out in another thread.

Any questions about the current setup are welcome.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From izak at upfrontsystems.co.za  Sat Nov 11 07:18:52 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sat, 11 Nov 2006 08:18:52 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163188484.7826.36.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>
Message-ID: <45556B4C.6030403@upfrontsystems.co.za>

Hi all,

Roch? Compaan wrote:
> It is running at http://psf.upfronthosting.co.za/roundup/meta/ and you
> should be able to register as a user.

config.ini needs a few more tweaks.  The mail comes from the wrong 
address at the moment for example...

> Submitting issues via the web doesn't work at the moment due to a
> permission error. This reminded me why we prefer using the roundup
> server - it can run as the roundup user and it saves you the hassle of
> permissions dances with Apache. Mail delivery works fine.

I'm thinking of this: http://httpd.apache.org/docs/2.0/mod/perchild.html

> mod_python scripts should also be executing as the roundup user but the
> SuexecUserGroup directive is ignored at the moment (most probably
> because of restrictive compile options that we are violating). We need
> to checkout the debian compile options for Apache.

suexec only works with actual cgi scripts.

> As far as responsibilities on the server goes, my feeling is that we can
> all help. It is probably simpler if we (Upfront Systems) look after the
> maintenance and security of the server and the rest of the
> administrators look at roundup. We would like to help with Roundup as
> far as we can though. We can coordinate the effort using a tracker but
> let's spell this out in another thread.

I agree.

> Any questions about the current setup are welcome.

One other thing that isn't clear to me.  With the mod_python example in 
the documentation (I added a rewrite rule to redirect to /roundup/) 
there is no way to get an index page, ie a list of the hosted trackers. 
  The builtin server does this if you have more than one tracker and 
don't specify a specific one.  How would you make a mod_python setup do 
the same?  Or should we simply use a static index page that needs 
updating whenever a new tracker is added?


regards,
Izak

From seefeld at sympatico.ca  Sat Nov 11 07:48:52 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 01:48:52 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <45556B4C.6030403@upfrontsystems.co.za>
References: <1163188484.7826.36.camel@kwaaitjie>
	<45556B4C.6030403@upfrontsystems.co.za>
Message-ID: <45557254.7050900@sympatico.ca>

Izak Burger wrote:

> One other thing that isn't clear to me.  With the mod_python example in 
> the documentation (I added a rewrite rule to redirect to /roundup/) 
> there is no way to get an index page, ie a list of the hosted trackers. 
>   The builtin server does this if you have more than one tracker and 
> don't specify a specific one.  How would you make a mod_python setup do 
> the same?  Or should we simply use a static index page that needs 
> updating whenever a new tracker is added?

Yes. While it may be convenient to have some toplevel page display
all tracker instances served on the given URL, I think we don't really
want to use this feature. If at some point there are multiple trackers
served at the same access point, we most certainly want to hand-write
an index page with helpful information to let users find their way.

I wouldn't worry about that at all. In fact I'd assume that those
trackers would all use some alias URL, i.e. would require some
apache rewrite rule anyway.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Sat Nov 11 10:36:38 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 10:36:38 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163188484.7826.36.camel@kwaaitjie> (=?iso-8859-1?Q?Roch=E9?=
	Compaan's message of "Fri, 10 Nov 2006 21:54:44 +0200")
References: <1163188484.7826.36.camel@kwaaitjie>
Message-ID: <87wt62uxy1.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roch? Compaan <roche at upfrontsystems.co.za> writes:

> Izak has completed the installation of Apache, Postfix and Roundup.

Excellent!

> It is running at http://psf.upfronthosting.co.za/roundup/meta/ and you
> should be able to register as a user.

I took the liberty of importing the data from http://efod.se/ptt into
this tracker, which also means that if you had a user in that tracker,
you should be able to use it in this tracker.

> Submitting issues via the web doesn't work at the moment due to a
> permission error. This reminded me why we prefer using the roundup
> server - it can run as the roundup user and it saves you the hassle of
> permissions dances with Apache. Mail delivery works fine.

I applied some sysadmin magic to make this work. The trick is to let
the www-data user be member of the roundup group (this was already
done), then make sure the db/files directory and all its subdirectires
have mode u+rwx,g+rwxs,o+rx. 

I've tested both submission via the web and via mail. 

Please let me know if you see any big problems with this setup. 

> As far as responsibilities on the server goes, my feeling is that we can
> all help. It is probably simpler if we (Upfront Systems) look after the
> maintenance and security of the server and the rest of the
> administrators look at roundup. We would like to help with Roundup as
> far as we can though. We can coordinate the effort using a tracker but
> let's spell this out in another thread.

I'm very happy that the roundup won't have to keep the box maintaned
and secure. 

Regarding roundup, I'm sure we can cooperate. The important thing is
that we must coordinate upgrades to make sure they go smooth.

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVZmmrJurFAusidkRArxlAJ48je82YLANAM05wTvXcg8WPIEmBACfV4xM
9eGeBNE1mxZLkTzoafOYhmI=
=zFIx
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sat Nov 11 10:38:08 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 10:38:08 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <45557254.7050900@sympatico.ca> (Stefan Seefeld's message of
	"Sat, 11 Nov 2006 01:48:52 -0500")
References: <1163188484.7826.36.camel@kwaaitjie>
	<45556B4C.6030403@upfrontsystems.co.za>
	<45557254.7050900@sympatico.ca>
Message-ID: <87slgquxvj.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Izak Burger wrote:
>
>> One other thing that isn't clear to me.  With the mod_python example in 
>> the documentation (I added a rewrite rule to redirect to /roundup/) 
>> there is no way to get an index page, ie a list of the hosted trackers. 
>>   The builtin server does this if you have more than one tracker and 
>> don't specify a specific one.  How would you make a mod_python setup do 
>> the same?  Or should we simply use a static index page that needs 
>> updating whenever a new tracker is added?
>
> Yes. While it may be convenient to have some toplevel page display
> all tracker instances served on the given URL, I think we don't really
> want to use this feature. If at some point there are multiple trackers
> served at the same access point, we most certainly want to hand-write
> an index page with helpful information to let users find their way.

I agree. There is also the matter of test trackers - we might have one
or two of them up, without listing them on the frontpage. 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVZoArJurFAusidkRAptOAJ47WhtYj6p4ud/Hutnj0In7ibQ7ywCfVrLU
qwO+cSwKdQXXbeB+jp3DXkE=
=sGw9
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Sat Nov 11 14:46:32 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 08:46:32 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <87wt62uxy1.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se>
Message-ID: <4555D438.60501@sympatico.ca>

Erik Forsberg wrote:
> Roch? Compaan <roche at upfrontsystems.co.za> writes:
> 
>>> Izak has completed the installation of Apache, Postfix and Roundup.
> 
> Excellent!
> 
>>> It is running at http://psf.upfronthosting.co.za/roundup/meta/ and you
>>> should be able to register as a user.
> 
> I took the liberty of importing the data from http://efod.se/ptt into
> this tracker, which also means that if you had a user in that tracker,
> you should be able to use it in this tracker.

I tried to log in, but the tracker refused all the passwords I tried.
Could you please reset my password ? Alternatively, could you store
the admin password on psf.upfronthosting.co.za in a way that I can
read it when logged in via ssh. Then I could reset my password myself.
Thanks !

For the 'real' tracker, I'd suggest we use the anydbm while we still
prototype, so reinitialization is easy. We then need to write a simple
'regenerate' script that reinitializes the tracker such it becomes
immediately useful again. This implies, as I suggested earlier, that
a set of default users be created automatically.
For now there only seems to be a single role 'User'. I think we'll
have to add at least one or two more so we can start talking about
more fine-grained access control (e.g. 'User', 'Developer', 'Coordinator',...)

Also, should we rename 'issue' to something more specific, such as 'bug' ?
This would allow us to add other issue types later on, with distinct
work-flows (I use 'tasks' in some trackers to organize my work, for example).


Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Sat Nov 11 16:13:32 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 16:13:32 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4555D438.60501@sympatico.ca> (Stefan Seefeld's message of "Sat, 
	11 Nov 2006 08:46:32 -0500")
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
Message-ID: <87odreuicj.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Erik Forsberg wrote:
>> Roch? Compaan <roche at upfrontsystems.co.za> writes:
>> 
>>>> Izak has completed the installation of Apache, Postfix and Roundup.
>> 
>> Excellent!
>> 
>>>> It is running at http://psf.upfronthosting.co.za/roundup/meta/ and you
>>>> should be able to register as a user.
>> 
>> I took the liberty of importing the data from http://efod.se/ptt into
>> this tracker, which also means that if you had a user in that tracker,
>> you should be able to use it in this tracker.
>
> I tried to log in, but the tracker refused all the passwords I tried.
> Could you please reset my password ? 

Umm.. why not use the web interface for retrieving your password? 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVeibrJurFAusidkRAuIdAJ495tbaT+kE5+AzMCRJtgw7YepBzgCgiNGY
+bMfElKswPqGTnFsUhBkJjQ=
=6OGc
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Sat Nov 11 17:17:23 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 11:17:23 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <87odreuicj.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>	<87wt62uxy1.fsf@uterus.efod.se>
	<4555D438.60501@sympatico.ca> <87odreuicj.fsf@uterus.efod.se>
Message-ID: <4555F793.8050707@sympatico.ca>

Erik Forsberg wrote:

> Umm.. why not use the web interface for retrieving your password? 

This thought is so strange it never occured to me. Doh ! :-)

So, it turned out I didn't even have an account yet. Thus I started
to register, and received the first mail asking me to either reply
or click on a link. The reply didn't make it, I got this failure
notice:


<issue_tracker at psf.upfronthosting.co.za>:
88.198.142.26 does not like recipient.
Remote host said: 550 5.1.1 <issue_tracker at psf.upfronthosting.co.za>: Recipient address rejected:
User unknown in local recipient table
Giving up on 88.198.142.26.

Should I create an issue for that ? :-)
It appears neither Izak nor Roche are registered yet, so this wouldn't
be of much use.


Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Sat Nov 11 17:41:47 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 11 Nov 2006 18:41:47 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4555F793.8050707@sympatico.ca>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se>  <4555F793.8050707@sympatico.ca>
Message-ID: <1163263308.7826.67.camel@kwaaitjie>

On Sat, 2006-11-11 at 11:17 -0500, Stefan Seefeld wrote:
> Erik Forsberg wrote:
> 
> > Umm.. why not use the web interface for retrieving your password? 
> 
> This thought is so strange it never occured to me. Doh ! :-)
> 
> So, it turned out I didn't even have an account yet. Thus I started
> to register, and received the first mail asking me to either reply
> or click on a link. The reply didn't make it, I got this failure
> notice:
> 
> 
> <issue_tracker at psf.upfronthosting.co.za>:
> 88.198.142.26 does not like recipient.
> Remote host said: 550 5.1.1 <issue_tracker at psf.upfronthosting.co.za>: Recipient address rejected:
> User unknown in local recipient table
> Giving up on 88.198.142.26.
> 
> Should I create an issue for that ? :-)
> It appears neither Izak nor Roche are registered yet, so this wouldn't
> be of much use.

Try now - the address in config.ini didn't match the mail setup. It
should actually be metatracker at psf.upfronthosting.co.za

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Sat Nov 11 17:48:18 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 11:48:18 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163263148.7826.66.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>	
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>	
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie>
Message-ID: <4555FED2.80908@sympatico.ca>

Roch? Compaan wrote:

>> Should I create an issue for that ? :-)
>> It appears neither Izak nor Roche are registered yet, so this wouldn't
>> be of much use.
> 
> Try now - the address in config.ini didn't match the mail setup. It
> should actually be metatracker at psf.upfronthosting.co.za

Thanks ! I can't repeat the registration process, as I'm already
registered. What I did, though, was to create a new issue by
sending mail to the above address. That has worked, sort of.

When looking at the new issue at

http://psf.upfronthosting.co.za/roundup/meta/issue29

I see this:

ERROR reading file: msg47
Possibly a access right configuration problem.
[Errno 13] Permission denied: '/home/roundup/trackers/meta/db/files/msg/0/msg47'

which may be caused by the roundup-mailgw not being invoked by the right user.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Sat Nov 11 18:47:23 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 18:47:23 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4555FED2.80908@sympatico.ca> (Stefan Seefeld's message of "Sat, 
	11 Nov 2006 11:48:18 -0500")
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie> <4555FED2.80908@sympatico.ca>
Message-ID: <87ejs9vpsk.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:


> Thanks ! I can't repeat the registration process, as I'm already
> registered. What I did, though, was to create a new issue by
> sending mail to the above address. That has worked, sort of.
>
> When looking at the new issue at
>
> http://psf.upfronthosting.co.za/roundup/meta/issue29
>
> I see this:
>
> ERROR reading file: msg47
> Possibly a access right configuration problem.
> [Errno 13] Permission denied: '/home/roundup/trackers/meta/db/files/msg/0/msg47'
>
> which may be caused by the roundup-mailgw not being invoked by the right user. 

Hmm.. I wonder why it did work for me when I tested. Anyway, this
reminded me of the fact that I had a small modification in my efod.se
setup, in the form of a os.umask(022) at the top of
roundup-mailgw. This makes it create files with group rw/permissions,
which is needed for the apache to read them.

I've applied this fix to /home/roundup/roundup/bin/roundup-mailgw as
well. I'll see what Richard says about applying this fix in the
roundup CVS as well.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVgyqrJurFAusidkRAhMvAKC+xsZ8cvR1x5hqWA5T0LUem0EaoACgvUOr
uRbdXzExrI/iCwQVVabE1CA=
=x/gy
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Sat Nov 11 18:53:58 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 12:53:58 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <87ejs9vpsk.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>	<87wt62uxy1.fsf@uterus.efod.se>
	<4555D438.60501@sympatico.ca>	<87odreuicj.fsf@uterus.efod.se>
	<4555F793.8050707@sympatico.ca>	<1163263148.7826.66.camel@kwaaitjie>
	<4555FED2.80908@sympatico.ca> <87ejs9vpsk.fsf@uterus.efod.se>
Message-ID: <45560E36.5000309@sympatico.ca>

Erik Forsberg wrote:

> Hmm.. I wonder why it did work for me when I tested. Anyway, this
> reminded me of the fact that I had a small modification in my efod.se
> setup, in the form of a os.umask(022) at the top of
> roundup-mailgw. This makes it create files with group rw/permissions,
> which is needed for the apache to read them.
> 
> I've applied this fix to /home/roundup/roundup/bin/roundup-mailgw as
> well. I'll see what Richard says about applying this fix in the
> roundup CVS as well.

Shouldn't it be enough to let the invoking process (i.e. the MTA) have
the right configuration ?
(http://roundup.sourceforge.net/doc-1.0/installation.html#configure-an-email-interface)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Sat Nov 11 19:39:23 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 11 Nov 2006 20:39:23 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4555FED2.80908@sympatico.ca>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie>  <4555FED2.80908@sympatico.ca>
Message-ID: <1163270364.7826.72.camel@kwaaitjie>

On Sat, 2006-11-11 at 11:48 -0500, Stefan Seefeld wrote:
> Roch? Compaan wrote:
> 
> >> Should I create an issue for that ? :-)
> >> It appears neither Izak nor Roche are registered yet, so this wouldn't
> >> be of much use.
> > 
> > Try now - the address in config.ini didn't match the mail setup. It
> > should actually be metatracker at psf.upfronthosting.co.za
> 
> Thanks ! I can't repeat the registration process, as I'm already
> registered. What I did, though, was to create a new issue by
> sending mail to the above address. That has worked, sort of.
> 
> When looking at the new issue at
> 
> http://psf.upfronthosting.co.za/roundup/meta/issue29
> 
> I see this:
> 
> ERROR reading file: msg47
> Possibly a access right configuration problem.
> [Errno 13] Permission denied: '/home/roundup/trackers/meta/db/files/msg/0/msg47'
> 
> which may be caused by the roundup-mailgw not being invoked by the right user.

It is configured to deliver mail as the roundup user. If the error
appears through the web then it suggests that Apache doesn't have
permission to read the file - it has already been created successfully
by roundup-mailgw.

When I browse do the above URL I do see your message. I'll create
another test issue to see if I can reproduce your permission error.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From roche at upfrontsystems.co.za  Sat Nov 11 19:43:30 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 11 Nov 2006 20:43:30 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163270364.7826.72.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie>  <4555FED2.80908@sympatico.ca>
	<1163270364.7826.72.camel@kwaaitjie>
Message-ID: <1163270610.7826.80.camel@kwaaitjie>

On Sat, 2006-11-11 at 20:39 +0200, Roch? Compaan wrote:
> On Sat, 2006-11-11 at 11:48 -0500, Stefan Seefeld wrote:
> > Roch? Compaan wrote:
> > 
> > >> Should I create an issue for that ? :-)
> > >> It appears neither Izak nor Roche are registered yet, so this wouldn't
> > >> be of much use.
> > > 
> > > Try now - the address in config.ini didn't match the mail setup. It
> > > should actually be metatracker at psf.upfronthosting.co.za
> > 
> > Thanks ! I can't repeat the registration process, as I'm already
> > registered. What I did, though, was to create a new issue by
> > sending mail to the above address. That has worked, sort of.
> > 
> > When looking at the new issue at
> > 
> > http://psf.upfronthosting.co.za/roundup/meta/issue29
> > 
> > I see this:
> > 
> > ERROR reading file: msg47
> > Possibly a access right configuration problem.
> > [Errno 13] Permission denied: '/home/roundup/trackers/meta/db/files/msg/0/msg47'
> > 
> > which may be caused by the roundup-mailgw not being invoked by the right user.
> 
> It is configured to deliver mail as the roundup user. If the error
> appears through the web then it suggests that Apache doesn't have
> permission to read the file - it has already been created successfully
> by roundup-mailgw.
> 
> When I browse do the above URL I do see your message. I'll create
> another test issue to see if I can reproduce your permission error.

Everything works for me - issue creation TTW and via mail as well as
responding to issue TTW and via mail.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Sat Nov 11 19:44:04 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 13:44:04 -0500
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163270364.7826.72.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>	
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>	
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>	
	<1163263148.7826.66.camel@kwaaitjie> <4555FED2.80908@sympatico.ca>
	<1163270364.7826.72.camel@kwaaitjie>
Message-ID: <455619F4.2090908@sympatico.ca>

Roch? Compaan wrote:

> It is configured to deliver mail as the roundup user. If the error
> appears through the web then it suggests that Apache doesn't have
> permission to read the file - it has already been created successfully
> by roundup-mailgw.
> 
> When I browse do the above URL I do see your message. I'll create
> another test issue to see if I can reproduce your permission error.

Well, the problem is gone. Looking again at issue29 now shows the
message text. No idea what changed meanwhile.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Sat Nov 11 19:46:28 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 11 Nov 2006 20:46:28 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <455619F4.2090908@sympatico.ca>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie> <4555FED2.80908@sympatico.ca>
	<1163270364.7826.72.camel@kwaaitjie>  <455619F4.2090908@sympatico.ca>
Message-ID: <1163270789.7826.82.camel@kwaaitjie>

On Sat, 2006-11-11 at 13:44 -0500, Stefan Seefeld wrote:
> Roch? Compaan wrote:
> 
> > It is configured to deliver mail as the roundup user. If the error
> > appears through the web then it suggests that Apache doesn't have
> > permission to read the file - it has already been created successfully
> > by roundup-mailgw.
> > 
> > When I browse do the above URL I do see your message. I'll create
> > another test issue to see if I can reproduce your permission error.
> 
> Well, the problem is gone. Looking again at issue29 now shows the
> message text. No idea what changed meanwhile.

I suspect somebody put Apache (www-data) in the Roundup group. I don't
know who though - hopefully a friendly hacker ;-)

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From roche at upfrontsystems.co.za  Sat Nov 11 20:07:53 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 11 Nov 2006 21:07:53 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <87ejs9vpsk.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie> <4555FED2.80908@sympatico.ca>
	<87ejs9vpsk.fsf@uterus.efod.se>
Message-ID: <1163272074.7826.88.camel@kwaaitjie>

On Sat, 2006-11-11 at 18:47 +0100, Erik Forsberg wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stefan Seefeld <seefeld at sympatico.ca> writes:
> 
> 
> > Thanks ! I can't repeat the registration process, as I'm already
> > registered. What I did, though, was to create a new issue by
> > sending mail to the above address. That has worked, sort of.
> >
> > When looking at the new issue at
> >
> > http://psf.upfronthosting.co.za/roundup/meta/issue29
> >
> > I see this:
> >
> > ERROR reading file: msg47
> > Possibly a access right configuration problem.
> > [Errno 13] Permission denied: '/home/roundup/trackers/meta/db/files/msg/0/msg47'
> >
> > which may be caused by the roundup-mailgw not being invoked by the right user. 
> 
> Hmm.. I wonder why it did work for me when I tested. Anyway, this
> reminded me of the fact that I had a small modification in my efod.se
> setup, in the form of a os.umask(022) at the top of
> roundup-mailgw. This makes it create files with group rw/permissions,
> which is needed for the apache to read them.
> 
> I've applied this fix to /home/roundup/roundup/bin/roundup-mailgw as
> well. I'll see what Richard says about applying this fix in the
> roundup CVS as well.

I remember doing the exact same thing while we were still using cgi.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From forsberg at efod.se  Sat Nov 11 22:11:25 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 22:11:25 +0100
Subject: [Tracker-discuss] 1.3.0 merged into trackers/python-dev
Message-ID: <87zmaxu1s2.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo!

I've now merged the template changes between 1.2.1 and 1.3.0 into
trackers/python-dev.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVjx9rJurFAusidkRAhvUAKCM2aKPKhBgAWMsk3JlNjwRjZRb2ACgheB4
JTQSV2gc82gD6T8FSbiXA1M=
=v95Z
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sat Nov 11 22:41:48 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 22:41:48 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <45556B4C.6030403@upfrontsystems.co.za> (Izak Burger's message of
	"Sat, 11 Nov 2006 08:18:52 +0200")
References: <1163188484.7826.36.camel@kwaaitjie>
	<45556B4C.6030403@upfrontsystems.co.za>
Message-ID: <877iy1u0df.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Izak Burger <izak at upfrontsystems.co.za> writes:

>> Submitting issues via the web doesn't work at the moment due to a
>> permission error. This reminded me why we prefer using the roundup
>> server - it can run as the roundup user and it saves you the hassle of
>> permissions dances with Apache. Mail delivery works fine.
>
> I'm thinking of this: http://httpd.apache.org/docs/2.0/mod/perchild.html

"This module is not functional. Development of this module is not
complete and is not currently active. Do not use perchild unless you
are a programmer willing to help fix it."

Are you a programmer willing to help fix it? :-)

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVkObrJurFAusidkRAtv7AJ9dl3j5DwG4u8pXWbTOM5TUMlnczACgycp0
F00pOt54qtAv5G9fRcIUBPc=
=tJiR
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sat Nov 11 22:50:54 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 11 Nov 2006 22:50:54 +0100
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <f74a6c2f0611091346o36db63dg98052a3a97aec809@mail.gmail.com>
	(Paul Dubois's message of "Thu, 9 Nov 2006 13:46:46 -0800")
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>
	<45539678.3030409@sympatico.ca>
	<f74a6c2f0611091346o36db63dg98052a3a97aec809@mail.gmail.com>
Message-ID: <873b8ptzy9.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Paul Dubois" <pfdubois at gmail.com> writes:

> I apparently was not clear. I'm not suggesting some sort of fancy mechanism
> to manage the triage list inside Roundup. (Triage list being my term for the
> set of people who get notified of new issues.)
>
> Obviously, the triage list can just be a normal mailing list; and the
> suggestion that we have two, one for 'new issues' and one for 'everything',
> is fine too. I can't believe anybody wants to read every message about every
> issue, even if in digest form, but there is no problem sending it if that is
> what they want.
>
> Again, I'm just saying that nosy lists are Roundup's most powerful and
> effective feature, and I believe that most people who get used to nosy lists
> are not going to want to be on the 'everything' list any more. When we
> present the tracker to the community we will want to make clear the new mode
> of operation that nosy lists make possible.


One idea that came to my mind is to extend the user class to include a
Multilink to keyword containing the list of keywords where the user
wants to be automatically added to the nosy list whenever new issues
are created (or when keywords are added to existing issues).

A detector could then be created to do the rest of the work. 

This would could form an alternative to the python-bugs and the
python-new-bugs mailing lists for people that only want information
about specific areas. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFVkW9rJurFAusidkRAulJAJ0Rn9bbiNM3A4gkJ9Jqln7FOUMDfwCbBvrZ
Yr0jASM7HZqQweJrWLyZ2Zo=
=vgWr
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Sat Nov 11 22:55:36 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 11 Nov 2006 16:55:36 -0500
Subject: [Tracker-discuss] triage and other matters
In-Reply-To: <873b8ptzy9.fsf@uterus.efod.se>
References: <f74a6c2f0611082231q7df063c8nfbe78c0bc91be5dc@mail.gmail.com>	<45539678.3030409@sympatico.ca>	<f74a6c2f0611091346o36db63dg98052a3a97aec809@mail.gmail.com>
	<873b8ptzy9.fsf@uterus.efod.se>
Message-ID: <455646D8.7020902@sympatico.ca>

Erik Forsberg wrote:

> One idea that came to my mind is to extend the user class to include a
> Multilink to keyword containing the list of keywords where the user
> wants to be automatically added to the nosy list whenever new issues
> are created (or when keywords are added to existing issues).
> 
> A detector could then be created to do the rest of the work. 
> 
> This would could form an alternative to the python-bugs and the
> python-new-bugs mailing lists for people that only want information
> about specific areas. 

Exactly. This may go beyond keywords, i.e. depending on the schema
we end up with, there will be other issue attributes that may make
it interesting to a user.

I'm using this approach on some of my trackers.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From izak at upfrontsystems.co.za  Sun Nov 12 08:44:03 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sun, 12 Nov 2006 09:44:03 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163272074.7826.88.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>	<87wt62uxy1.fsf@uterus.efod.se>
	<4555D438.60501@sympatico.ca>	<87odreuicj.fsf@uterus.efod.se>
	<4555F793.8050707@sympatico.ca>	<1163263148.7826.66.camel@kwaaitjie>
	<4555FED2.80908@sympatico.ca>	<87ejs9vpsk.fsf@uterus.efod.se>
	<1163272074.7826.88.camel@kwaaitjie>
Message-ID: <4556D0C3.7010109@upfrontsystems.co.za>

Hi guys,

Actually Roche jumped the gun a bit by saying that the tracker was 
"ready".  It was my first mod-python/apache setup and I wanted to get 
that right first, which means I did the minimum (literally only entered 
values for settings that had NO DEFAULT) to get the tracker working with 
the intention of fixing it later.  This is why the email address was 
wrong for example.

I've been a bit busy over the weekend though.  Had some family over and 
there was the usual weekly shopping and things like that.

I apologise if I could not always respond in a timely fashion (or at 
all).  It seems you guys got it sorted though.  I promise to look at any 
outstanding issues on Monday.

regards,
Izak

From izak at upfrontsystems.co.za  Sun Nov 12 08:47:57 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sun, 12 Nov 2006 09:47:57 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <877iy1u0df.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>	<45556B4C.6030403@upfrontsystems.co.za>
	<877iy1u0df.fsf@uterus.efod.se>
Message-ID: <4556D1AD.6020708@upfrontsystems.co.za>

Erik Forsberg wrote:
> "This module is not functional. Development of this module is not
> complete and is not currently active. Do not use perchild unless you
> are a programmer willing to help fix it."
> 
> Are you a programmer willing to help fix it? :-)

Silly me.  I admit I did not actually read the whole thing.  Rule of 
thumb, if something is just too useful/easy it is probably broken or 
incomplete (or non existant).

From roche at upfrontsystems.co.za  Sun Nov 12 10:23:00 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sun, 12 Nov 2006 11:23:00 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4556D0C3.7010109@upfrontsystems.co.za>
References: <1163188484.7826.36.camel@kwaaitjie>
	<87wt62uxy1.fsf@uterus.efod.se> <4555D438.60501@sympatico.ca>
	<87odreuicj.fsf@uterus.efod.se> <4555F793.8050707@sympatico.ca>
	<1163263148.7826.66.camel@kwaaitjie> <4555FED2.80908@sympatico.ca>
	<87ejs9vpsk.fsf@uterus.efod.se> <1163272074.7826.88.camel@kwaaitjie>
	<4556D0C3.7010109@upfrontsystems.co.za>
Message-ID: <1163323381.7826.102.camel@kwaaitjie>

On Sun, 2006-11-12 at 09:44 +0200, Izak Burger wrote:
> Hi guys,
> 
> Actually Roche jumped the gun a bit by saying that the tracker was 
> "ready".  It was my first mod-python/apache setup and I wanted to get 
> that right first, which means I did the minimum (literally only entered 
> values for settings that had NO DEFAULT) to get the tracker working with 
> the intention of fixing it later.  This is why the email address was 
> wrong for example.
> 
> I've been a bit busy over the weekend though.  Had some family over and 
> there was the usual weekly shopping and things like that.
> 
> I apologise if I could not always respond in a timely fashion (or at 
> all).  It seems you guys got it sorted though.  I promise to look at any 
> outstanding issues on Monday.

Sorry for jumping the gun Izak, I was just eager to get things ready.
And I knew there were other volunteer sysadmins that would help us look
after Roundup on this server.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From roche at upfrontsystems.co.za  Sun Nov 12 10:25:00 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sun, 12 Nov 2006 11:25:00 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <4556D1AD.6020708@upfrontsystems.co.za>
References: <1163188484.7826.36.camel@kwaaitjie>
	<45556B4C.6030403@upfrontsystems.co.za> <877iy1u0df.fsf@uterus.efod.se>
	<4556D1AD.6020708@upfrontsystems.co.za>
Message-ID: <1163323500.7826.104.camel@kwaaitjie>

On Sun, 2006-11-12 at 09:47 +0200, Izak Burger wrote:
> Erik Forsberg wrote:
> > "This module is not functional. Development of this module is not
> > complete and is not currently active. Do not use perchild unless you
> > are a programmer willing to help fix it."
> > 
> > Are you a programmer willing to help fix it? :-)
> 
> Silly me.  I admit I did not actually read the whole thing.  Rule of 
> thumb, if something is just too useful/easy it is probably broken or 
> incomplete (or non existant).

Mmm, that's how it should be to be stable - it should be usable and
easy :-)

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From forsberg at efod.se  Sun Nov 12 21:17:44 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 12 Nov 2006 21:17:44 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
Message-ID: <877iy0s9lj.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo!

I've been doing some work on the sourceforge screenscraper, originally
created by Fredrik Lundh. I've reworked it a bit to make it easier for
it to cope with tracker items moving between trackers. I've also made
it more robust against sourceforge's hit limits etc. Will commit this
work later this week.

I've also subscribed roundup+trackerupdate (at)
psf.upfronthosting.co.za to the python-bugs and the patches
mailinglist. Mail from both these lists now end up in a Maildir under
~roundup/auto-tracker-update/. My intent is to create a script that
polls this maildir and then automatically updates our copy of the
sourceforge data, as well as our tracker, each time there's an action
to any of the python-related tracker items at sourceforge.

Btw, is there a list for RFEs as well? 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFV4FnrJurFAusidkRAgbMAJ4sk5lokHkeU2u6RA8JbRxT1t9a0QCgu/gk
AZqfXxXgRGm+v0t3xYyzZkM=
=THyv
-----END PGP SIGNATURE-----

From brett at python.org  Sun Nov 12 22:31:32 2006
From: brett at python.org (Brett Cannon)
Date: Sun, 12 Nov 2006 13:31:32 -0800
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <877iy0s9lj.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
Message-ID: <bbaeab100611121331v1f562410xc5395438b4fe1af3@mail.gmail.com>

On 11/12/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yo!
>
> I've been doing some work on the sourceforge screenscraper, originally
> created by Fredrik Lundh. I've reworked it a bit to make it easier for
> it to cope with tracker items moving between trackers. I've also made
> it more robust against sourceforge's hit limits etc. Will commit this
> work later this week.
>
> I've also subscribed roundup+trackerupdate (at)
> psf.upfronthosting.co.za to the python-bugs and the patches
> mailinglist. Mail from both these lists now end up in a Maildir under
> ~roundup/auto-tracker-update/. My intent is to create a script that
> polls this maildir and then automatically updates our copy of the
> sourceforge data, as well as our tracker, each time there's an action
> to any of the python-related tracker items at sourceforge.
>
> Btw, is there a list for RFEs as well?


Feature requests go to the bugs list.

-Brett



Cheers,
> \EF
> - --
> Erik Forsberg                 http://efod.se
> GPG/PGP Key: 1024D/0BAC89D9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/
> >
>
> iD8DBQFFV4FnrJurFAusidkRAgbMAJ4sk5lokHkeU2u6RA8JbRxT1t9a0QCgu/gk
> AZqfXxXgRGm+v0t3xYyzZkM=
> =THyv
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061112/d03a1642/attachment.html 

From izak at upfrontsystems.co.za  Sun Nov 12 22:36:09 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sun, 12 Nov 2006 23:36:09 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <1163323500.7826.104.camel@kwaaitjie>
References: <1163188484.7826.36.camel@kwaaitjie>	
	<45556B4C.6030403@upfrontsystems.co.za>
	<877iy1u0df.fsf@uterus.efod.se>	
	<4556D1AD.6020708@upfrontsystems.co.za>
	<1163323500.7826.104.camel@kwaaitjie>
Message-ID: <455793C9.2040606@upfrontsystems.co.za>

Hi all,

A bit more research eventually showed that not only is perchild 
experimental and sometimes non-functional, it was also removed from 
apache2.2.  Several other solutions have been written by others, for 
example:

http://home.samfundet.no/~sesse/mpm-itk/
http://mpm.metux.de/index.php/Main_Page
http://www.telana.com/peruser.php

Two of them keeps a pool of apache processes running under each uid, and 
the other runs as root for as long as it can before dropping privileges 
to the right user.  Each has some problems of it's own.

So I thought a bit more about the idea of keeping a seperate pool of 
processes running under the right uid.  This led me to the idea of 
running a second apache under the roundup uid (that implements the 
separate "pool of processes") and let the frontend apache pass queries 
to it.  Then I figured, if I do that I might as well use roundup-server.

I've changed the configuration now to run roundup-server, with apache in 
front of it.  Apache will serve all static content, and pass the rest to 
roundup-server.  The idea is that we let apache do what it is good(and 
fast) at.

If there is some advantage to be had from rather using mod-python, it 
will be an easy swap.  I already have the config sorted (in 
/home/roundup/apache/apache2.conf).

regards,
Izak

From martin at v.loewis.de  Sun Nov 12 22:41:59 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 12 Nov 2006 22:41:59 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <877iy0s9lj.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
Message-ID: <45579527.2090209@v.loewis.de>

Erik Forsberg schrieb:
> I've also subscribed roundup+trackerupdate (at)
> psf.upfronthosting.co.za to the python-bugs and the patches
> mailinglist. Mail from both these lists now end up in a Maildir under
> ~roundup/auto-tracker-update/. My intent is to create a script that
> polls this maildir and then automatically updates our copy of the
> sourceforge data, as well as our tracker, each time there's an action
> to any of the python-related tracker items at sourceforge.

That might be useful while still dealing with the setup. For
the actual conversion, I'd rather propose to perform a tracker freeze.
There is an option "hide this tracker", and we can put a message
on top of the "submit new" page, although I don't see a way to make
the tracker fully read-only. Conversion during the freeze could then
start from scratch.

Doing so is IMO necessary as SF won't send email on all changes
(e.g. attaching a new file won't cause a message to be sent).

> Btw, is there a list for RFEs as well? 

Changes to that tracker will get sent to python-bugs-list also.

Regards,
Martin

From barry at python.org  Sun Nov 12 22:47:14 2006
From: barry at python.org (Barry Warsaw)
Date: Sun, 12 Nov 2006 16:47:14 -0500
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <877iy0s9lj.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
Message-ID: <46AD89EB-6C63-4DE0-94F8-D01F4CC3D449@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 12, 2006, at 3:17 PM, Erik Forsberg wrote:

> I've been doing some work on the sourceforge screenscraper, originally
> created by Fredrik Lundh. I've reworked it a bit to make it easier for
> it to cope with tracker items moving between trackers. I've also made
> it more robust against sourceforge's hit limits etc. Will commit this
> work later this week.

Any chance you can post your changes or get Fredrik to commit them to  
his svn?  I took your patch, and it helped but I'm still getting  
tracebacks trying to create the tracker xml.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRVeWZ3EjvBPtnXfVAQJ5yQP+KR2DEQRXBS8djsMfsO54Os4MVDkU1Wr/
tNphXz9p+hZiuJ9mQt2CdcQkWozvguBJhpZk1ezXcTrQFFVccGPLhVPGpCU99Jq0
AEoVlcfVP0YowuPEq/TbViU18BGfuc0+y8zrA3JaBB/2VCNZo7vecK5QWwnVfehu
EPCHHEEO1y0=
=sHKx
-----END PGP SIGNATURE-----

From brett at python.org  Mon Nov 13 01:05:58 2006
From: brett at python.org (Brett Cannon)
Date: Sun, 12 Nov 2006 16:05:58 -0800
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <45579527.2090209@v.loewis.de>
References: <877iy0s9lj.fsf@uterus.efod.se> <45579527.2090209@v.loewis.de>
Message-ID: <bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>

On 11/12/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Erik Forsberg schrieb:
> > I've also subscribed roundup+trackerupdate (at)
> > psf.upfronthosting.co.za to the python-bugs and the patches
> > mailinglist. Mail from both these lists now end up in a Maildir under
> > ~roundup/auto-tracker-update/. My intent is to create a script that
> > polls this maildir and then automatically updates our copy of the
> > sourceforge data, as well as our tracker, each time there's an action
> > to any of the python-related tracker items at sourceforge.
>
> That might be useful while still dealing with the setup. For
> the actual conversion, I'd rather propose to perform a tracker freeze.
> There is an option "hide this tracker", and we can put a message
> on top of the "submit new" page, although I don't see a way to make
> the tracker fully read-only. Conversion during the freeze could then
> start from scratch.
>
> Doing so is IMO necessary as SF won't send email on all changes
> (e.g. attaching a new file won't cause a message to be sent).


I agree.  This is what I always figured we would do in the end.

-Brett

> Btw, is there a list for RFEs as well?
>
> Changes to that tracker will get sent to python-bugs-list also.
>
> Regards,
> Martin
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061112/64afa64f/attachment.html 

From seefeld at sympatico.ca  Mon Nov 13 01:47:06 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 12 Nov 2006 19:47:06 -0500
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>
References: <877iy0s9lj.fsf@uterus.efod.se> <45579527.2090209@v.loewis.de>
	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>
Message-ID: <4557C08A.4010600@sympatico.ca>

Brett Cannon wrote:
> 
> 
> On 11/12/06, *"Martin v. L?wis"* <martin at v.loewis.de

>     That might be useful while still dealing with the setup. For
>     the actual conversion, I'd rather propose to perform a tracker freeze.
>     There is an option "hide this tracker", and we can put a message
>     on top of the "submit new" page, although I don't see a way to make
>     the tracker fully read-only. Conversion during the freeze could then
>     start from scratch.
> 
>     Doing so is IMO necessary as SF won't send email on all changes
>     (e.g. attaching a new file won't cause a message to be sent).
> 
> 
> I agree.  This is what I always figured we would do in the end.

And, I don't think it is that useful to always use a tracker filled with
real data while working on the schema / templates / et al., since I'd expect
us re-initializing the tracker rather often. Having only a handful of
(dummy) issues makes more sense.

Only once we are converging towards the final tracker should we start
importing the real data. Thus, having a single run of the transfer script
should be enough.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Mon Nov 13 07:10:36 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 13 Nov 2006 07:10:36 +0100
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <455793C9.2040606@upfrontsystems.co.za> (Izak Burger's message of
	"Sun, 12 Nov 2006 23:36:09 +0200")
References: <1163188484.7826.36.camel@kwaaitjie>
	<45556B4C.6030403@upfrontsystems.co.za>
	<877iy1u0df.fsf@uterus.efod.se>
	<4556D1AD.6020708@upfrontsystems.co.za>
	<1163323500.7826.104.camel@kwaaitjie>
	<455793C9.2040606@upfrontsystems.co.za>
Message-ID: <873b8nswpv.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Izak Burger <izak at upfrontsystems.co.za> writes:

> Hi all,
>
> A bit more research eventually showed that not only is perchild 
> experimental and sometimes non-functional, it was also removed from 
> apache2.2.  Several other solutions have been written by others, for 
> example:
>
> http://home.samfundet.no/~sesse/mpm-itk/
> http://mpm.metux.de/index.php/Main_Page
> http://www.telana.com/peruser.php
>
> Two of them keeps a pool of apache processes running under each uid, and 
> the other runs as root for as long as it can before dropping privileges 
> to the right user.  Each has some problems of it's own.
>
> So I thought a bit more about the idea of keeping a seperate pool of 
> processes running under the right uid.  This led me to the idea of 
> running a second apache under the roundup uid (that implements the 
> separate "pool of processes") and let the frontend apache pass queries 
> to it.  Then I figured, if I do that I might as well use roundup-server.
>
> I've changed the configuration now to run roundup-server, with apache in 
> front of it.  Apache will serve all static content, and pass the rest to 
> roundup-server.  The idea is that we let apache do what it is good(and 
> fast) at.

I don't quite see why this was necessary? What was so wrong with the
mod_python approach that it needed change? 

The people on the roundup-users mailing list all seems to agree that
the mod_python frontend is the one with the best performance. It also
has the advantage of keeping the list of processes that need
monitoring at a minimum.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWAxcrJurFAusidkRAqOWAJ9ifPkpoDWsI5HgDH/bXJ+yW0kFWgCgjL/J
kMplN72I1Kuby8AW1xfDqDA=
=OJPI
-----END PGP SIGNATURE-----

From forsberg at efod.se  Mon Nov 13 07:16:12 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 13 Nov 2006 07:16:12 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <45579527.2090209@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 12 Nov 2006 22:41:59 +0100")
References: <877iy0s9lj.fsf@uterus.efod.se> <45579527.2090209@v.loewis.de>
Message-ID: <87veljrhw3.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Erik Forsberg schrieb:
>> I've also subscribed roundup+trackerupdate (at)
>> psf.upfronthosting.co.za to the python-bugs and the patches
>> mailinglist. Mail from both these lists now end up in a Maildir under
>> ~roundup/auto-tracker-update/. My intent is to create a script that
>> polls this maildir and then automatically updates our copy of the
>> sourceforge data, as well as our tracker, each time there's an action
>> to any of the python-related tracker items at sourceforge.
>
> That might be useful while still dealing with the setup. For
> the actual conversion, I'd rather propose to perform a tracker freeze.
> There is an option "hide this tracker", and we can put a message
> on top of the "submit new" page, although I don't see a way to make
> the tracker fully read-only. Conversion during the freeze could then
> start from scratch.

Another idea I had on the tracker conversion was to let the importer
mark each issue as closed on sourceforge, with a remark about the
issue being moved to <url for new tracker>, and do this incrementally
for each issue as it's finally moved to the new tracker.

> Doing so is IMO necessary as SF won't send email on all changes
> (e.g. attaching a new file won't cause a message to be sent).

Too bad. Makes my "fetch data incrementally" idea less good :-).

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWA2srJurFAusidkRAs4CAJ9TqXGrjm9uaYD/Mii+5iKvdKEYZgCfbdLI
T24i4/vKK+rsumVwrGfF4ZY=
=FeZY
-----END PGP SIGNATURE-----

From forsberg at efod.se  Mon Nov 13 07:27:03 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 13 Nov 2006 07:27:03 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <4557C08A.4010600@sympatico.ca> (Stefan Seefeld's message of
	"Sun, 12 Nov 2006 19:47:06 -0500")
References: <877iy0s9lj.fsf@uterus.efod.se> <45579527.2090209@v.loewis.de>
	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>
	<4557C08A.4010600@sympatico.ca>
Message-ID: <87r6w7rhe0.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> And, I don't think it is that useful to always use a tracker filled with
> real data while working on the schema / templates / et al., since I'd expect
> us re-initializing the tracker rather often. Having only a handful of
> (dummy) issues makes more sense.

On the other hand, using real data as often as possible makes sure we
find as many importer bugs as possible, and also forces us to keep the
importer up to date with any changes (layout-wise etc.) at sourceforge
so that we don't find out in the very last moment that we can't import
data. 

> Only once we are converging towards the final tracker should we start
> importing the real data. Thus, having a single run of the transfer script
> should be enough.

Just for your knowledge, "a single run of the transfer script" takes
many hours and is, due to the instability of sourceforge, a very
error-prone project. Not to mention that sourceforge block me for half
an hour once in a while for fetching too much data. 

Also, let's make it clear that this is a process in two steps:

1) Fetch all data from sourceforge into a set of XML files locally.
2) Import into roundup.

I would be much more comfortable if we had a process where step 1) is
always kept in sync with sourceforge. This would keep us much less
dependent on sourceforge being up and working at the time for the
final conversion.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWBA2rJurFAusidkRAlXkAKDgD0ZRFF6dh+vp0mwmsjkSOa5AywCghjhO
BeUWnP8bfZ0JtwCgjO/+BjA=
=dRHI
-----END PGP SIGNATURE-----

From forsberg at efod.se  Mon Nov 13 07:33:00 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 13 Nov 2006 07:33:00 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <46AD89EB-6C63-4DE0-94F8-D01F4CC3D449@python.org> (Barry Warsaw's
	message of "Sun, 12 Nov 2006 16:47:14 -0500")
References: <877iy0s9lj.fsf@uterus.efod.se>
	<46AD89EB-6C63-4DE0-94F8-D01F4CC3D449@python.org>
Message-ID: <87mz6vrh43.fsf@uterus.efod.se>

An embedded and charset-unspecified text was scrubbed...
Name: sourceforge.diff
Url: http://mail.python.org/pipermail/tracker-discuss/attachments/20061113/3cd48333/attachment.diff 

From martin at v.loewis.de  Mon Nov 13 07:56:48 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 13 Nov 2006 07:56:48 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <87veljrhw3.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se> <45579527.2090209@v.loewis.de>
	<87veljrhw3.fsf@uterus.efod.se>
Message-ID: <45581730.4090204@v.loewis.de>

Erik Forsberg schrieb:
> Another idea I had on the tracker conversion was to let the importer
> mark each issue as closed on sourceforge, with a remark about the
> issue being moved to <url for new tracker>, and do this incrementally
> for each issue as it's finally moved to the new tracker.

I also considered that. There is one downside, though: SF will send
a message to the submitters and all on the SF "nosy" lists about these
changes; this could amount to spam. Python-dev people will get hundreds
of such messages, the original submitters will sometimes see this as
the first reaction so far.

So at a maximum, we should do so for open issues only, and only after
python-dev has agreed to such a procedure.

Regards,
Martin

From martin at v.loewis.de  Mon Nov 13 08:04:29 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 13 Nov 2006 08:04:29 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <87r6w7rhe0.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
	<45579527.2090209@v.loewis.de>	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>	<4557C08A.4010600@sympatico.ca>
	<87r6w7rhe0.fsf@uterus.efod.se>
Message-ID: <455818FD.9060806@v.loewis.de>

Erik Forsberg schrieb:
> On the other hand, using real data as often as possible makes sure we
> find as many importer bugs as possible, and also forces us to keep the
> importer up to date with any changes (layout-wise etc.) at sourceforge
> so that we don't find out in the very last moment that we can't import
> data. 

I also think we should have real data online before the actual switch
is made. People should be able to look at it and make comments before
it goes life. The length of such a "sunrise" period is debatable; I
think two weeks should be sufficient (or even less).

Keeping these data up-to-date in an ongoing manner is not important,
IMO.

> Just for your knowledge, "a single run of the transfer script" takes
> many hours and is, due to the instability of sourceforge, a very
> error-prone project. Not to mention that sourceforge block me for half
> an hour once in a while for fetching too much data. 

Yes, we can't do that too often (and yes, I understand it is tedious
for whoever is doing it). If it means that the tracker is frozen for
two or three days: that's fine. If then something is lost because
people were posting messages even though it was frozen: that's fine
as well.

> I would be much more comfortable if we had a process where step 1) is
> always kept in sync with sourceforge. This would keep us much less
> dependent on sourceforge being up and working at the time for the
> final conversion.

Don't worry about it too much. If we can blame SF, that's fine. People
understand that such problems are the primary rationale for this project
in the first place.

If you find after day one of the conversion that SF just won't give
you the data, we lift the freeze and wait a week to try again.

Regards,
Martin

From izak at upfrontsystems.co.za  Mon Nov 13 08:21:06 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Mon, 13 Nov 2006 09:21:06 +0200
Subject: [Tracker-discuss] Roundup installed
In-Reply-To: <873b8nswpv.fsf@uterus.efod.se>
References: <1163188484.7826.36.camel@kwaaitjie>	<45556B4C.6030403@upfrontsystems.co.za>	<877iy1u0df.fsf@uterus.efod.se>	<4556D1AD.6020708@upfrontsystems.co.za>	<1163323500.7826.104.camel@kwaaitjie>	<455793C9.2040606@upfrontsystems.co.za>
	<873b8nswpv.fsf@uterus.efod.se>
Message-ID: <45581CE2.6030403@upfrontsystems.co.za>

Erik Forsberg wrote:
> I don't quite see why this was necessary? What was so wrong with the
> mod_python approach that it needed change? 

Roch? and I thought it would be cleaner, it would avoid all this 
umask/setgid trickery we are currently using.  We discussed it again 
this morning and would appear that our uneasiness with this setup stems 
from previous experiences with hosting multiple virtual hosts (belonging 
to different people) on the same machine.  Specifically, any other 
application you run under apache on this machine will have write access 
to roundup files.  At the moment there isn't any, so it is not really a 
problem.  We therefore decided to leave it as is for the moment (that 
is, to use mod-python) and (if necessary) revisit this decision if 
another application ever needs running through this apache instance.

regards,
Izak

From g.brandl at gmx.net  Mon Nov 13 09:03:11 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 13 Nov 2006 09:03:11 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <45581730.4090204@v.loewis.de>
References: <877iy0s9lj.fsf@uterus.efod.se>
	<45579527.2090209@v.loewis.de>	<87veljrhw3.fsf@uterus.efod.se>
	<45581730.4090204@v.loewis.de>
Message-ID: <455826BF.2030400@gmx.net>

Martin v. L?wis wrote:
> Erik Forsberg schrieb:
>> Another idea I had on the tracker conversion was to let the importer
>> mark each issue as closed on sourceforge, with a remark about the
>> issue being moved to <url for new tracker>, and do this incrementally
>> for each issue as it's finally moved to the new tracker.
> 
> I also considered that. There is one downside, though: SF will send
> a message to the submitters and all on the SF "nosy" lists about these
> changes; this could amount to spam. Python-dev people will get hundreds
> of such messages, the original submitters will sometimes see this as
> the first reaction so far.
> 
> So at a maximum, we should do so for open issues only, and only after
> python-dev has agreed to such a procedure.

Isn't there any possibility to completely turn off email notifications for
the tracker system?

Georg

From g.brandl at gmx.net  Mon Nov 13 09:04:59 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 13 Nov 2006 09:04:59 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <455818FD.9060806@v.loewis.de>
References: <877iy0s9lj.fsf@uterus.efod.se>	<45579527.2090209@v.loewis.de>	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>	<4557C08A.4010600@sympatico.ca>	<87r6w7rhe0.fsf@uterus.efod.se>
	<455818FD.9060806@v.loewis.de>
Message-ID: <4558272B.9030809@gmx.net>

Martin v. L?wis wrote:
> Erik Forsberg schrieb:
>> On the other hand, using real data as often as possible makes sure we
>> find as many importer bugs as possible, and also forces us to keep the
>> importer up to date with any changes (layout-wise etc.) at sourceforge
>> so that we don't find out in the very last moment that we can't import
>> data. 
> 
> I also think we should have real data online before the actual switch
> is made. People should be able to look at it and make comments before
> it goes life. The length of such a "sunrise" period is debatable; I
> think two weeks should be sufficient (or even less).


This is a good idea. For example, at one time I noticed that in the
imported comments, there were still these blocks of

Date: 2006-11-12 22:00
Sender: whoever
Logged In: YES
user_id=xyzabc

visisble, though the relevant information (sender name, date) also appear
as properties of the comment.

Georg

From seefeld at sympatico.ca  Mon Nov 13 14:30:05 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Nov 2006 08:30:05 -0500
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <87r6w7rhe0.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
	<45579527.2090209@v.loewis.de>	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>	<4557C08A.4010600@sympatico.ca>
	<87r6w7rhe0.fsf@uterus.efod.se>
Message-ID: <4558735D.6090007@sympatico.ca>

Erik Forsberg wrote:
> Stefan Seefeld <seefeld at sympatico.ca> writes:
> 
>>> And, I don't think it is that useful to always use a tracker filled with
>>> real data while working on the schema / templates / et al., since I'd expect
>>> us re-initializing the tracker rather often. Having only a handful of
>>> (dummy) issues makes more sense.
> 
> On the other hand, using real data as often as possible makes sure we
> find as many importer bugs as possible, and also forces us to keep the
> importer up to date with any changes (layout-wise etc.) at sourceforge
> so that we don't find out in the very last moment that we can't import
> data. 

Fair enough. I didn't mean to imply that the data transfer wouldn't need to
be checked / debugged, just that our early work on the tracker schema and templates
doesn't need any real data, and that using a clone of the sf.net tracker would
slow down the work rather than help.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Mon Nov 13 16:40:32 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Nov 2006 10:40:32 -0500
Subject: [Tracker-discuss] schema ideas
Message-ID: <455891F0.2050209@sympatico.ca>

I'm looking at the current schema, and I have several related
questions / suggestions.

First, I'd like to suggest that we generate some clickable schema
diagram as part of the tracker help that will assist users to
find their way around the tracker.
(I once contributed a script that generates diagrams from a
roundup schema automatically, but looking at the result I find
it rather useless. I attach the generated diagram for the current
schema anyways...)

What I have in mind is something like what I used in the (now mostly
defunct) Fresco tracker: http://issues.fresco.org/reports/schema.html
This schema could pop up in a help window. It lets you click on individual
items, displaying the available values for each property, with short
descriptions.

What this display does not capture is the life-cycle of an issue, for
example, what status changes are expected / possible. These things
are captured by roundup's detectors, and thus can't easily be extracted
automatically. Yet I believe it would be very valuable to have that
captured in a diagram, too.

Now for some actual points related to the schema:

* I'd like to rename 'issue' to 'bug' to make room for other issue
  types in the future.

* I'd like to add a 'severity'. A severity reflects the impact this
  issue has on the user. The 'priority' is a ranking to be done by
  developers, not users, and should be read-only for users.

* Speaking of which, I'd like to know whether it wouldn't be meaningful
  to introduce a 'Developer' role. I'm not familiar enough with python's
  development model, but I'd expect it to allow the distinction between
  'user' and 'developer'. For example, bugs can only be assigned to
  developers, and certain changes can only be made by developers.


As soon as we are ready to instantiate the 'real' tracker, I'd like
to adjust the schema accordingly, add some default initialization data
to initial_data.py, and start working on the help system. That will help
us understand the tracker schema and behavior better while we discuss
subsequent changes.

Comments ?

Regards,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schema.svg
Type: image/svg+xml
Size: 23099 bytes
Desc: not available
Url : http://mail.python.org/pipermail/tracker-discuss/attachments/20061113/1956173d/attachment-0001.svg 

From seefeld at sympatico.ca  Mon Nov 13 19:43:46 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Nov 2006 13:43:46 -0500
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <87r6w7rhe0.fsf@uterus.efod.se>
References: <877iy0s9lj.fsf@uterus.efod.se>
	<45579527.2090209@v.loewis.de>	<bbaeab100611121605l56e290f5ne03739b924609ff9@mail.gmail.com>	<4557C08A.4010600@sympatico.ca>
	<87r6w7rhe0.fsf@uterus.efod.se>
Message-ID: <4558BCE2.7080305@sympatico.ca>

Erik Forsberg wrote:

> On the other hand, using real data as often as possible makes sure we
> find as many importer bugs as possible, and also forces us to keep the
> importer up to date with any changes (layout-wise etc.) at sourceforge
> so that we don't find out in the very last moment that we can't import
> data. 

Speaking of 'real data': Could you separate the translation of
issues from the translation of other data such as the possible
values (enumerators) for 'group', 'category', 'status', 'priority', etc. ?

The latter don't seem to change as frequently as the issues themselves (if
at all), and thus could already be coded into the new tracker (possibly
by means of initial_data.py). They are in a sense more part of the schema
than they are part of the actual tracker content. Also: any detectors
we will write will depend on them, so it's important to have them available
independently from the issues.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Mon Nov 13 21:38:46 2006
From: brett at python.org (Brett Cannon)
Date: Mon, 13 Nov 2006 12:38:46 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455891F0.2050209@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>
Message-ID: <bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>

On 11/13/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> I'm looking at the current schema, and I have several related
> questions / suggestions.
>
> First, I'd like to suggest that we generate some clickable schema
> diagram as part of the tracker help that will assist users to
> find their way around the tracker.
> (I once contributed a script that generates diagrams from a
> roundup schema automatically, but looking at the result I find
> it rather useless. I attach the generated diagram for the current
> schema anyways...)
>
> What I have in mind is something like what I used in the (now mostly
> defunct) Fresco tracker: http://issues.fresco.org/reports/schema.html
> This schema could pop up in a help window. It lets you click on individual
> items, displaying the available values for each property, with short
> descriptions.
>
> What this display does not capture is the life-cycle of an issue, for
> example, what status changes are expected / possible. These things
> are captured by roundup's detectors, and thus can't easily be extracted
> automatically. Yet I believe it would be very valuable to have that
> captured in a diagram, too.
>
> Now for some actual points related to the schema:
>
> * I'd like to rename 'issue' to 'bug' to make room for other issue
>   types in the future.
>
> * I'd like to add a 'severity'. A severity reflects the impact this
>   issue has on the user. The 'priority' is a ranking to be done by
>   developers, not users, and should be read-only for users.
>
> * Speaking of which, I'd like to know whether it wouldn't be meaningful
>   to introduce a 'Developer' role. I'm not familiar enough with python's
>   development model, but I'd expect it to allow the distinction between
>   'user' and 'developer'. For example, bugs can only be assigned to
>   developers, and certain changes can only be made by developers.


For this dicussion I am going to need to pull in some python-dev folk to
help figure out exactly where we want to go with all of this.  I was holding
off on this until we were at the point to discuss this.  But if you guys
want to start this discussion let me know and I will start to get people
over here to help contribute to the python-dev perspective since we are not
going to mirror SF.

-Brett

As soon as we are ready to instantiate the 'real' tracker, I'd like
> to adjust the schema accordingly, add some default initialization data
> to initial_data.py, and start working on the help system. That will help
> us understand the tracker schema and behavior better while we discuss
> subsequent changes.
>
> Comments ?
>
> Regards,
>                 Stefan
>
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061113/33da4d9b/attachment.htm 

From forsberg at efod.se  Mon Nov 13 21:44:56 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 13 Nov 2006 21:44:56 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	(Brett Cannon's message of "Mon, 13 Nov 2006 12:38:46 -0800")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
Message-ID: <87y7qfoz3r.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Brett Cannon" <brett at python.org> writes:

> For this dicussion I am going to need to pull in some python-dev folk to
> help figure out exactly where we want to go with all of this.  I was holding
> off on this until we were at the point to discuss this.  But if you guys
> want to start this discussion let me know and I will start to get people
> over here to help contribute to the python-dev perspective since we are not
> going to mirror SF.

Before we do this, perhaps we should establish some procedure to
handle all suggestions, to make sure we don't miss anything, and also
to make sure the suggestions favoured by most people get implemented.

I have a feeling that the python-dev people already have a procedure
for this? Our meta tracker should of course be part of it some way. 

Comments on this? 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWNlHrJurFAusidkRApIaAKCm+bHv/2cp34daouxXqapaJV4c4QCdEmAq
522kx59vWLsPROfsOV07OKc=
=C38L
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Mon Nov 13 23:00:38 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Nov 2006 17:00:38 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <87y7qfoz3r.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se>
Message-ID: <4558EB06.5030509@sympatico.ca>

Erik Forsberg wrote:
> "Brett Cannon" <brett at python.org> writes:
> 
>>> For this dicussion I am going to need to pull in some python-dev folk to
>>> help figure out exactly where we want to go with all of this.  I was holding
>>> off on this until we were at the point to discuss this.  But if you guys
>>> want to start this discussion let me know and I will start to get people
>>> over here to help contribute to the python-dev perspective since we are not
>>> going to mirror SF.
> 
> Before we do this, perhaps we should establish some procedure to
> handle all suggestions, to make sure we don't miss anything, and also
> to make sure the suggestions favoured by most people get implemented.
> 
> I have a feeling that the python-dev people already have a procedure
> for this? Our meta tracker should of course be part of it some way. 

Right. Well, my suggestion contained two items:
the use of an 'online' schema to illustrate / document the tracker,
and some actual schema changes. Can I assume that people generally
agree with such a navigation help ? Having that available with the
first version of the tracker may help everybody in the discussion of
subsequent schema / lifecycle changes.

Thus, I suggest I just do the first, and we start discussing the second
once the tracker is life, and everybody who has something to say has
an account on the metatracker, so we can have the discussion there.

OK ?

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Mon Nov 13 23:16:55 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 13 Nov 2006 23:16:55 +0100
Subject: [Tracker-discuss] Working with the sourceforge screenscraper
In-Reply-To: <455826BF.2030400@gmx.net>
References: <877iy0s9lj.fsf@uterus.efod.se>
	<45579527.2090209@v.loewis.de>	<87veljrhw3.fsf@uterus.efod.se>
	<45581730.4090204@v.loewis.de> <455826BF.2030400@gmx.net>
Message-ID: <4558EED7.6030103@v.loewis.de>

Georg Brandl schrieb:
>> I also considered that. There is one downside, though: SF will send
>> a message to the submitters and all on the SF "nosy" lists about these
>> changes; this could amount to spam. Python-dev people will get hundreds
>> of such messages, the original submitters will sometimes see this as
>> the first reaction so far.
>>
>> So at a maximum, we should do so for open issues only, and only after
>> python-dev has agreed to such a procedure.
> 
> Isn't there any possibility to completely turn off email notifications for
> the tracker system?

Not AFAICT. I just made you admin so you can see for yourself; if
anybody of the Roundup people wants to become admin of the Python
SF project as well, please let me know.

Regards,
Martin

From martin at v.loewis.de  Mon Nov 13 23:24:45 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 13 Nov 2006 23:24:45 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455891F0.2050209@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>
Message-ID: <4558F0AD.3040802@v.loewis.de>

Stefan Seefeld schrieb:
> * I'd like to add a 'severity'. A severity reflects the impact this
>   issue has on the user. The 'priority' is a ranking to be done by
>   developers, not users, and should be read-only for users.

This should come with precise guidelines of what value to use in what
cases. Users are unlikely to fill out such a field, even in presence
of clear guidelines (unless filling out the value is enforced, in which
case they will give each issue the highest possible severity).

> * Speaking of which, I'd like to know whether it wouldn't be meaningful
>   to introduce a 'Developer' role. I'm not familiar enough with python's
>   development model, but I'd expect it to allow the distinction between
>   'user' and 'developer'. For example, bugs can only be assigned to
>   developers, and certain changes can only be made by developers.

Currently, there is a group of people which are members of the SF python
project, and SF classifies them as "developers". Those are the ones that
bugs can be assigned to. By tradition, each of them has nearly full
access rights to the tracker, with the reasoning that they all have
(had) CVS commit access, which is a higher privilege. The only thing
they can't do is to change the "schema" (ie. the value list of
enumerated types, and the creation of new trackers); you have to be
admin to do that.

Of these developers, some only ever get assigned issues (and never
triage themselves), some others do triage. We currently make no
distinction between these groups.

Regards,
Martin

From martin at v.loewis.de  Mon Nov 13 23:31:19 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 13 Nov 2006 23:31:19 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <87y7qfoz3r.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se>
Message-ID: <4558F237.8030407@v.loewis.de>

Erik Forsberg schrieb:
> Before we do this, perhaps we should establish some procedure to
> handle all suggestions, to make sure we don't miss anything, and also
> to make sure the suggestions favoured by most people get implemented.
> 
> I have a feeling that the python-dev people already have a procedure
> for this? Our meta tracker should of course be part of it some way. 

Not sure what "this" is, but the answer is likely "no". If "this"
is "changes to the tracker", then no: there was zero chance that
SF would ever listen to our requests, so nobody bothered with making
any suggestions.

If "this" is "changes to the infrastructure", the people request
them by posting to python-dev. Either somebody responds, or they
either forget/give-up, or ask again after some time.

So letting them post to tracker-discuss would be a reasonable procedure;
OTOH, if they are told to put it into roundup, they also will.

Regards,
Martin

From nnorwitz at gmail.com  Mon Nov 13 23:32:36 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 13 Nov 2006 14:32:36 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <4558F0AD.3040802@v.loewis.de>
References: <455891F0.2050209@sympatico.ca> <4558F0AD.3040802@v.loewis.de>
Message-ID: <ee2a432c0611131432kaf31051rf9c8cd1548505a66@mail.gmail.com>

On 11/13/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Stefan Seefeld schrieb:
> > * I'd like to add a 'severity'. A severity reflects the impact this
> >   issue has on the user. The 'priority' is a ranking to be done by
> >   developers, not users, and should be read-only for users.
>
> This should come with precise guidelines of what value to use in what
> cases. Users are unlikely to fill out such a field, even in presence
> of clear guidelines (unless filling out the value is enforced, in which
> case they will give each issue the highest possible severity).

Right, it seems that no one ever gets the distinction right.  Users
shouldn't be able to change the priority either if this is setup.  I'm
not sure it's really worth it.  Very few of the categories are used in
SF.

Google's tracker is setup differently.  There are very few categories,
but you can assign arbitrary tags (labels) to each issue.  I was
somewhat opposed to this initially, but after using it a bit during
the design, I found it to be easier.  I would prefer to remain as
lightweight/minimal as possible.  Only add something when we really,
really need it.

n

From pfdubois at gmail.com  Tue Nov 14 01:34:49 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Mon, 13 Nov 2006 16:34:49 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
Message-ID: <f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>

a. I do not favor a 'severity'. Without some big long discussion, let me
lose all the nuance and summarize it as 'useful for user indicating how mad
they are, and letting off steam, but not useful to us' and 'experience with
sf tracker'.

b. The suggestion that we call issue bug doesn't make sense to me very much.
We have by default issues that can be categorized as bugs, features, wishes,
etc. In my tracker we have an FAQ priority as well. Probably the confusion
is with the word priority more than the word issue. I realize you could have
an entirely new class with its own handlers, but we can fight that war when
it breaks out.

c. The best way to screw up an operation, as the Japanese found out at
Midway, is to make it too complicated with too many pieces. We don't really
need a comment period, for example: we have already been selected by such a
process, and we all know it is a good product, and we all know we can adapt
it over time if we need to. Let's just run it out there, without any new
pieces that can break. If the standard help is not enough to suit you, you
can had some 'what does this mean' little links next to words like priority
and have it go to a text page that explains them all.  I'm for stopping SF
on a date certain, importing, checking it out ourselves, and then turning
the public loose on it. I've actually never seen anybody need any
instructions to use Roundup.

d. It is not a good habit of mind to try to make it 'like sourceforge'.  The
problem with involving pythondev too much is that those who know no other
way may overlook the ways in which 'native Roundup' might be better. I
remember a fellow in my office who refused to have a glass terminal and who
had elaborate explanations of why -- until about 2 days after he'd had a
glass terminal instead of a paper one. Committees make damn poor achitects.
I'm not saying don't ask customers what they want, but I am saying we have
to lead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061113/e7e860da/attachment.html 

From seefeld at sympatico.ca  Tue Nov 14 04:17:10 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 13 Nov 2006 22:17:10 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <4558F0AD.3040802@v.loewis.de>
References: <455891F0.2050209@sympatico.ca> <4558F0AD.3040802@v.loewis.de>
Message-ID: <45593536.8000606@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> * I'd like to add a 'severity'. A severity reflects the impact this
>>   issue has on the user. The 'priority' is a ranking to be done by
>>   developers, not users, and should be read-only for users.
> 
> This should come with precise guidelines of what value to use in what
> cases. Users are unlikely to fill out such a field, even in presence
> of clear guidelines (unless filling out the value is enforced, in which
> case they will give each issue the highest possible severity).

Heh, indeed. Yes, concise and clear help is important. The goal is not
to dilute the semantics by adding new properties, but by providing properties
that better map to users' / developers' vocabulary.
Thus, I think it would already be helpful to not use numerical values
(such as priority 1 .. 10), but instead use adjectives such as 'critical',
'major', 'minor', etc.

For example, at CodeSourcery we use a variety of bug trackers, all with
a severity attribute with enumerators

critical: "This issue leaves you completely unable to make progress"
serious:  "This issue is causing substantial impact to your progress, but a workaround exists."
mild:     "This issue is merely an annoyance, not preventing progress."


priorities may exist, too, but, as I said, are merely a means to assist
developers to prioritize their work, and thus, aren't displayed to users.

Anyway, as suggested earlier, I'm holding back more schema-related
suggestions until we have a live tracker to play with, and all interested
people are subscribed to the meta-tracker.

>> * Speaking of which, I'd like to know whether it wouldn't be meaningful
>>   to introduce a 'Developer' role. I'm not familiar enough with python's
>>   development model, but I'd expect it to allow the distinction between
>>   'user' and 'developer'. For example, bugs can only be assigned to
>>   developers, and certain changes can only be made by developers.
> 
> Currently, there is a group of people which are members of the SF python
> project, and SF classifies them as "developers". Those are the ones that
> bugs can be assigned to. By tradition, each of them has nearly full
> access rights to the tracker, with the reasoning that they all have
> (had) CVS commit access, which is a higher privilege. The only thing
> they can't do is to change the "schema" (ie. the value list of
> enumerated types, and the creation of new trackers); you have to be
> admin to do that.

Excellent, that gives us three types of users, all with different
access rights to the tracker. Again: the goal here is not to make things
more complex than necessary, but instead to simplify the UI by removing
items / transitions that aren't meaningful or valid anyway.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Tue Nov 14 08:16:29 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 14 Nov 2006 08:16:29 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <4558F237.8030407@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Mon, 13 Nov 2006 23:31:19 +0100")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
Message-ID: <87u012pkfm.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Erik Forsberg schrieb:
>> Before we do this, perhaps we should establish some procedure to
>> handle all suggestions, to make sure we don't miss anything, and also
>> to make sure the suggestions favoured by most people get implemented.
>> 
>> I have a feeling that the python-dev people already have a procedure
>> for this? Our meta tracker should of course be part of it some way. 
>
> Not sure what "this" is, but the answer is likely "no". If "this"
> is "changes to the tracker", then no: there was zero chance that
> SF would ever listen to our requests, so nobody bothered with making
> any suggestions.
>
> If "this" is "changes to the infrastructure", the people request
> them by posting to python-dev. Either somebody responds, or they
> either forget/give-up, or ask again after some time.
>
> So letting them post to tracker-discuss would be a reasonable procedure;
> OTOH, if they are told to put it into roundup, they also will.

Sorry for being unclear, I'll try to rephrase.

What I meant was that perhaps "we" (as in, "the people actually
implementing the new tracker") need a way to organize the suggestions
on features/changes to the tracker that people from python-dev suggest. 

I agree with Paul - it's important not to make things too complicated,
and I fear that we might get into a situation where we discuss pros
and cons of lots of suggestions never getting to the point where we
feel that we can go live with the new tracker.

How do we find out which features/changes are so important that we
_must_ implement them before going live, and what features/changes can
wait until later? Let's not forget that the tracker is not finalized
once it goes live - it can be improved later, and now when we have a
tracker software that is open source, requests for new features can
even be answered with the infamous "Patch welcome!" :-)

Perhaps I'm just an old lady with blue hair worrying too much? :-)

http://www.python.org/dev/process/ tells me that there is an "informal
voting process" that is sometimes followed on python-dev. Perhaps we
could use some variant on this. Here's a proposed way to handle
feature/change requests:

1) Feature/change requests must be added to the meta tracker. The
   priority should be set to 'wish'.

   (We might want to setup a detector that sends this list a mail
   whenever there's a new issue, and when there's a comment added)

2) Once it's in the meta tracker, let's discuss it, by making comments
   in the tracker. If someone has really good arguments on why a
   specific issue should be implemented before going live, here's the
   chance to publish them in a structured manner.

3) After a short period of discussion, let members of python-dev vote
   using the protocol outlined in
   http://www.python.org/dev/process/. This can also be done by adding
   comments to the tracker.

4) Issues that get many +1 and few -1 can be moved up to priority
   "bug", which means "must be implemented before christmas, ehm.. I
   mean before going live"

   Issues that get a few +1, few -1 and mostly +/-0 can be moved up to
   priority "feature" which means "good idea, but let's wait and do it
   later".

Does this sound like a good or bad idea? Other ideas on how to handle
this problem? Is it a problem at all, or should I just cut that blue
hair? :)

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWW1NrJurFAusidkRAmW0AKCZTKLiHNjGufmVKfaKhKb2IBky2ACgl8vW
sIERFig1JJE5h09s2NOHXV4=
=hMVq
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Tue Nov 14 13:40:54 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 07:40:54 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
Message-ID: <4559B956.5060309@sympatico.ca>

Paul Dubois wrote:
> a. I do not favor a 'severity'. Without some big long discussion, let me
> lose all the nuance and summarize it as 'useful for user indicating how
> mad they are, and letting off steam, but not useful to us' and
> 'experience with sf tracker'.

OK, so do you agree that the priority attribute is removed, or at least,
made unavailable to users ?

> b. The suggestion that we call issue bug doesn't make sense to me very
> much. We have by default issues that can be categorized as bugs,
> features, wishes, etc. In my tracker we have an FAQ priority as well.
> Probably the confusion is with the word priority more than the word
> issue. I realize you could have an entirely new class with its own
> handlers, but we can fight that war when it breaks out.

I was specifically thinking of things such as PEPs that we may add support
for later on. All this falls into the broad category of 'issues', and so
I'd just point out that right now we are discussing bug tracking only.

> c. The best way to screw up an operation, as the Japanese found out at
> Midway, is to make it too complicated with too many pieces. We don't
> really need a comment period, for example: we have already been selected
> by such a process, and we all know it is a good product, and we all know
> we can adapt it over time if we need to. Let's just run it out there,
> without any new pieces that can break. If the standard help is not
> enough to suit you, you can had some 'what does this mean' little links
> next to words like priority and have it go to a text page that explains
> them all.  I'm for stopping SF on a date certain, importing, checking it
> out ourselves, and then turning the public loose on it. I've actually
> never seen anybody need any instructions to use Roundup.

Yes we have been selected, based on roundup's capabilities. I'm not sure
whether that actually implies that the schema used for the prototype is
already optimal. I for one don't like the schema used at sf.net at all,
and so I'd break more radically from it during the transition, since
now we can.

> d. It is not a good habit of mind to try to make it 'like sourceforge'. 
> The problem with involving pythondev too much is that those who know no
> other way may overlook the ways in which 'native Roundup' might be
> better. I remember a fellow in my office who refused to have a glass
> terminal and who had elaborate explanations of why -- until about 2 days
> after he'd had a glass terminal instead of a paper one. Committees make
> damn poor achitects. I'm not saying don't ask customers what they want,
> but I am saying we have to lead.

We are in violent agreement. I have configured many roundup trackers in
the past, and always was pleased with the results. I'm certainly not
trying to make things complex. Quite the contrary. I'm trying to
find the ideal vocabulary that fits into the actual development process.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Tue Nov 14 19:01:42 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Tue, 14 Nov 2006 10:01:42 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <4559B956.5060309@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
	<4559B956.5060309@sympatico.ca>
Message-ID: <f74a6c2f0611141001q5f37486aye1bcf961afee36b9@mail.gmail.com>

On 11/14/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
> > a. I do not favor a 'severity'. Without some big long discussion, let me
> > lose all the nuance and summarize it as 'useful for user indicating how
> > mad they are, and letting off steam, but not useful to us' and
> > 'experience with sf tracker'.
>
> OK, so do you agree that the priority attribute is removed, or at least,
> made unavailable to users ?


I see nothing wrong with letting only developers (or some other designated
set of persons) set priority. However, users might still see the priorities
so that they can tell what will be fixed soonest.

I am guilty I just realized of not looking at the prototype; I've been
entirely thinking 'native' roundup, not of whatever changes were made for
the prototype.

To remove the priority attribute means you want to handle rfe (wishes) some
other way? That is, this issue class is only for bugs, period? I think that
is the source of my confusion. The problem is people will submit wishes and
commentary disguised as bug reports. ("Clearly a dict should remember the
order of its keys.") We have also found bug reports that are 'user error'
frequently turn into FAQ entries or 'feature' descriptions, so we have found
it useful to use the original Roundup priorities - done + FAQ. We didn't
find it useful to have two forms of closure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061114/0f7494df/attachment.htm 

From seefeld at sympatico.ca  Tue Nov 14 19:21:36 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 13:21:36 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <f74a6c2f0611141001q5f37486aye1bcf961afee36b9@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>	<4559B956.5060309@sympatico.ca>
	<f74a6c2f0611141001q5f37486aye1bcf961afee36b9@mail.gmail.com>
Message-ID: <455A0930.7060206@sympatico.ca>

Paul Dubois wrote:

> I see nothing wrong with letting only developers (or some other
> designated set of persons) set priority. However, users might still see
> the priorities so that they can tell what will be fixed soonest.

Yes, of course (if priority is any indication of it). (I'v used trackers
in the past where I set up a 'milestone' issue type, which then could be
used to attach bugs to, so you can easily query which bugs were targetted
at a given milestone (release), and what milestone to expect a given bug
to be fixed in.)

> I am guilty I just realized of not looking at the prototype; I've been
> entirely thinking 'native' roundup, not of whatever changes were made
> for the prototype.

I'm looking forward to having it set up and run on the server...

> To remove the priority attribute means you want to handle rfe (wishes)
> some other way? That is, this issue class is only for bugs, period? I
> think that is the source of my confusion. The problem is people will
> submit wishes and commentary disguised as bug reports. ("Clearly a dict
> should remember the order of its keys.") We have also found bug reports
> that are 'user error' frequently turn into FAQ entries or 'feature'
> descriptions, so we have found it useful to use the original Roundup
> priorities - done + FAQ. We didn't find it useful to have two forms of
> closure.

Without going into too much of a schema discussion (which I'm looking
forward to have once we are ready for it): I think it is reasonable to
have some kind of 'type' property. For example, for my synopsis tracker
I use types [crash, build failure, resource usage, security, behavior,
enhancement request] for users to choose from. I agree that the line between
'bug' and 'rfe' often is blury, and that one can turn into the other during
the lifetime of the issue. Thus, I have this type attribute available to
all bugs.
The python tracker on sf.net has 'category' and 'group' properties, which
I find confusing, too. The second looks like it is used to tell what python
version the bug was observed with (why isn't it called 'version', then ?),
while the first is probably better called 'component'.

But hey, now we are really getting deep into a schema discussion. ;-)
I'm really only pointing these things out here to illustrate that I don't
think the old sf.net schema is very clear, and that a well-crafted
help system (yes, simply one help link per property on the item page)
would be very efficient for users of the tracker to figure out what
the correct properties are for the thing they want to report.

Regards,

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Tue Nov 14 19:38:15 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 14 Nov 2006 19:38:15 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <87u012pkfm.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de> <87u012pkfm.fsf@uterus.efod.se>
Message-ID: <455A0D17.40008@v.loewis.de>

Erik Forsberg schrieb:
> How do we find out which features/changes are so important that we
> _must_ implement them before going live, and what features/changes can
> wait until later? 

I'm fine with the process you are proposing. I have a specific answer
to this question, though: Changes that would force a re-import of all
data (because of data-loss, or data-garbling) need to be detected before
the new infrastructure goes life. Anything else can probably wait until
later.

Some of the other thing should get high priority to be implemented
before the new tracker goes life: those features that are currently
available in the SF tracker and heavily used. For these, I see
- email notifications
- SF redirector
- weekly summary

Regards,
Martin

From brett at python.org  Tue Nov 14 19:53:34 2006
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Nov 2006 10:53:34 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A0D17.40008@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
Message-ID: <bbaeab100611141053q724212d9p970073f2f2e5f4f8@mail.gmail.com>

On 11/14/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Erik Forsberg schrieb:
> > How do we find out which features/changes are so important that we
> > _must_ implement them before going live, and what features/changes can
> > wait until later?
>
> I'm fine with the process you are proposing. I have a specific answer
> to this question, though: Changes that would force a re-import of all
> data (because of data-loss, or data-garbling) need to be detected before
> the new infrastructure goes life. Anything else can probably wait until
> later.


Ditto from me.  We can try to figure things out ahead of time before we do
the final SF pull, but if it is easy to change the schema later on then it
is not such a priority.

But we do need to heed what Neal Norwitz and Anthony Baxter want since they
handle releases.  And then people who do a lot of triaging (Martin v. L?wis
and Georg Brandl) should also be listened to.  I am not saying everyone else
should be ignored, but these people have to deal with the tracker the most
in the end.

Some of the other thing should get high priority to be implemented
> before the new tracker goes life: those features that are currently
> available in the SF tracker and heavily used. For these, I see
> - email notifications
> - SF redirector
> - weekly summary


I agree with the first two.  I don't know if the weekly summary Kurt sends
out is that critical.  It's nice to keep an eye on the number of current
bugs, but I don't see it as a show-stopper.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061114/75a42f61/attachment.html 

From seefeld at sympatico.ca  Tue Nov 14 19:45:59 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 13:45:59 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A0D17.40008@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
Message-ID: <455A0EE7.4070801@sympatico.ca>

Martin v. L?wis wrote:

> Some of the other thing should get high priority to be implemented
> before the new tracker goes life: those features that are currently
> available in the SF tracker and heavily used. For these, I see
> - email notifications

What kind of notification is currently sent out ? (Note: it's quite
trivial to make roundup do that, too.)

> - SF redirector

What is that ?

> - weekly summary

That's straight forward to implement with the roundup API.
Can you point me to such a summary ? I could add a reporter
script that does the same with the new tracker.

Thanks,
		Stefan

From martin at v.loewis.de  Tue Nov 14 20:30:44 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 14 Nov 2006 20:30:44 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A0EE7.4070801@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<455A0D17.40008@v.loewis.de> <455A0EE7.4070801@sympatico.ca>
Message-ID: <455A1964.2010308@v.loewis.de>

Stefan Seefeld schrieb:
>> Some of the other thing should get high priority to be implemented
>> before the new tracker goes life: those features that are currently
>> available in the SF tracker and heavily used. For these, I see
>> - email notifications
> 
> What kind of notification is currently sent out ? 

There is a message on each change to python-bugs-list, a message to
all members of SF's "nosy list" (which are all people who ever posted
a comment), and a message to the assigned-to person (when an assignment
is made, when a new message is added and there is already somebody
assigned, and when a new issue is submitted and it gets auto-assigned).

> (Note: it's quite trivial to make roundup do that, too.)

I'm quite sure it is - I just wanted to mention as an essential
aspect that should be done before the tracker goes life (although
it is technically possible to do it afterwards also)

>> - SF redirector
> 
> What is that ?

Currently, http://python.org/sf/<bugid> gets you to the SF
page; try http://python.org/sf/1593751

People use that a lot because it is short than the SF URLs.
It also has a query syntax, e.g. used in the "SourceForge"
box at

http://www.python.org/dev/

This syntax is http://python.org/sf?id=1593751

Notice that this also used in various browser plugins.

After the conversion, it should refer to the equivalent
roundup page; the bugid should stay the same even if
the import renumbers them. To implement that, a static
mapping could be used: there won't be any new SF bugs
after the conversion is completed.

For new bugs, it would be desirable if a short,
stable URL could be available out-of-the-box, like
bugs.python.org/<bugid>

>> - weekly summary
> 
> That's straight forward to implement with the roundup API.
> Can you point me to such a summary ? I could add a reporter
> script that does the same with the new tracker.

http://mail.python.org/pipermail/python-dev/2006-November/069909.html

I think Kurt (B. Kaiser) can provide the source code of the
current script if desired. Notice that it also uses the
SF redirector (I keep mentioning it because it's my doing :-)

Regards,
Martin

From seefeld at sympatico.ca  Tue Nov 14 20:36:03 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 14:36:03 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A1964.2010308@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<455A0D17.40008@v.loewis.de> <455A0EE7.4070801@sympatico.ca>
	<455A1964.2010308@v.loewis.de>
Message-ID: <455A1AA3.40208@sympatico.ca>

Martin v. L?wis wrote:

>>> - SF redirector
>> What is that ?
> 
> Currently, http://python.org/sf/<bugid> gets you to the SF
> page; try http://python.org/sf/1593751
> 
> People use that a lot because it is short than the SF URLs.
> It also has a query syntax, e.g. used in the "SourceForge"
> box at
> 
> http://www.python.org/dev/
> 
> This syntax is http://python.org/sf?id=1593751
> 
> Notice that this also used in various browser plugins.
> 
> After the conversion, it should refer to the equivalent
> roundup page; the bugid should stay the same even if
> the import renumbers them. To implement that, a static
> mapping could be used: there won't be any new SF bugs
> after the conversion is completed.

That sounds like an interesting challenge. Erik, didn't
you look into how to create issues with specific ids ?
Or am I making that up now ?
It would be nice if we could avoid http redirection.

> For new bugs, it would be desirable if a short,
> stable URL could be available out-of-the-box, like
> bugs.python.org/<bugid>

Right.

>>> - weekly summary
>> That's straight forward to implement with the roundup API.
>> Can you point me to such a summary ? I could add a reporter
>> script that does the same with the new tracker.
> 
> http://mail.python.org/pipermail/python-dev/2006-November/069909.html
> 
> I think Kurt (B. Kaiser) can provide the source code of the
> current script if desired. Notice that it also uses the
> SF redirector (I keep mentioning it because it's my doing :-)

:-)

Thanks,
		Stefan



From forsberg at efod.se  Tue Nov 14 20:46:04 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 14 Nov 2006 20:46:04 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A1AA3.40208@sympatico.ca> (Stefan Seefeld's message of "Tue, 
	14 Nov 2006 14:36:03 -0500")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
	<455A0EE7.4070801@sympatico.ca> <455A1964.2010308@v.loewis.de>
	<455A1AA3.40208@sympatico.ca>
Message-ID: <87psbpq0ar.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

>> After the conversion, it should refer to the equivalent
>> roundup page; the bugid should stay the same even if
>> the import renumbers them. To implement that, a static
>> mapping could be used: there won't be any new SF bugs
>> after the conversion is completed.
>
> That sounds like an interesting challenge. Erik, didn't
> you look into how to create issues with specific ids ?
> Or am I making that up now ?
> It would be nice if we could avoid http redirection.

The import does not renumber - it keeps the sf bug id. 

Check out any bug in http://efod.se/python-tracker/ - each issue even
has a link to the old sf entry (to make it easy to compare source and
result after import). 

So, as an example, http://efod.se/python-tracker/issue1462485
corresponds to sf bug id 1462485.

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWhz8rJurFAusidkRAsAqAJ9cGw0onw8rkDuT3PwHzpqaDFVPgwCfeCUm
1oMU670iwc8Uw8qBl4JiFQ0=
=Y18t
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Tue Nov 14 20:49:12 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 14 Nov 2006 20:49:12 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A1AA3.40208@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<455A0D17.40008@v.loewis.de>
	<455A0EE7.4070801@sympatico.ca>	<455A1964.2010308@v.loewis.de>
	<455A1AA3.40208@sympatico.ca>
Message-ID: <455A1DB8.3000504@v.loewis.de>

Stefan Seefeld schrieb:
>> After the conversion, it should refer to the equivalent
>> roundup page; the bugid should stay the same even if
>> the import renumbers them. To implement that, a static
>> mapping could be used: there won't be any new SF bugs
>> after the conversion is completed.
> 
> That sounds like an interesting challenge. Erik, didn't
> you look into how to create issues with specific ids ?
> Or am I making that up now ?
> It would be nice if we could avoid http redirection.

Sure. However, one level of redirection is unavoidable,
anyway, because it's different computer systems
(www.python.org vs. bugs.python.org). At that redirection,
renumbering can occur, e.g.

 http://python.org/sf?id=1593751

could get redirected to

 http://bugs.python.org/3426

(say). The renumbering database would live on www.python.org,
and it wouldn't ever need to change, since no new items are
added to the SF trackers. The database would have to be created
during the transition. As it is a static database, a pickled
Python dictionary or a bsddb database might work just fine.

Regards,
Martin

From seefeld at sympatico.ca  Tue Nov 14 20:49:13 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 14:49:13 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <87psbpq0ar.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<455A0D17.40008@v.loewis.de>	<455A0EE7.4070801@sympatico.ca>
	<455A1964.2010308@v.loewis.de>	<455A1AA3.40208@sympatico.ca>
	<87psbpq0ar.fsf@uterus.efod.se>
Message-ID: <455A1DB9.10502@sympatico.ca>

Erik Forsberg wrote:

> The import does not renumber - it keeps the sf bug id. 
> 
> Check out any bug in http://efod.se/python-tracker/ - each issue even
> has a link to the old sf entry (to make it easy to compare source and
> result after import). 
> 
> So, as an example, http://efod.se/python-tracker/issue1462485
> corresponds to sf bug id 1462485.

Wow, that's pretty awesome !
(and will make the transition all that much easier.)

Thanks,
		Stefan

From pfdubois at gmail.com  Tue Nov 14 23:24:14 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Tue, 14 Nov 2006 14:24:14 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A0D17.40008@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
Message-ID: <f74a6c2f0611141424g3ef72d4do6100babe031b7bc1@mail.gmail.com>

FYI: I corresponded with Stefan and we decided that I will take the 'weekly
summary' job.

On 11/14/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Erik Forsberg schrieb:
> > How do we find out which features/changes are so important that we
> > _must_ implement them before going live, and what features/changes can
> > wait until later?
>
> I'm fine with the process you are proposing. I have a specific answer
> to this question, though: Changes that would force a re-import of all
> data (because of data-loss, or data-garbling) need to be detected before
> the new infrastructure goes life. Anything else can probably wait until
> later.
>
> Some of the other thing should get high priority to be implemented
> before the new tracker goes life: those features that are currently
> available in the SF tracker and heavily used. For these, I see
> - email notifications
> - SF redirector
> - weekly summary
>
> Regards,
> Martin
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061114/6f09f561/attachment.html 

From anthony at interlink.com.au  Wed Nov 15 03:00:56 2006
From: anthony at interlink.com.au (Anthony Baxter)
Date: Wed, 15 Nov 2006 13:00:56 +1100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <4559B956.5060309@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
	<4559B956.5060309@sympatico.ca>
Message-ID: <200611151300.57423.anthony@interlink.com.au>

Speaking for myself - we use priorities to mark "stuff which needs 
to be looked at before release X.Y" and the like. This could, and 
should, be better implemented using keywords.

Anthony

From seefeld at sympatico.ca  Wed Nov 15 04:02:02 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 14 Nov 2006 22:02:02 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <200611151300.57423.anthony@interlink.com.au>
References: <455891F0.2050209@sympatico.ca>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
	<4559B956.5060309@sympatico.ca>
	<200611151300.57423.anthony@interlink.com.au>
Message-ID: <455A832A.3090603@sympatico.ca>

Anthony Baxter wrote:
> Speaking for myself - we use priorities to mark "stuff which needs 
> to be looked at before release X.Y" and the like. This could, and 
> should, be better implemented using keywords.

What's the advantage of using keywords for this instead of a more
structured approach where the bug either has a property of type
'target version', or where there is another entity 'release' or 'milestone'
that refers to all bugs to be closed ?
The latter has the advantage of being more expressive, so you could
form more complex queries more easily (either online, or when
generating reports, etc.).

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Wed Nov 15 06:55:20 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 15 Nov 2006 06:55:20 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <f74a6c2f0611141424g3ef72d4do6100babe031b7bc1@mail.gmail.com>
	(Paul Dubois's message of "Tue, 14 Nov 2006 14:24:14 -0800")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
	<f74a6c2f0611141424g3ef72d4do6100babe031b7bc1@mail.gmail.com>
Message-ID: <87lkmdp83b.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Paul Dubois" <pfdubois at gmail.com> writes:

> FYI: I corresponded with Stefan and we decided that I will take the 'weekly
> summary' job.

May I then propose that you assign yourself to that task in the meta tracker? 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFWqvHrJurFAusidkRAkB2AJ9qz7BzcT7rWr+Ltrl7z6fJRHdXrgCeIeyl
pB9XZNGdIfAbwHo9i/ERTqg=
=EZAb
-----END PGP SIGNATURE-----

From forsberg at efod.se  Wed Nov 15 16:52:57 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 15 Nov 2006 16:52:57 +0100
Subject: [Tracker-discuss] Tracker data download success!
Message-ID: <200611151652.57269.forsberg@efod.se>

./fetch_sf_data  1408,75s user 155,14s system 3% cpu 14:20:49,66 total

Ah! Finally, after several robustness improvements to the scripts, it seems 
like my download script has succeeded in fetching the whole database.

Next challenge: See if the import scripts still work :-).

I'll be back later with a patch for people interested.

\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Wed Nov 15 17:24:28 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 15 Nov 2006 11:24:28 -0500
Subject: [Tracker-discuss] Tracker data download success!
In-Reply-To: <200611151652.57269.forsberg@efod.se>
References: <200611151652.57269.forsberg@efod.se>
Message-ID: <455B3F3C.2000305@sympatico.ca>

Erik Forsberg wrote:
> ./fetch_sf_data  1408,75s user 155,14s system 3% cpu 14:20:49,66 total
> 
> Ah! Finally, after several robustness improvements to the scripts, it seems 
> like my download script has succeeded in fetching the whole database.
> 
> Next challenge: See if the import scripts still work :-).
> 
> I'll be back later with a patch for people interested.

Erik, can we extract the property enumerators (status, category, and group values)
and integrate them into initial_data.py ? That would allow us to get a better
picture of the schema and tracker behavior, without having to have real
issues in the database.

(I was tempted to manually write them down from looking at the sf.net tracker,
 but thought there was may be a more elegant way to do it :-) )

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Wed Nov 15 17:46:49 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Wed, 15 Nov 2006 17:46:49 +0100
Subject: [Tracker-discuss] Tracker data download success!
In-Reply-To: <455B3F3C.2000305@sympatico.ca>
References: <200611151652.57269.forsberg@efod.se>
	<455B3F3C.2000305@sympatico.ca>
Message-ID: <200611151746.49782.forsberg@efod.se>

onsdag 15 november 2006 17:24 skrev Stefan Seefeld:
> Erik Forsberg wrote:
> > ./fetch_sf_data  1408,75s user 155,14s system 3% cpu 14:20:49,66 total
> >
> > Ah! Finally, after several robustness improvements to the scripts, it
> > seems like my download script has succeeded in fetching the whole
> > database.
> >
> > Next challenge: See if the import scripts still work :-).
> >
> > I'll be back later with a patch for people interested.
>
> Erik, can we extract the property enumerators (status, category, and group
> values) and integrate them into initial_data.py ? That would allow us to
> get a better picture of the schema and tracker behavior, without having to
> have real issues in the database.

> (I was tempted to manually write them down from looking at the sf.net
> tracker, but thought there was may be a more elegant way to do it :-) )

I'd say that this is the KISS solution. Why bother doing exports of so small 
amounts of data, when it probably takes less time to write them down 
manually? 

The importer is written in such a way that it will not create double entries 
of status/category/group values, so as long as they don't change names, 
existing values (from initial_data.py) will be used when doing the final 
import.

\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Wed Nov 15 17:56:48 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 15 Nov 2006 11:56:48 -0500
Subject: [Tracker-discuss] Tracker data download success!
In-Reply-To: <200611151746.49782.forsberg@efod.se>
References: <200611151652.57269.forsberg@efod.se>	<455B3F3C.2000305@sympatico.ca>
	<200611151746.49782.forsberg@efod.se>
Message-ID: <455B46D0.1000405@sympatico.ca>

Erik Forsberg wrote:
> onsdag 15 november 2006 17:24 skrev Stefan Seefeld:

>> (I was tempted to manually write them down from looking at the sf.net
>> tracker, but thought there was may be a more elegant way to do it :-) )
> 
> I'd say that this is the KISS solution. Why bother doing exports of so small 
> amounts of data, when it probably takes less time to write them down 
> manually? 
> 
> The importer is written in such a way that it will not create double entries 
> of status/category/group values, so as long as they don't change names, 
> existing values (from initial_data.py) will be used when doing the final 
> import.

Good, I'll take care of that, then.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From g.brandl at gmx.net  Wed Nov 15 18:13:10 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 15 Nov 2006 18:13:10 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A832A.3090603@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>	<4559B956.5060309@sympatico.ca>	<200611151300.57423.anthony@interlink.com.au>
	<455A832A.3090603@sympatico.ca>
Message-ID: <455B4AA6.3040906@gmx.net>

Stefan Seefeld schrieb:
> Anthony Baxter wrote:
>> Speaking for myself - we use priorities to mark "stuff which needs 
>> to be looked at before release X.Y" and the like. This could, and 
>> should, be better implemented using keywords.
> 
> What's the advantage of using keywords for this instead of a more
> structured approach where the bug either has a property of type
> 'target version', or where there is another entity 'release' or 'milestone'
> that refers to all bugs to be closed ?
> The latter has the advantage of being more expressive, so you could
> form more complex queries more easily (either online, or when
> generating reports, etc.).

The milestone concept is already weakly used with the SourceForge groups.
IMO it's a good concept, helps you keep track of which bugs should be closed
before which release. Together with a priority/type classification (showstopper,
major bug, minor bug, nuisance, enhancement request), there might be a better
possibility to establish guidelines on which bugs must be looked at before
release.

regards,
Georg

From pfdubois at gmail.com  Wed Nov 15 19:19:12 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 15 Nov 2006 10:19:12 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455B4AA6.3040906@gmx.net>
References: <455891F0.2050209@sympatico.ca>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
	<4559B956.5060309@sympatico.ca>
	<200611151300.57423.anthony@interlink.com.au>
	<455A832A.3090603@sympatico.ca> <455B4AA6.3040906@gmx.net>
Message-ID: <f74a6c2f0611151019r19ca61bap849d8d317405a543@mail.gmail.com>

FWIW I added a 'Due Date' to our tracker by following the example in the
Roundup guide. However, I decided not to use an actual date field but rather
strings, so that you can have due dates like "v2.6", "ASAP", and "2Q 2007";
the problem with real dates was that releases do not tend to have stable
dates. Using the ordering attribute you can control the order of the groups
in a custom search by due date. I added a permission class to give to those
special managers allowed to create new 'due dates'.

As I mentioned before we use a special priority to indicate things that have
been fixed but are not yet in the main line; but perhaps in the Python
context that would be irrelevant. A due date can indicate when the fix or
enhancement will appear.

On 11/15/06, Georg Brandl <g.brandl at gmx.net> wrote:
>
> Stefan Seefeld schrieb:
> > Anthony Baxter wrote:
> >> Speaking for myself - we use priorities to mark "stuff which needs
> >> to be looked at before release X.Y" and the like. This could, and
> >> should, be better implemented using keywords.
> >
> > What's the advantage of using keywords for this instead of a more
> > structured approach where the bug either has a property of type
> > 'target version', or where there is another entity 'release' or
> 'milestone'
> > that refers to all bugs to be closed ?
> > The latter has the advantage of being more expressive, so you could
> > form more complex queries more easily (either online, or when
> > generating reports, etc.).
>
> The milestone concept is already weakly used with the SourceForge groups.
> IMO it's a good concept, helps you keep track of which bugs should be
> closed
> before which release. Together with a priority/type classification
> (showstopper,
> major bug, minor bug, nuisance, enhancement request), there might be a
> better
> possibility to establish guidelines on which bugs must be looked at before
> release.
>
> regards,
> Georg
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061115/ea025982/attachment.htm 

From seefeld at sympatico.ca  Wed Nov 15 19:30:08 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 15 Nov 2006 13:30:08 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <f74a6c2f0611151019r19ca61bap849d8d317405a543@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>	
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>	
	<4559B956.5060309@sympatico.ca>	
	<200611151300.57423.anthony@interlink.com.au>	
	<455A832A.3090603@sympatico.ca> <455B4AA6.3040906@gmx.net>
	<f74a6c2f0611151019r19ca61bap849d8d317405a543@mail.gmail.com>
Message-ID: <455B5CB0.5020605@sympatico.ca>

Paul Dubois wrote:
> FWIW I added a 'Due Date' to our tracker by following the example in the
> Roundup guide. However, I decided not to use an actual date field but
> rather strings, so that you can have due dates like "v2.6", "ASAP", and
> "2Q 2007"; the problem with real dates was that releases do not tend to
> have stable dates. Using the ordering attribute you can control the
> order of the groups in a custom search by due date. I added a permission
> class to give to those special managers allowed to create new 'due dates'.

The problem I can see with using strings here is that there is nothing
that enforces a particular value, i.e. if you type 'V1,1' but you actually
meant 'V1.1' there is no validation, though your bug never shows up if
you query for all bugs due by release V1.1.
Using links to join a 'bug' and a 'milestone' (or 'release') table is
thus less error-prone, and easier to query.

(The same would be true if we started to track bugs against particular
branches, at which point a 'branch' property would probably make sense,
too.)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From g.brandl at gmx.net  Wed Nov 15 19:38:09 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 15 Nov 2006 19:38:09 +0100
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455B5CB0.5020605@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>		<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>		<4559B956.5060309@sympatico.ca>		<200611151300.57423.anthony@interlink.com.au>		<455A832A.3090603@sympatico.ca>
	<455B4AA6.3040906@gmx.net>	<f74a6c2f0611151019r19ca61bap849d8d317405a543@mail.gmail.com>
	<455B5CB0.5020605@sympatico.ca>
Message-ID: <455B5E91.9020503@gmx.net>

Stefan Seefeld schrieb:
> Paul Dubois wrote:
>> FWIW I added a 'Due Date' to our tracker by following the example in the
>> Roundup guide. However, I decided not to use an actual date field but
>> rather strings, so that you can have due dates like "v2.6", "ASAP", and
>> "2Q 2007"; the problem with real dates was that releases do not tend to
>> have stable dates. Using the ordering attribute you can control the
>> order of the groups in a custom search by due date. I added a permission
>> class to give to those special managers allowed to create new 'due dates'.
> 
> The problem I can see with using strings here is that there is nothing
> that enforces a particular value, i.e. if you type 'V1,1' but you actually
> meant 'V1.1' there is no validation, though your bug never shows up if
> you query for all bugs due by release V1.1.
> Using links to join a 'bug' and a 'milestone' (or 'release') table is
> thus less error-prone, and easier to query.

+1. This is also why I'm a bit sceptical about a "tags" value: it's easy to
get the tags wrong, and the bug will then not be found together with the
others belonging to a category.

> (The same would be true if we started to track bugs against particular
> branches, at which point a 'branch' property would probably make sense,
> too.)

I don't think that's needed since we have not so many branches around.
There's at most two maintenance branches, and p3yk.

regards,
Georg

From pfdubois at gmail.com  Wed Nov 15 19:42:52 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 15 Nov 2006 10:42:52 -0800
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455B5E91.9020503@gmx.net>
References: <455891F0.2050209@sympatico.ca>
	<f74a6c2f0611131634r752a1a46uf801937c3fa9b6aa@mail.gmail.com>
	<4559B956.5060309@sympatico.ca>
	<200611151300.57423.anthony@interlink.com.au>
	<455A832A.3090603@sympatico.ca> <455B4AA6.3040906@gmx.net>
	<f74a6c2f0611151019r19ca61bap849d8d317405a543@mail.gmail.com>
	<455B5CB0.5020605@sympatico.ca> <455B5E91.9020503@gmx.net>
Message-ID: <f74a6c2f0611151042nfb21ae7r29e18910c5c6852c@mail.gmail.com>

I should have made clear that the list of 'due dates' is a constrained list
-- it is a pulldown when displayed. So you can't search for one that doesn't
exist. Maybe we're saying the same thing.

On 11/15/06, Georg Brandl <g.brandl at gmx.net> wrote:
>
> Stefan Seefeld schrieb:
> > Paul Dubois wrote:
> >> FWIW I added a 'Due Date' to our tracker by following the example in
> the
> >> Roundup guide. However, I decided not to use an actual date field but
> >> rather strings, so that you can have due dates like "v2.6", "ASAP", and
> >> "2Q 2007"; the problem with real dates was that releases do not tend to
> >> have stable dates. Using the ordering attribute you can control the
> >> order of the groups in a custom search by due date. I added a
> permission
> >> class to give to those special managers allowed to create new 'due
> dates'.
> >
> > The problem I can see with using strings here is that there is nothing
> > that enforces a particular value, i.e. if you type 'V1,1' but you
> actually
> > meant 'V1.1' there is no validation, though your bug never shows up if
> > you query for all bugs due by release V1.1.
> > Using links to join a 'bug' and a 'milestone' (or 'release') table is
> > thus less error-prone, and easier to query.
>
> +1. This is also why I'm a bit sceptical about a "tags" value: it's easy
> to
> get the tags wrong, and the bug will then not be found together with the
> others belonging to a category.
>
> > (The same would be true if we started to track bugs against particular
> > branches, at which point a 'branch' property would probably make sense,
> > too.)
>
> I don't think that's needed since we have not so many branches around.
> There's at most two maintenance branches, and p3yk.
>
> regards,
> Georg
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061115/3b14d1b2/attachment-0001.html 

From forsberg at efod.se  Thu Nov 16 07:14:29 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 16 Nov 2006 07:14:29 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87u012pkfm.fsf@uterus.efod.se> (Erik Forsberg's message of "Tue, 
	14 Nov 2006 08:16:29 +0100")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se>
Message-ID: <87d57nq5oa.fsf_-_@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Forsberg <forsberg at efod.se> writes:

> http://www.python.org/dev/process/ tells me that there is an "informal
> voting process" that is sometimes followed on python-dev. Perhaps we
> could use some variant on this. Here's a proposed way to handle
> feature/change requests:

>
> 1) Feature/change requests must be added to the meta tracker. The
>    priority should be set to 'wish'.
>
>    (We might want to setup a detector that sends this list a mail
>    whenever there's a new issue, and when there's a comment added)
>
> 2) Once it's in the meta tracker, let's discuss it, by making comments
>    in the tracker. If someone has really good arguments on why a
>    specific issue should be implemented before going live, here's the
>    chance to publish them in a structured manner.
>
> 3) After a short period of discussion, let members of python-dev vote
>    using the protocol outlined in
>    http://www.python.org/dev/process/. This can also be done by adding
>    comments to the tracker.
>
> 4) Issues that get many +1 and few -1 can be moved up to priority
>    "bug", which means "must be implemented before christmas, ehm.. I
>    mean before going live"
>
>    Issues that get a few +1, few -1 and mostly +/-0 can be moved up to
>    priority "feature" which means "good idea, but let's wait and do it
>    later".
>
> Does this sound like a good or bad idea? Other ideas on how to handle
> this problem? Is it a problem at all, or should I just cut that blue
> hair? :)

Any comments from the rest of the tracker team? Michael? Stefan? Paul?

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFXAHFrJurFAusidkRAgexAJ97CPUVqO62f60cNOU/3qNva17knwCgn1kI
yW1yFzu2XgrgngLuOfj+dUs=
=59U4
-----END PGP SIGNATURE-----

From pfdubois at gmail.com  Thu Nov 16 08:56:58 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Wed, 15 Nov 2006 23:56:58 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87d57nq5oa.fsf_-_@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
Message-ID: <f74a6c2f0611152356i72140c5du9ae566e90be43a2b@mail.gmail.com>

I'm basically ok with this as a procedure for the long run.

On 11/15/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Erik Forsberg <forsberg at efod.se> writes:
>
> > http://www.python.org/dev/process/ tells me that there is an "informal
> > voting process" that is sometimes followed on python-dev. Perhaps we
> > could use some variant on this. Here's a proposed way to handle
> > feature/change requests:
>
> >
> > 1) Feature/change requests must be added to the meta tracker. The
> >    priority should be set to 'wish'.
> >
> >    (We might want to setup a detector that sends this list a mail
> >    whenever there's a new issue, and when there's a comment added)
> >
> > 2) Once it's in the meta tracker, let's discuss it, by making comments
> >    in the tracker. If someone has really good arguments on why a
> >    specific issue should be implemented before going live, here's the
> >    chance to publish them in a structured manner.
> >
> > 3) After a short period of discussion, let members of python-dev vote
> >    using the protocol outlined in
> >    http://www.python.org/dev/process/. This can also be done by adding
> >    comments to the tracker.
> >
> > 4) Issues that get many +1 and few -1 can be moved up to priority
> >    "bug", which means "must be implemented before christmas, ehm.. I
> >    mean before going live"
> >
> >    Issues that get a few +1, few -1 and mostly +/-0 can be moved up to
> >    priority "feature" which means "good idea, but let's wait and do it
> >    later".
> >
> > Does this sound like a good or bad idea? Other ideas on how to handle
> > this problem? Is it a problem at all, or should I just cut that blue
> > hair? :)
>
> Any comments from the rest of the tracker team? Michael? Stefan? Paul?
>
> \EF
> - --
> Erik Forsberg                 http://efod.se
> GPG/PGP Key: 1024D/0BAC89D9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFFXAHFrJurFAusidkRAgexAJ97CPUVqO62f60cNOU/3qNva17knwCgn1kI
> yW1yFzu2XgrgngLuOfj+dUs=
> =59U4
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061115/051f9c33/attachment.html 

From seefeld at sympatico.ca  Thu Nov 16 13:33:15 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 16 Nov 2006 07:33:15 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87d57nq5oa.fsf_-_@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>
Message-ID: <455C5A8B.1090209@sympatico.ca>

Erik Forsberg wrote:

> Any comments from the rest of the tracker team? Michael? Stefan? Paul?

I think that's OK. Actually, such a discussion could even take place on
the 'real' tracker, assuming there is an appropriate category for it
('infrastructure' / 'tracker'), so the current meta tracker is really
only there for emergency issues, or will be phased out entirely.

Also, I'm not sure whether the process has to be that formal. If there
is a lot of debate about whether or not the wish in question is a good
idea, there obviously needs to be some way to decide, but often a wish
is unanimous, and the only thing holding it back is the lack of time
to implement it. :-)

In a nutshell: whatever works best, I'm fine with it.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Thu Nov 16 13:39:28 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 16 Nov 2006 07:39:28 -0500
Subject: [Tracker-discuss] tracker instance setup
Message-ID: <455C5C00.7030905@sympatico.ca>

Hi there,

what's the status of the server / tracker instance ?
What is holding us back to instantiate the tracker ?

For now I'm running a local copy of the tracker to
see changes I make, but in order to be able to discuss
proposed changes with everyone else we should first
start the real instance, even if we only use fake data.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Thu Nov 16 13:54:54 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 16 Nov 2006 13:54:54 +0100
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <455C5C00.7030905@sympatico.ca>
References: <455C5C00.7030905@sympatico.ca>
Message-ID: <200611161354.54994.forsberg@efod.se>

torsdag 16 november 2006 13:39 skrev Stefan Seefeld:
> Hi there,
>
> what's the status of the server / tracker instance ?
> What is holding us back to instantiate the tracker ?

Nothing. I've been busy with the importer. 

Just do it! :-)

Cheers,
\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Thu Nov 16 14:30:40 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 16 Nov 2006 08:30:40 -0500
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <200611161354.54994.forsberg@efod.se>
References: <455C5C00.7030905@sympatico.ca>
	<200611161354.54994.forsberg@efod.se>
Message-ID: <455C6800.7050401@sympatico.ca>

Erik Forsberg wrote:
> torsdag 16 november 2006 13:39 skrev Stefan Seefeld:
>> Hi there,
>>
>> what's the status of the server / tracker instance ?
>> What is holding us back to instantiate the tracker ?
> 
> Nothing. I've been busy with the importer. 
> 
> Just do it! :-)

Oh, I didn't know the ball was in our camp. :-)
I'll have a try.

Thanks,
		Stefan



-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Thu Nov 16 14:42:45 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 16 Nov 2006 14:42:45 +0100
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <455C6800.7050401@sympatico.ca>
References: <455C5C00.7030905@sympatico.ca>
	<200611161354.54994.forsberg@efod.se>
	<455C6800.7050401@sympatico.ca>
Message-ID: <200611161442.45497.forsberg@efod.se>

torsdag 16 november 2006 14:30 skrev Stefan Seefeld:
> Erik Forsberg wrote:
> > torsdag 16 november 2006 13:39 skrev Stefan Seefeld:
> >> Hi there,
> >>
> >> what's the status of the server / tracker instance ?
> >> What is holding us back to instantiate the tracker ?
> >
> > Nothing. I've been busy with the importer.
> >
> > Just do it! :-)
>
> Oh, I didn't know the ball was in our camp. :-)

Well, I'd say it's not in neither our or upfront's camp, but a little of both. 
That probably explains why it has not been done :-).

> I'll have a try.

Please do. Since the meta tracker is in place, I guess a lot of the 
configuration can just be copy-pasted. 

Cheers,
\EF
-- 
http://efod.se/

From roche at upfrontsystems.co.za  Thu Nov 16 15:10:24 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 16 Nov 2006 16:10:24 +0200
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <455C5C00.7030905@sympatico.ca>
References: <455C5C00.7030905@sympatico.ca>
Message-ID: <1163686224.25620.36.camel@localhost.localdomain>

On Thu, 2006-11-16 at 07:39 -0500, Stefan Seefeld wrote:
> Hi there,
> 
> what's the status of the server / tracker instance ?
> What is holding us back to instantiate the tracker ?

Nothing really, we thought you are still discussing configuration and
schema issues.

> For now I'm running a local copy of the tracker to
> see changes I make, but in order to be able to discuss
> proposed changes with everyone else we should first
> start the real instance, even if we only use fake data.

We'll set up another instance. What must it be called? Will this be
published on a proper python.org URL and email address or should we use
psf.upfronthosting.co.za in the mean time?

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From roche at upfrontsystems.co.za  Thu Nov 16 15:11:47 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 16 Nov 2006 16:11:47 +0200
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <200611161442.45497.forsberg@efod.se>
References: <455C5C00.7030905@sympatico.ca>
	<200611161354.54994.forsberg@efod.se> <455C6800.7050401@sympatico.ca>
	<200611161442.45497.forsberg@efod.se>
Message-ID: <1163686307.25620.39.camel@localhost.localdomain>

On Thu, 2006-11-16 at 14:42 +0100, Erik Forsberg wrote:
> torsdag 16 november 2006 14:30 skrev Stefan Seefeld:
> > Erik Forsberg wrote:
> > > torsdag 16 november 2006 13:39 skrev Stefan Seefeld:
> > >> Hi there,
> > >>
> > >> what's the status of the server / tracker instance ?
> > >> What is holding us back to instantiate the tracker ?
> > >
> > > Nothing. I've been busy with the importer.
> > >
> > > Just do it! :-)
> >
> > Oh, I didn't know the ball was in our camp. :-)
> 
> Well, I'd say it's not in neither our or upfront's camp, but a little of both. 
> That probably explains why it has not been done :-).
> 
> > I'll have a try.
> 
> Please do. Since the meta tracker is in place, I guess a lot of the 
> configuration can just be copy-pasted. 

Eric maybe you can set up the tracker instance and we'll do the postfix
and apache config. Just let us know what it should be.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From forsberg at efod.se  Thu Nov 16 15:36:03 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 16 Nov 2006 15:36:03 +0100
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <1163686224.25620.36.camel@localhost.localdomain>
References: <455C5C00.7030905@sympatico.ca>
	<1163686224.25620.36.camel@localhost.localdomain>
Message-ID: <200611161536.04060.forsberg@efod.se>

torsdag 16 november 2006 15:10 skrev Roch? Compaan:

> > For now I'm running a local copy of the tracker to
> > see changes I make, but in order to be able to discuss
> > proposed changes with everyone else we should first
> > start the real instance, even if we only use fake data.
>
> We'll set up another instance. What must it be called? Will this be
> published on a proper python.org URL and email address or should we use
> psf.upfronthosting.co.za in the mean time?

It's just a temporary tracker for testing, so psf.upfronthosting.co.za is 
fine. 

\Ef
-- 
http://efod.se/

From seefeld at sympatico.ca  Thu Nov 16 15:37:23 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 16 Nov 2006 09:37:23 -0500
Subject: [Tracker-discuss] tracker instance setup
In-Reply-To: <1163686224.25620.36.camel@localhost.localdomain>
References: <455C5C00.7030905@sympatico.ca>
	<1163686224.25620.36.camel@localhost.localdomain>
Message-ID: <455C77A3.2050502@sympatico.ca>

Roch? Compaan wrote:
> On Thu, 2006-11-16 at 07:39 -0500, Stefan Seefeld wrote:
>> Hi there,
>>
>> what's the status of the server / tracker instance ?
>> What is holding us back to instantiate the tracker ?
> 
> Nothing really, we thought you are still discussing configuration and
> schema issues.

Yes, though that discussion will probably go on for a while,
with us reinitializing the tracker with 'roundup-admin initialise'
every now and then.

>> For now I'm running a local copy of the tracker to
>> see changes I make, but in order to be able to discuss
>> proposed changes with everyone else we should first
>> start the real instance, even if we only use fake data.
> 
> We'll set up another instance. What must it be called? Will this be
> published on a proper python.org URL and email address or should we use
> psf.upfronthosting.co.za in the mean time?

Yeah, I think there is no point in adding URL redirection etc.
at this point. It could just be named 'python-dev' or somesuch.
admin mails for this tracker should go somewhere sensibly, i.e.
either this list, or to us four roundup admins.

Can you please set up such a tracker instance, and make it group-writable
for us admins ? As soon as this is done, I can cd there, replace the
relevant files with versions from the subversion repository, and
(re-)initialize the tracker so everybody can see and play with it.


Many thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Fri Nov 17 19:21:06 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 17 Nov 2006 13:21:06 -0500
Subject: [Tracker-discuss] new tracker is up and running, please review !
Message-ID: <455DFD92.8060908@sympatico.ca>

Hello,

the new tracker is now up and running (thanks Izak for
helping me getting started !) at

http://psf.upfronthosting.co.za/roundup/tracker/


You may look at it as anonymous user, or logged in
as 'user' (password: 'user').
Please play around with it (such as create new issues), and
provide feedback.

In order to help guide discussions, please use the meta
tracker to submit feedback.
(http://psf.upfronthosting.co.za/roundup/meta/)

In particular, I'd like to direct your attention to
these issues:

proposed schema changes:

* Add 'milestone' type. (http://psf.upfronthosting.co.za/roundup/meta/issue38)
* Rename 'issue' to 'bug' (http://psf.upfronthosting.co.za/roundup/meta/issue39)
* Add 'type' property to issue (http://psf.upfronthosting.co.za/roundup/meta/issue40)

proposed behavioral changes:

* Create different roles for 'User', 'Developer', and 'Coordinator'.
  (http://psf.upfronthosting.co.za/roundup/meta/issue41)

as these are quite fundamental. I'd like to focus on schema and behavioral
changes first, keeping discussion of html templating and secondary behavioral
changes (what notification is sent out when and to whom) for a later point.

Many thanks !

Have a good weekend,

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Fri Nov 17 20:13:34 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Fri, 17 Nov 2006 11:13:34 -0800
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <455DFD92.8060908@sympatico.ca>
References: <455DFD92.8060908@sympatico.ca>
Message-ID: <f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>

I created an issue as user 'user' but got an error that 'the administrators
have been notified' of.

I gave user 'user' the email address 'bait at pfdubois.com', which is a
black hole that works, so that I can test mailing-detectors such as nosy.

I certainly hate this schema compared to 'classic' Roundup.

On 11/17/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Hello,
>
> the new tracker is now up and running (thanks Izak for
> helping me getting started !) at
>
> http://psf.upfronthosting.co.za/roundup/tracker/
>
>
> You may look at it as anonymous user, or logged in
> as 'user' (password: 'user').
> Please play around with it (such as create new issues), and
> provide feedback.
>
> In order to help guide discussions, please use the meta
> tracker to submit feedback.
> (http://psf.upfronthosting.co.za/roundup/meta/)
>
> In particular, I'd like to direct your attention to
> these issues:
>
> proposed schema changes:
>
> * Add 'milestone' type. (
> http://psf.upfronthosting.co.za/roundup/meta/issue38)
> * Rename 'issue' to 'bug' (
> http://psf.upfronthosting.co.za/roundup/meta/issue39)
> * Add 'type' property to issue (
> http://psf.upfronthosting.co.za/roundup/meta/issue40)
>
> proposed behavioral changes:
>
> * Create different roles for 'User', 'Developer', and 'Coordinator'.
>   (http://psf.upfronthosting.co.za/roundup/meta/issue41)
>
> as these are quite fundamental. I'd like to focus on schema and behavioral
> changes first, keeping discussion of html templating and secondary
> behavioral
> changes (what notification is sent out when and to whom) for a later
> point.
>
> Many thanks !
>
> Have a good weekend,
>
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061117/537a3139/attachment.htm 

From seefeld at sympatico.ca  Fri Nov 17 20:24:41 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 17 Nov 2006 14:24:41 -0500
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
Message-ID: <455E0C79.1050801@sympatico.ca>

Paul Dubois wrote:
> I created an issue as user 'user' but got an error that 'the
> administrators have been notified' of.

Hmm, I don't know who will get this mail right now. Izak, can you tell ?

> I gave user 'user' the email address 'bait at pfdubois.com
> <http://pfdubois.com>', which is a black hole that works, so that I can
> test mailing-detectors such as nosy.
> 
> I certainly hate this schema compared to 'classic' Roundup.

Well, I'm sorry you feel that way, but I don't think this kind of remark
is helpful at all.
Could you be a bit more specific, and add some reasoning ?
Ideally, even using the issues I set up for these discussions in the
meta tracker ?

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Fri Nov 17 20:36:20 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Fri, 17 Nov 2006 21:36:20 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review	!
In-Reply-To: <455E0C79.1050801@sympatico.ca>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
	<455E0C79.1050801@sympatico.ca>
Message-ID: <1163792181.16984.14.camel@kwaaitjie>

On Fri, 2006-11-17 at 14:24 -0500, Stefan Seefeld wrote:
> Paul Dubois wrote:
> > I created an issue as user 'user' but got an error that 'the
> > administrators have been notified' of.
> 
> Hmm, I don't know who will get this mail right now. Izak, can you tell ?

The mail is sent to our sysadmin account for the time being. The mail
indicated their was an error with file permissions which I fixed. Try
now it should work.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Fri Nov 17 20:43:26 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 17 Nov 2006 14:43:26 -0500
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <1163792181.16984.14.camel@kwaaitjie>
References: <455DFD92.8060908@sympatico.ca>	
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>	
	<455E0C79.1050801@sympatico.ca>
	<1163792181.16984.14.camel@kwaaitjie>
Message-ID: <455E10DE.1090502@sympatico.ca>

Roch? Compaan wrote:
> On Fri, 2006-11-17 at 14:24 -0500, Stefan Seefeld wrote:
>> Paul Dubois wrote:
>>> I created an issue as user 'user' but got an error that 'the
>>> administrators have been notified' of.
>> Hmm, I don't know who will get this mail right now. Izak, can you tell ?
> 
> The mail is sent to our sysadmin account for the time being. The mail
> indicated their was an error with file permissions which I fixed. Try
> now it should work.

Could we find a means for others to see such mail, too ? Most of the time
it should be fixable by us roundup admins. Also, what permission problem
was that, if I may ask ? I copied our own tracker files over the
ones Izak set up in his initial install. It may well be that I missed
something. (I'm going to reinitialize the tracker quite frequently over
the next couple of weeks, I believe, so it would be good to know what
potential errors to watch out for.

Thanks,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Fri Nov 17 21:03:47 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Fri, 17 Nov 2006 22:03:47 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review	!
In-Reply-To: <455E10DE.1090502@sympatico.ca>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
	<455E0C79.1050801@sympatico.ca> <1163792181.16984.14.camel@kwaaitjie>
	<455E10DE.1090502@sympatico.ca>
Message-ID: <1163793827.16984.21.camel@kwaaitjie>

On Fri, 2006-11-17 at 14:43 -0500, Stefan Seefeld wrote:
> Roch? Compaan wrote:
> > On Fri, 2006-11-17 at 14:24 -0500, Stefan Seefeld wrote:
> >> Paul Dubois wrote:
> >>> I created an issue as user 'user' but got an error that 'the
> >>> administrators have been notified' of.
> >> Hmm, I don't know who will get this mail right now. Izak, can you tell ?
> > 
> > The mail is sent to our sysadmin account for the time being. The mail
> > indicated their was an error with file permissions which I fixed. Try
> > now it should work.
> 
> Could we find a means for others to see such mail, too ? Most of the time
> it should be fixable by us roundup admins.

No problem, it is done.

>  Also, what permission problem
> was that, if I may ask ? I copied our own tracker files over the
> ones Izak set up in his initial install. It may well be that I missed
> something. (I'm going to reinitialize the tracker quite frequently over
> the next couple of weeks, I believe, so it would be good to know what
> potential errors to watch out for.

The db/files directory did not exist. I created it and gave the group
write permissions and set the sticky bit (g+ws).

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From brett at python.org  Fri Nov 17 22:27:32 2006
From: brett at python.org (Brett Cannon)
Date: Fri, 17 Nov 2006 13:27:32 -0800
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <455DFD92.8060908@sympatico.ca>
References: <455DFD92.8060908@sympatico.ca>
Message-ID: <bbaeab100611171327l25ddaa86l654c1e28fb28d8e7@mail.gmail.com>

On 11/17/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Hello,
>
> the new tracker is now up and running (thanks Izak for
> helping me getting started !) at
>
> http://psf.upfronthosting.co.za/roundup/tracker/
>
>
> You may look at it as anonymous user, or logged in
> as 'user' (password: 'user').
> Please play around with it (such as create new issues), and
> provide feedback.
>
> In order to help guide discussions, please use the meta
> tracker to submit feedback.
> (http://psf.upfronthosting.co.za/roundup/meta/)
>
> In particular, I'd like to direct your attention to
> these issues:
>
> proposed schema changes:
>
> * Add 'milestone' type. (
> http://psf.upfronthosting.co.za/roundup/meta/issue38)
> * Rename 'issue' to 'bug' (
> http://psf.upfronthosting.co.za/roundup/meta/issue39)
> * Add 'type' property to issue (
> http://psf.upfronthosting.co.za/roundup/meta/issue40)
>
> proposed behavioral changes:
>
> * Create different roles for 'User', 'Developer', and 'Coordinator'.
>   (http://psf.upfronthosting.co.za/roundup/meta/issue41)
>
> as these are quite fundamental. I'd like to focus on schema and behavioral
> changes first, keeping discussion of html templating and secondary
> behavioral
> changes (what notification is sent out when and to whom) for a later
> point.
>
> Many thanks !


Are you guys ready for me to try to get more involvement from python-dev in
designing the schema then?

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061117/51c057ab/attachment.html 

From seefeld at sympatico.ca  Fri Nov 17 22:31:14 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Fri, 17 Nov 2006 16:31:14 -0500
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <bbaeab100611171327l25ddaa86l654c1e28fb28d8e7@mail.gmail.com>
References: <455DFD92.8060908@sympatico.ca>
	<bbaeab100611171327l25ddaa86l654c1e28fb28d8e7@mail.gmail.com>
Message-ID: <455E2A22.3020408@sympatico.ca>

Brett Cannon wrote:

> Are you guys ready for me to try to get more involvement from python-dev
> in designing the schema then?


Definitely !

Please invite people to register with the meta-tracker or otherwise
discussions will be anonymous.


Thanks,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From kbk at shore.net  Sat Nov 18 03:40:41 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Fri, 17 Nov 2006 21:40:41 -0500
Subject: [Tracker-discuss] schema ideas
In-Reply-To: <455A1964.2010308@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Tue, 14 Nov 2006 20:30:44 +0100")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <455A0D17.40008@v.loewis.de>
	<455A0EE7.4070801@sympatico.ca> <455A1964.2010308@v.loewis.de>
Message-ID: <87ejs1cw9i.fsf@hydra.bayview.thirdcreek.com>

"Martin v. L?wis" <martin at v.loewis.de> writes:

>>> - weekly summary
>> 
>> That's straight forward to implement with the roundup API.
>> Can you point me to such a summary ? I could add a reporter
>> script that does the same with the new tracker.
>
> http://mail.python.org/pipermail/python-dev/2006-November/069909.html
>
> I think Kurt (B. Kaiser) can provide the source code of the
> current script if desired. Notice that it also uses the
> SF redirector (I keep mentioning it because it's my doing :-)

Since the code will diverge dramatically and there may be others on
SF who might like to use it as is, I've created a SF project and
uploaded the current code under the Python license.

http://sourceforge.net/projects/tracker-report/

I see Paul Dubois is going to take this on.

-- 
KBK

From izak at upfrontsystems.co.za  Sat Nov 18 07:45:02 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sat, 18 Nov 2006 08:45:02 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <1163792181.16984.14.camel@kwaaitjie>
References: <455DFD92.8060908@sympatico.ca>	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>	<455E0C79.1050801@sympatico.ca>
	<1163792181.16984.14.camel@kwaaitjie>
Message-ID: <455EABEE.4080101@upfrontsystems.co.za>

Roch? Compaan wrote:
> The mail is sent to our sysadmin account for the time being. The mail
> indicated their was an error with file permissions which I fixed. Try
> now it should work.

Thanks Roch?.  I did set the permissions g+ws on db/files yesterday.  I 
think we probably need the os.umask(002) trick.


From izak at upfrontsystems.co.za  Sat Nov 18 07:50:11 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sat, 18 Nov 2006 08:50:11 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <1163793827.16984.21.camel@kwaaitjie>
References: <455DFD92.8060908@sympatico.ca>	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>	<455E0C79.1050801@sympatico.ca>
	<1163792181.16984.14.camel@kwaaitjie>	<455E10DE.1090502@sympatico.ca>
	<1163793827.16984.21.camel@kwaaitjie>
Message-ID: <455EAD23.7080808@upfrontsystems.co.za>

Roch? Compaan wrote:
> The db/files directory did not exist. I created it and gave the group
> write permissions and set the sticky bit (g+ws).

Aaah yes.  I noticed yesterday after doing roundup-admin initialise that 
db/files didn't exist, so I created it (I figured it will possibly be 
created when the first email submissions arrives but did not want to 
wait that long).  If Stefan copied files over it it is quite likely that 
it was accidently removed again.

I suppose I could implement the umask setting in the mta.  I know how to 
do this for exim (you just set it in the router definition) but give me 
a second to figure it out for postfix.

Cheers,
Izak

From izak at upfrontsystems.co.za  Sat Nov 18 08:07:09 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sat, 18 Nov 2006 09:07:09 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <455EAD23.7080808@upfrontsystems.co.za>
References: <455DFD92.8060908@sympatico.ca>	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>	<455E0C79.1050801@sympatico.ca>	<1163792181.16984.14.camel@kwaaitjie>	<455E10DE.1090502@sympatico.ca>	<1163793827.16984.21.camel@kwaaitjie>
	<455EAD23.7080808@upfrontsystems.co.za>
Message-ID: <455EB11D.7050404@upfrontsystems.co.za>

Izak Burger wrote:
> I suppose I could implement the umask setting in the mta.  I know how to 
> do this for exim (you just set it in the router definition) but give me 
> a second to figure it out for postfix.

Seems postfix cannot be configured to do this.  If we want the umask to 
be 002 we'll have to set it in the script.

regards,
Izak

From roche at upfrontsystems.co.za  Sat Nov 18 08:20:29 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 18 Nov 2006 09:20:29 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review	!
In-Reply-To: <455EB11D.7050404@upfrontsystems.co.za>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
	<455E0C79.1050801@sympatico.ca>	<1163792181.16984.14.camel@kwaaitjie>
	<455E10DE.1090502@sympatico.ca>	<1163793827.16984.21.camel@kwaaitjie>
	<455EAD23.7080808@upfrontsystems.co.za>
	<455EB11D.7050404@upfrontsystems.co.za>
Message-ID: <1163834430.16984.54.camel@kwaaitjie>

On Sat, 2006-11-18 at 09:07 +0200, Izak Burger wrote:
> Izak Burger wrote:
> > I suppose I could implement the umask setting in the mta.  I know how to 
> > do this for exim (you just set it in the router definition) but give me 
> > a second to figure it out for postfix.
> 
> Seems postfix cannot be configured to do this.  If we want the umask to 
> be 002 we'll have to set it in the script.

This is not really a Postfix problem but an Apache one. Since Postfix
can easily deliver the mail as the roundup user it will have no problem
creating that directory if the first post was done by mail.

If the first issue is created through the web, Apache will not have the
permission to create this directory since it is only in the roundup
group. So it is really a configuration error.

That aside, I really don't like the fact that CGI's under Apache can't
run as a different user - it's damn frustrating and causes stupid
permission settings that is simply not secure. Hence we run roundup
server - maybe it's time to do a proper benchmark to see if the
mod_python version is really faster than roundup server.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From izak at upfrontsystems.co.za  Sat Nov 18 10:09:13 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Sat, 18 Nov 2006 11:09:13 +0200
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <1163834430.16984.54.camel@kwaaitjie>
References: <455DFD92.8060908@sympatico.ca>	
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>	
	<455E0C79.1050801@sympatico.ca>	<1163792181.16984.14.camel@kwaaitjie>	
	<455E10DE.1090502@sympatico.ca>	<1163793827.16984.21.camel@kwaaitjie>	
	<455EAD23.7080808@upfrontsystems.co.za>	
	<455EB11D.7050404@upfrontsystems.co.za>
	<1163834430.16984.54.camel@kwaaitjie>
Message-ID: <455ECDB9.7000009@upfrontsystems.co.za>

Roch? Compaan wrote:
> This is not really a Postfix problem but an Apache one. 

Agreed, but let me phrase it differently.  Not being able to set the 
umask can be seen as a postfix problem (compared to exim which can set 
it), but in this case it isn't really postfix's job to solve the problem 
created by another program so my criticism doesn't really apply :-)

> That aside, I really don't like the fact that CGI's under Apache can't
> run as a different user - it's damn frustrating and causes stupid
> permission settings that is simply not secure. Hence we run roundup
> server - maybe it's time to do a proper benchmark to see if the
> mod_python version is really faster than roundup server.

The setup I tried earlier was to use apache in a setup similar to a 
mod_python setup, but instead of passing the dynamic queries to 
mod_python, I proxy them through to roundup-server.  Performance should 
be very similar as far as I can see, I really just replaced the part 
that does the actual python interpretation.  I think mod_python might 
still win because of the overhead of an additional tcp connection when 
proxying from apache to the backend roundup-server, but perhaps the 
advantages to be had because of the improved security might make it 
worth it.

regards,
Izak

From skip at pobox.com  Sat Nov 18 16:28:41 2006
From: skip at pobox.com (Skip Montanaro)
Date: Sat, 18 Nov 2006 09:28:41 -0600
Subject: [Tracker-discuss] new tracker is up and running,
	please review     !
In-Reply-To: <1163792181.16984.14.camel@kwaaitjie>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
	<455E0C79.1050801@sympatico.ca>
	<1163792181.16984.14.camel@kwaaitjie>
Message-ID: <17759.9897.46076.712291@montanaro.dyndns.org>

    >> > I created an issue as user 'user' but got an error that 'the
    >> > administrators have been notified' of.
    >> 
    >> Hmm, I don't know who will get this mail right now. Izak, can you
    >> tell ?

    Roch??> The mail is sent to our sysadmin account for the time being. The
    Roch??> mail indicated their was an error with file permissions which I
    Roch??> fixed. Try now it should work.

Worked for me...

Skip

From pfdubois at gmail.com  Sat Nov 18 17:17:41 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 18 Nov 2006 08:17:41 -0800
Subject: [Tracker-discuss] new tracker is up and running, please review !
In-Reply-To: <17759.9897.46076.712291@montanaro.dyndns.org>
References: <455DFD92.8060908@sympatico.ca>
	<f74a6c2f0611171113q676d39d9w5b2d60c36f94b441@mail.gmail.com>
	<455E0C79.1050801@sympatico.ca> <1163792181.16984.14.camel@kwaaitjie>
	<17759.9897.46076.712291@montanaro.dyndns.org>
Message-ID: <f74a6c2f0611180817j61d2da6ahcea18bd44495f517@mail.gmail.com>

It is ok now. I had the same experience once, with a new tracker not
creating the files directory, and I was running the roundup server with
Apache proxy, not mod_python.  In my case it was caused by a mail submission
and I didn't have the mail user in the roundup group or something like that.


I think that the roundup server / Apache proxy-pass setup does have the
advantage that one never again needs to get into the Apache space and can
just be an 'ordinary' user after that. (I like having a fake user that we
all sudo to, and having it 'own' roundup.)

 But I know nothing about performance.

On 11/18/06, Skip Montanaro <skip at pobox.com> wrote:
>
>     >> > I created an issue as user 'user' but got an error that 'the
>     >> > administrators have been notified' of.
>     >>
>     >> Hmm, I don't know who will get this mail right now. Izak, can you
>     >> tell ?
>
>     Roch?> The mail is sent to our sysadmin account for the time being.
> The
>     Roch?> mail indicated their was an error with file permissions which I
>     Roch?> fixed. Try now it should work.
>
> Worked for me...
>
> Skip
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061118/79e85729/attachment.htm 

From brett at python.org  Sat Nov 18 22:02:16 2006
From: brett at python.org (Brett Cannon)
Date: Sat, 18 Nov 2006 13:02:16 -0800
Subject: [Tracker-discuss] discussion of schema for new issue tracker
	starting
Message-ID: <bbaeab100611181302u73976bacm862a0f727eef05cc@mail.gmail.com>

Discussion of what we want in terms of the schema for the new issue tracker
has begun.  If you wish to give feedback on what you would like each issue
to have in terms of data then please file an issue in the meta tracker at
http://psf.upfronthosting.co.za/roundup/meta/ .  You can see the current
test tracker at http://psf.upfronthosting.co.za/roundup/tracker/ .  And the
tracker-discuss mailing list is at
http://mail.python.org/mailman/listinfo/tracker-discuss (although you can
bypass the list and use the meta tracker to your ideas relating to the
schema).

If you do participate through the meta tracker please sign up for an account
so that it is not anonymous.  I really hope that Anthony and Neal can
participate so that we can make sure the tracker does what they need to make
their lives easier during a release.  And obviously everyone who still works
with bugs and patches should participate as well.  We can change the schema
even after we launch to the new tracker, but it would be nice to minimize
the amount of feature churn once the tracker is up and going.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061118/95531b46/attachment.htm 

From pfdubois at gmail.com  Sun Nov 19 21:29:17 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 19 Nov 2006 12:29:17 -0800
Subject: [Tracker-discuss] instructions for modifying tracker?
Message-ID: <f74a6c2f0611191229q6442f5f2hff716bf30b86108c@mail.gmail.com>

Perhaps I missed it; if so, sorry. How do I work on the present tracker  and
metatracker, such as adding a detector to test it? I need to know whether or
not to sudo to some special user, and where the files are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061119/14a14784/attachment.html 

From seefeld at sympatico.ca  Sun Nov 19 21:38:45 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 19 Nov 2006 15:38:45 -0500
Subject: [Tracker-discuss] instructions for modifying tracker?
In-Reply-To: <f74a6c2f0611191229q6442f5f2hff716bf30b86108c@mail.gmail.com>
References: <f74a6c2f0611191229q6442f5f2hff716bf30b86108c@mail.gmail.com>
Message-ID: <4560C0D5.5090904@sympatico.ca>

Paul Dubois wrote:
> Perhaps I missed it; if so, sorry. How do I work on the present tracker 
> and metatracker, such as adding a detector to test it? I need to know
> whether or not to sudo to some special user, and where the files are.

The trackers are in /home/roundup/trackers, owned by roundup:roundup,
so to make any modifications you have to 'sudo -u roundup'.

However, I'd like to ask people to refrain from using the live tracker
to test features. What I do is to use a local clone of the tracker
(checked out from subversion, instantiated with roundup-admin as usual),
and do may playing around and testing here.
Only once I'm sure it works do I make a patch and submit it, or update
the live tracker for others to see the change I have made.

Kind regards,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Tue Nov 21 16:12:41 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 21 Nov 2006 10:12:41 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87d57nq5oa.fsf_-_@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>
Message-ID: <45631769.6020200@sympatico.ca>

Hi there,

we have been discussing various possible changes to the tracker
prototype, some of which already made it into the current version.

However, up to now there has been very little feedback from those
people most affected by all this.

Thus I wonder:

* What time scale should we expect this whole migration to take to
  move forward ? Would it make sense to set up a time frame to not
  let this drag on for too long ?

* I have made various fine-grained change proposals on the meta
  tracker. Would it be more efficient I made an overall proposal
  that allows to think in terms of the 'big picture', instead of
  piece meal changes ? (Many suggested changes only make sense
  in the context of other changes, so discussing them independently
  may not be very useful.)

* What exactly do we need in order to consider a change to be
  approved ?


While I realize that everybody is busy with his own work, I believe
it would be most efficient if we could have a concentrated effort
at least to define what we want, as opposed to letting discussions
drag on for a long time.
Having to re-read old mails every so often just to swap in the context
to work on these tasks makes life unnecessarily hard.

Many thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Tue Nov 21 20:03:44 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 21 Nov 2006 20:03:44 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45631769.6020200@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca>
Message-ID: <45634D90.8060806@v.loewis.de>

Stefan Seefeld schrieb:
> * What time scale should we expect this whole migration to take to
>   move forward ? Would it make sense to set up a time frame to not
>   let this drag on for too long ?

I think so. Some people (GvR in particular) have been asking why
this isn't completed, yet.

It would be good if it completed this year.

> * I have made various fine-grained change proposals on the meta
>   tracker. Would it be more efficient I made an overall proposal
>   that allows to think in terms of the 'big picture', instead of
>   piece meal changes ?

I think people won't respond at all to tracker schema changes,
no matter how much feedback you request. Instead, they want to
see the complete solution, life.

> * What exactly do we need in order to consider a change to be
>   approved ?

The tracker team can do whatever they want, IMO. The infrastructure
committee should back them up and support them as long as we had a
chance to comment.

Regards,
Martin

From brett at python.org  Tue Nov 21 20:54:01 2006
From: brett at python.org (Brett Cannon)
Date: Tue, 21 Nov 2006 11:54:01 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45634D90.8060806@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
Message-ID: <bbaeab100611211154p1bcb845ek62b47c488bdb6ae7@mail.gmail.com>

On 11/21/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Stefan Seefeld schrieb:
> > * What time scale should we expect this whole migration to take to
> >   move forward ? Would it make sense to set up a time frame to not
> >   let this drag on for too long ?
>
> I think so. Some people (GvR in particular) have been asking why
> this isn't completed, yet.
>
> It would be good if it completed this year.


Ditto from me.  This might be a situation where people just want it done and
don't care about the final solution since it is better than what we have
now.

> * I have made various fine-grained change proposals on the meta
> >   tracker. Would it be more efficient I made an overall proposal
> >   that allows to think in terms of the 'big picture', instead of
> >   piece meal changes ?
>
> I think people won't respond at all to tracker schema changes,
> no matter how much feedback you request. Instead, they want to
> see the complete solution, life.


I bet if you make the initial changes to what you think is reasonable based
on any suggestions people make, we can then say, "here is the rough draft of
the tracker; make comments now before we push out the first version
publicly".  That should light some fires under people.  Plus it gives
everyone something concrete to play with.

In other words, take the current ideas, implement them in a schema, push it
to the test tracker, and we can play with it a little and give feedback.
With that done, we then make the tweaks and do the switch.  After that we
can make gradual changes.  I am sure people will come to realize that
certain things are needed as time goes on and people have more experience
with the tracker.

> * What exactly do we need in order to consider a change to be
> >   approved ?
>
> The tracker team can do whatever they want, IMO. The infrastructure
> committee should back them up and support them as long as we had a
> chance to comment.


Same from me.  Basically you guys present to us what you got, we comment,
and then was fix and go.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061121/e2ebb88c/attachment.html 

From seefeld at sympatico.ca  Tue Nov 21 21:11:22 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 21 Nov 2006 15:11:22 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45634D90.8060806@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
Message-ID: <45635D6A.4060509@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> * What time scale should we expect this whole migration to take to
>>   move forward ? Would it make sense to set up a time frame to not
>>   let this drag on for too long ?
> 
> I think so. Some people (GvR in particular) have been asking why
> this isn't completed, yet.
> 
> It would be good if it completed this year.

I agree that would be good, and I think it is possible, at least
technically.

>> * I have made various fine-grained change proposals on the meta
>>   tracker. Would it be more efficient I made an overall proposal
>>   that allows to think in terms of the 'big picture', instead of
>>   piece meal changes ?
> 
> I think people won't respond at all to tracker schema changes,
> no matter how much feedback you request. Instead, they want to
> see the complete solution, life.
> 
>> * What exactly do we need in order to consider a change to be
>>   approved ?
> 
> The tracker team can do whatever they want, IMO. The infrastructure
> committee should back them up and support them as long as we had a
> chance to comment.

OK, fair enough. So, let me present a little hand-drawn schema I'm aiming
for, with some comments. The goal is to allow users to report bugs with
as much detail as possible, without getting into their way. All properties
are typed (i.e. use links to predefined entities), instead of simple strings,
to avoid typos and make querying easier.

Roundup's permission handling, together with auditors, should help us
keeping the workflow / bug lifetime streamlined, i.e. make it obvious to
everybody what the potential state transitions are.


Schema
------

bug = (title,
       messages,
       files,
       type,
       components,
       platforms,
       version,
       severity,
       dependencies,
       status,
       resolution,
       superseder)

pep = (title, messages, files, ...)

milestone = (name, messages, eta, bugs, peps)


Comments:

* type is an enum helping to classify the bug. For example:
  (crash, compile error, resource usage, security, rendering, behavior, rfe)

* components expresses what parts are affected

* platforms expresses what platforms are affected

* version is an enum to express the python version (or branch) the problem
  occured in.

* severity is an enum allowing users to express the impact the bug has on them,
  such as: (critical, major, normal, minor)

* dependencies: a list of bugs that need to be fixed before this can be fixed.

* status: one of (new, open, closed)

* resolution, set when status is set to closed: one of (fixed, invalid, duplicate)

* superseder: a follow-up bug, if resolution is set to duplicate.

* milestone is an issue type useful for release management. With it it is
  possible to query for bugs / peps to be closed for a given point (release / time)

* pep is a placeholder for PEPs, just to illustrate that this tracker can grow. :-)


Access
------

Users submit bugs, setting title, and optionally components, platforms, version,
and severity.

Developers set assignee, status, resolution, dependencies, and superseder.

Conversion
----------

Conversion from sf.net should map 'category' to 'components',
and 'group' to 'version'.



If there are no objections, I'm going to start to implement it.

Comments ?
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Tue Nov 21 21:27:12 2006
From: brett at python.org (Brett Cannon)
Date: Tue, 21 Nov 2006 12:27:12 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45635D6A.4060509@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca>
Message-ID: <bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>

On 11/21/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Martin v. L?wis wrote:
> > Stefan Seefeld schrieb:
> >> * What time scale should we expect this whole migration to take to
> >>   move forward ? Would it make sense to set up a time frame to not
> >>   let this drag on for too long ?
> >
> > I think so. Some people (GvR in particular) have been asking why
> > this isn't completed, yet.
> >
> > It would be good if it completed this year.
>
> I agree that would be good, and I think it is possible, at least
> technically.
>
> >> * I have made various fine-grained change proposals on the meta
> >>   tracker. Would it be more efficient I made an overall proposal
> >>   that allows to think in terms of the 'big picture', instead of
> >>   piece meal changes ?
> >
> > I think people won't respond at all to tracker schema changes,
> > no matter how much feedback you request. Instead, they want to
> > see the complete solution, life.
> >
> >> * What exactly do we need in order to consider a change to be
> >>   approved ?
> >
> > The tracker team can do whatever they want, IMO. The infrastructure
> > committee should back them up and support them as long as we had a
> > chance to comment.
>
> OK, fair enough. So, let me present a little hand-drawn schema I'm aiming
> for, with some comments. The goal is to allow users to report bugs with
> as much detail as possible, without getting into their way. All properties
> are typed (i.e. use links to predefined entities), instead of simple
> strings,
> to avoid typos and make querying easier.
>
> Roundup's permission handling, together with auditors, should help us
> keeping the workflow / bug lifetime streamlined, i.e. make it obvious to
> everybody what the potential state transitions are.
>
>
> Schema
> ------
>
> bug = (title,
>        messages,
>        files,
>        type,
>        components,
>        platforms,
>        version,
>        severity,
>        dependencies,
>        status,
>        resolution,
>        superseder)
>
> pep = (title, messages, files, ...)
>
> milestone = (name, messages, eta, bugs, peps)
>
>
> Comments:
>
> * type is an enum helping to classify the bug. For example:
>   (crash, compile error, resource usage, security, rendering, behavior,
> rfe)
>
> * components expresses what parts are affected
>
> * platforms expresses what platforms are affected
>
> * version is an enum to express the python version (or branch) the problem
>   occured in.


Is this a single setting, or can it have multiple values?  If we
automatically close old bugs, it might get us to deal with things faster and
thus we won't have bugs from a couple versions back.  But otherwise we can
end up with bugs where they are present in 2.3 and people need an easy way
to note that it is still present in 2.5, etc.

This also brings up the idea of having a dependency field.  If I am waiting
for feedback or more details from someone, set that field to their
username.  If I don't here from them after a set amount of time (like two
weeks) the bug gets closed automatically for lack of information.

* severity is an enum allowing users to express the impact the bug has on
> them,
>   such as: (critical, major, normal, minor)
>
> * dependencies: a list of bugs that need to be fixed before this can be
> fixed.
>
> * status: one of (new, open, closed)
>
> * resolution, set when status is set to closed: one of (fixed, invalid,
> duplicate)


Also add "Lack of Info" or something since we end up with bugs that just sit
there waiting for more info from the OP that we never get.

* superseder: a follow-up bug, if resolution is set to duplicate.
>
> * milestone is an issue type useful for release management. With it it is
>   possible to query for bugs / peps to be closed for a given point
> (release / time)


So like showstopper, A1, B2, etc.?  That way one can specify that this bug
must be closed by that point or else the release is blocked?

* pep is a placeholder for PEPs, just to illustrate that this tracker can
> grow. :-)


=)

Access
> ------
>
> Users submit bugs, setting title, and optionally components, platforms,
> version,
> and severity.


Don't let them set severity.  I have gotten into mini competitions with OPs
over resetting the severity.  They think they know better than me what is
severe and what isn't.  And everyone's bug to them is severe.  =)

Developers set assignee, status, resolution, dependencies, and superseder.
>
> Conversion
> ----------
>
> Conversion from sf.net should map 'category' to 'components',
> and 'group' to 'version'.
>
>
>
> If there are no objections, I'm going to start to implement it.
>
> Comments ?


Any way to flag that a patch might be ripe for backporting?  Sometimes
people fix stuff in svn but don't have the time or inclination to backport,
so it can get lost (people are supposed to note it in Misc/NEWS, but that is
really the wrong place to denote it).  If there was a way to close a bug and
flag it as needs backporting (or have a "Backport" resolution) that would
help matters.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061121/afecb275/attachment-0001.htm 

From seefeld at sympatico.ca  Tue Nov 21 21:42:47 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Tue, 21 Nov 2006 15:42:47 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>	
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>	
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>	
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>	
	<45635D6A.4060509@sympatico.ca>
	<bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
Message-ID: <456364C7.606@sympatico.ca>

Brett Cannon wrote:

>     * version is an enum to express the python version (or branch) the
>     problem
>       occured in.
> 
> 
> Is this a single setting, or can it have multiple values?  If we
> automatically close old bugs, it might get us to deal with things faster
> and thus we won't have bugs from a couple versions back.  But otherwise
> we can end up with bugs where they are present in 2.3 and people need an
> easy way to note that it is still present in 2.5, etc.

Good point. It certainly can be a multilink, i.e. refer to multiple
versions / branches. (An interesting side-note: if we hook up with
subversion, we probably want to track changes to individual branches
and only close out the parts of a bug that got affected by a checkin.)

> This also brings up the idea of having a dependency field.  If I am
> waiting for feedback or more details from someone, set that field to
> their username.  If I don't here from them after a set amount of time
> (like two weeks) the bug gets closed automatically for lack of information.

Right. I think there can be a status enumerator for this state, together
with a timer that gets started whenever that state is entered.

> 
>     * severity is an enum allowing users to express the impact the bug
>     has on them,
>       such as: (critical, major, normal, minor)
> 
>     * dependencies: a list of bugs that need to be fixed before this can
>     be fixed.
> 
>     * status: one of (new, open, closed)
> 
>     * resolution, set when status is set to closed: one of (fixed,
>     invalid, duplicate) 
> 
> 
> Also add "Lack of Info" or something since we end up with bugs that just
> sit there waiting for more info from the OP that we never get.

Good point. Wouldn't that be the same status enumerator as above
(or at least, very similar) ?

> 
>     * superseder: a follow-up bug, if resolution is set to duplicate.
> 
>     * milestone is an issue type useful for release management. With it
>     it is
>       possible to query for bugs / peps to be closed for a given point
>     (release / time) 
> 
> 
> So like showstopper, A1, B2, etc.?  That way one can specify that this
> bug must be closed by that point or else the release is blocked?

Right. However, that would be an attribute of the milestone -> bugs link,
not the bug itself. The bug itself doesn't care that a milestone is on hold
for it. :-)

>     * pep is a placeholder for PEPs, just to illustrate that this
>     tracker can grow. :-)
> 
> 
> =)
> 
>     Access
>     ------
> 
>     Users submit bugs, setting title, and optionally components,
>     platforms, version,
>     and severity.
> 
> 
> Don't let them set severity.  I have gotten into mini competitions with
> OPs over resetting the severity.  They think they know better than me
> what is severe and what isn't.  And everyone's bug to them is severe.  =)

I guess that's your call. I have made good experience with such a flag.
And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)

>     Developers set assignee, status, resolution, dependencies, and
>     superseder.
> 
>     Conversion
>     ----------
> 
>     Conversion from sf.net <http://sf.net> should map 'category' to
>     'components',
>     and 'group' to 'version'.
> 
> 
> 
>     If there are no objections, I'm going to start to implement it.
> 
>     Comments ?
> 
> 
> Any way to flag that a patch might be ripe for backporting?  Sometimes
> people fix stuff in svn but don't have the time or inclination to
> backport, so it can get lost (people are supposed to note it in
> Misc/NEWS, but that is really the wrong place to denote it).  If there
> was a way to close a bug and flag it as needs backporting (or have a
> "Backport" resolution) that would help matters.

That sounds like something for for a roundup script, where a new bug
is created by cloning an old one, but attached to a different branch / version.
Or somesuch.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Tue Nov 21 22:12:26 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Tue, 21 Nov 2006 13:12:26 -0800
Subject: [Tracker-discuss] Generating reports from the database
Message-ID: <f74a6c2f0611211312s1f25a5faj6e7547b57ef509b5@mail.gmail.com>

I'm helping with the conversion of the Python tracker to Roundup. One of the
side tasks they do now is use a script to generate a report on the number of
open bugs and those issues that have been opened, closed, etc. since the
last (weekly) report. They do this mostly by generating an email to an
account with each issue change and they parse that email.

That's possible for Roundup but it seems like an odd solution to me. Other
ways I can think of: a Roundup detector that writes the summary as it goes
along, and / or a Python script that generates the report using database
queries, or in the case of something like postgresql, using some report
generating capability in the database itself. I'm not a database guy, so I'm
unsure about the difficulty, performance, etc.

Any thoughts? Somebody please write and tell me you already have one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061121/fe4cdcbf/attachment.htm 

From nnorwitz at gmail.com  Wed Nov 22 06:17:46 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Tue, 21 Nov 2006 21:17:46 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456364C7.606@sympatico.ca>
References: <455891F0.2050209@sympatico.ca> <87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de> <87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se> <45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de> <45635D6A.4060509@sympatico.ca>
	<bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
	<456364C7.606@sympatico.ca>
Message-ID: <ee2a432c0611212117n41adbda7w7aad73d275722854@mail.gmail.com>

Thanks for your collective efforts to get this working.  It would be a
bit easier for me to comment with the DB loaded up, but I have some
meta & concrete comments.
There are a bunch, I'll try to prioritize some.  The general ones are
probably more important to me than some of the details.  I also think
it's important to get this out sooner rather than later.

The tracker should be much simpler (less options) than it currently
has.  It seems that your proposed schema does a bunch of this.  I want
to see something as simple as possible.  I haven't used the version of
the bug tracker on code.google.com, but I was involved with the
original design.  I like that it's minimal, but still powerful.

The Issues link in the left nav bar should maintain the existing
settings that people have for sorting and grouping.  Only minimal
fields should be sortable/groupable.  We can add more later.  Make
this as simple as possible for users.  If we find we need more we can
add it later.  It will be harder to remove funcationality.  (Basically
be agile and add only the features that people request.)

I'd like to be able to add a new bug easily.  It shouldn't require a
login, though we should always capture an email addr.  Make it a one
step process so people don't get put off creating bug reports.

The search box in the upper right should be labeled that it will
search for issues.  I wasn't sure if it was a general Google search or
specific to the issues without trying it.

I didn't like that grouping took priority over sorting, but sorting is
displayed above grouping.  I'd rather only sort/group by a single
column.  I'd like to see the download to CSV moved elsewhere.  It will
rarely be viewed, but we will always have to look at it.  Grouping on
things like time doesn't make sense, although sorting on time does.

I'd like a lot of flexibility in grouping bug reports together.  This
is where a feature like Google's labels make a lot of sense.  I'd like
to be able to add a bunch of labels to bug reports.  The reason for
this is that no one can handle 900 bug reports.  But they can handle
5.  I want to make it easy to display those 5.  Many bug reports are
focused in a handful of places, some specific modules, doc, o/s
specific etc.  I want to be able to easily filter however I'd like.
The only way I can think of to do that is with labels.

Ideally I would be able to sort by clicking on the column heading
rather than change an option menu and click redisplay.  I would like
to be able change/reorder the columns shown.  I would like to be able
to star issues.  (It could just display a star if I'm on the nosy
list.)

I would like the entire row to be highlighted if I moused over it and
be able to click anywhere in the row to view the details of an issue.

I realize a bunch of these are how roundup is currently implemented,
but I'd like to be able to easily find any subset of issues and track
them.  SF doesn't give me an easy way to do that.  If I change a
viewing preference, it's sticky and I have to change it later.  I want
to have a bunch of different views I can easily go between depending
on what I'm working on.

Hope this helps and doesn't scare you away. :-)

n
--
On 11/21/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Brett Cannon wrote:
>
> >     * version is an enum to express the python version (or branch) the
> >     problem
> >       occured in.
> >
> >
> > Is this a single setting, or can it have multiple values?  If we
> > automatically close old bugs, it might get us to deal with things faster
> > and thus we won't have bugs from a couple versions back.  But otherwise
> > we can end up with bugs where they are present in 2.3 and people need an
> > easy way to note that it is still present in 2.5, etc.
>
> Good point. It certainly can be a multilink, i.e. refer to multiple
> versions / branches. (An interesting side-note: if we hook up with
> subversion, we probably want to track changes to individual branches
> and only close out the parts of a bug that got affected by a checkin.)
>
> > This also brings up the idea of having a dependency field.  If I am
> > waiting for feedback or more details from someone, set that field to
> > their username.  If I don't here from them after a set amount of time
> > (like two weeks) the bug gets closed automatically for lack of information.
>
> Right. I think there can be a status enumerator for this state, together
> with a timer that gets started whenever that state is entered.
>
> >
> >     * severity is an enum allowing users to express the impact the bug
> >     has on them,
> >       such as: (critical, major, normal, minor)
> >
> >     * dependencies: a list of bugs that need to be fixed before this can
> >     be fixed.
> >
> >     * status: one of (new, open, closed)
> >
> >     * resolution, set when status is set to closed: one of (fixed,
> >     invalid, duplicate)
> >
> >
> > Also add "Lack of Info" or something since we end up with bugs that just
> > sit there waiting for more info from the OP that we never get.
>
> Good point. Wouldn't that be the same status enumerator as above
> (or at least, very similar) ?
>
> >
> >     * superseder: a follow-up bug, if resolution is set to duplicate.
> >
> >     * milestone is an issue type useful for release management. With it
> >     it is
> >       possible to query for bugs / peps to be closed for a given point
> >     (release / time)
> >
> >
> > So like showstopper, A1, B2, etc.?  That way one can specify that this
> > bug must be closed by that point or else the release is blocked?
>
> Right. However, that would be an attribute of the milestone -> bugs link,
> not the bug itself. The bug itself doesn't care that a milestone is on hold
> for it. :-)
>
> >     * pep is a placeholder for PEPs, just to illustrate that this
> >     tracker can grow. :-)
> >
> >
> > =)
> >
> >     Access
> >     ------
> >
> >     Users submit bugs, setting title, and optionally components,
> >     platforms, version,
> >     and severity.
> >
> >
> > Don't let them set severity.  I have gotten into mini competitions with
> > OPs over resetting the severity.  They think they know better than me
> > what is severe and what isn't.  And everyone's bug to them is severe.  =)
>
> I guess that's your call. I have made good experience with such a flag.
> And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)
>
> >     Developers set assignee, status, resolution, dependencies, and
> >     superseder.
> >
> >     Conversion
> >     ----------
> >
> >     Conversion from sf.net <http://sf.net> should map 'category' to
> >     'components',
> >     and 'group' to 'version'.
> >
> >
> >
> >     If there are no objections, I'm going to start to implement it.
> >
> >     Comments ?
> >
> >
> > Any way to flag that a patch might be ripe for backporting?  Sometimes
> > people fix stuff in svn but don't have the time or inclination to
> > backport, so it can get lost (people are supposed to note it in
> > Misc/NEWS, but that is really the wrong place to denote it).  If there
> > was a way to close a bug and flag it as needs backporting (or have a
> > "Backport" resolution) that would help matters.
>
> That sounds like something for for a roundup script, where a new bug
> is created by cloning an old one, but attached to a different branch / version.
> Or somesuch.
>
> Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From brett at python.org  Wed Nov 22 18:37:53 2006
From: brett at python.org (Brett Cannon)
Date: Wed, 22 Nov 2006 09:37:53 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456364C7.606@sympatico.ca>
References: <455891F0.2050209@sympatico.ca> <87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de> <87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se> <45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de> <45635D6A.4060509@sympatico.ca>
	<bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
	<456364C7.606@sympatico.ca>
Message-ID: <bbaeab100611220937m6caeba05v3dcfcb1c42e91689@mail.gmail.com>

On 11/21/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Brett Cannon wrote:
>
> >     * version is an enum to express the python version (or branch) the
> >     problem
> >       occured in.
> >
> >
> > Is this a single setting, or can it have multiple values?  If we
> > automatically close old bugs, it might get us to deal with things faster
> > and thus we won't have bugs from a couple versions back.  But otherwise
> > we can end up with bugs where they are present in 2.3 and people need an
> > easy way to note that it is still present in 2.5, etc.
>
> Good point. It certainly can be a multilink, i.e. refer to multiple
> versions / branches. (An interesting side-note: if we hook up with
> subversion, we probably want to track changes to individual branches
> and only close out the parts of a bug that got affected by a checkin.)
>
> > This also brings up the idea of having a dependency field.  If I am
> > waiting for feedback or more details from someone, set that field to
> > their username.  If I don't here from them after a set amount of time
> > (like two weeks) the bug gets closed automatically for lack of
> information.
>
> Right. I think there can be a status enumerator for this state, together
> with a timer that gets started whenever that state is entered.
>
> >
> >     * severity is an enum allowing users to express the impact the bug
> >     has on them,
> >       such as: (critical, major, normal, minor)
> >
> >     * dependencies: a list of bugs that need to be fixed before this can
> >     be fixed.
> >
> >     * status: one of (new, open, closed)
> >
> >     * resolution, set when status is set to closed: one of (fixed,
> >     invalid, duplicate)
> >
> >
> > Also add "Lack of Info" or something since we end up with bugs that just
> > sit there waiting for more info from the OP that we never get.
>
> Good point. Wouldn't that be the same status enumerator as above
> (or at least, very similar) ?


Yes.  I put it in just in case the previous idea didn't work.

>
> >     * superseder: a follow-up bug, if resolution is set to duplicate.
> >
> >     * milestone is an issue type useful for release management. With it
> >     it is
> >       possible to query for bugs / peps to be closed for a given point
> >     (release / time)
> >
> >
> > So like showstopper, A1, B2, etc.?  That way one can specify that this
> > bug must be closed by that point or else the release is blocked?
>
> Right. However, that would be an attribute of the milestone -> bugs link,
> not the bug itself. The bug itself doesn't care that a milestone is on
> hold
> for it. :-)
>
> >     * pep is a placeholder for PEPs, just to illustrate that this
> >     tracker can grow. :-)
> >
> >
> > =)
> >
> >     Access
> >     ------
> >
> >     Users submit bugs, setting title, and optionally components,
> >     platforms, version,
> >     and severity.
> >
> >
> > Don't let them set severity.  I have gotten into mini competitions with
> > OPs over resetting the severity.  They think they know better than me
> > what is severe and what isn't.  And everyone's bug to them is
> severe.  =)
>
> I guess that's your call. I have made good experience with such a flag.
> And, it doesn't have to affect your ranking, it's merely a hint, you know.
> :-)


Right, but bug reporter's take it seriously and can get angry if you don't
give it a priority that they agree with, and thus take it upon themselves to
change.

>     Developers set assignee, status, resolution, dependencies, and
> >     superseder.
> >
> >     Conversion
> >     ----------
> >
> >     Conversion from sf.net <http://sf.net> should map 'category' to
> >     'components',
> >     and 'group' to 'version'.
> >
> >
> >
> >     If there are no objections, I'm going to start to implement it.
> >
> >     Comments ?
> >
> >
> > Any way to flag that a patch might be ripe for backporting?  Sometimes
> > people fix stuff in svn but don't have the time or inclination to
> > backport, so it can get lost (people are supposed to note it in
> > Misc/NEWS, but that is really the wrong place to denote it).  If there
> > was a way to close a bug and flag it as needs backporting (or have a
> > "Backport" resolution) that would help matters.
>
> That sounds like something for for a roundup script, where a new bug
> is created by cloning an old one, but attached to a different branch /
> version.
> Or somesuch.


Maybe.  I just want the feature.  =)

-Brett



Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061122/f121ab83/attachment.htm 

From g.brandl at gmx.net  Wed Nov 22 18:53:44 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Wed, 22 Nov 2006 18:53:44 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456364C7.606@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>		<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>		<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>		<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>		<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>		<45635D6A.4060509@sympatico.ca>	<bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
	<456364C7.606@sympatico.ca>
Message-ID: <45648EA8.2030501@gmx.net>

Stefan Seefeld schrieb:
> Brett Cannon wrote:
> 
>>     * version is an enum to express the python version (or branch) the
>>     problem
>>       occured in.
>> 
>> 
>> Is this a single setting, or can it have multiple values?  If we
>> automatically close old bugs, it might get us to deal with things faster
>> and thus we won't have bugs from a couple versions back.  But otherwise
>> we can end up with bugs where they are present in 2.3 and people need an
>> easy way to note that it is still present in 2.5, etc.
> 
> Good point. It certainly can be a multilink, i.e. refer to multiple
> versions / branches. (An interesting side-note: if we hook up with
> subversion, we probably want to track changes to individual branches
> and only close out the parts of a bug that got affected by a checkin.)
> 
>> This also brings up the idea of having a dependency field.  If I am
>> waiting for feedback or more details from someone, set that field to
>> their username.  If I don't here from them after a set amount of time
>> (like two weeks) the bug gets closed automatically for lack of information.
> 
> Right. I think there can be a status enumerator for this state, together
> with a timer that gets started whenever that state is entered.

Good. That's continuing the SF "Pending" state then.

>>     * severity is an enum allowing users to express the impact the bug
>>     has on them,
>>       such as: (critical, major, normal, minor)
>> 
>>     * dependencies: a list of bugs that need to be fixed before this can
>>     be fixed.
>> 
>>     * status: one of (new, open, closed)
>> 
>>     * resolution, set when status is set to closed: one of (fixed,
>>     invalid, duplicate) 

I would also add "rejected" for patches and "works for me". I don't know if
we need "won't fix". Something like "out of date" is also useful.

>> Also add "Lack of Info" or something since we end up with bugs that just
>> sit there waiting for more info from the OP that we never get.
> 
> Good point. Wouldn't that be the same status enumerator as above
> (or at least, very similar) ?

I'd say that if the "pending" state period is over with no response, set
status to "closed" and resolution to "lack of info" *if* it isn't already
set to another value. This allows to handle both the cases where you need
more info to process the bug, and where you processed it but want to give
the OP the opportunity to comment before closing it.

>>     Users submit bugs, setting title, and optionally components,
>>     platforms, version,
>>     and severity.
>> 
>> 
>> Don't let them set severity.  I have gotten into mini competitions with
>> OPs over resetting the severity.  They think they know better than me
>> what is severe and what isn't.  And everyone's bug to them is severe.  =)
> 
> I guess that's your call. I have made good experience with such a flag.
> And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)

Can't the field become locked after the original submission?

Georg

From seefeld at sympatico.ca  Wed Nov 22 20:05:54 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 22 Nov 2006 14:05:54 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45648EA8.2030501@gmx.net>
References: <455891F0.2050209@sympatico.ca>		<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>		<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>		<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>		<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>		<45635D6A.4060509@sympatico.ca>	<bbaeab100611211227r5aeaf6c9va53c60fe93ef6c44@mail.gmail.com>
	<456364C7.606@sympatico.ca> <45648EA8.2030501@gmx.net>
Message-ID: <45649F92.1060500@sympatico.ca>

Georg Brandl wrote:

>>>     * status: one of (new, open, closed)
>>>
>>>     * resolution, set when status is set to closed: one of (fixed,
>>>     invalid, duplicate) 
> 
> I would also add "rejected" for patches and "works for me". I don't know if
> we need "won't fix". Something like "out of date" is also useful.

Conceptually these all seem to fit into the 'invalid' box. It may make
sense to spell them out if you want to be able to query for them. Otherwise
providing the rest of the feedback in a message could be enough.
So: Do you think querying for the cases you mention is a frequent enough
use case to warrant these additional resolution enumerators ?

>>> Also add "Lack of Info" or something since we end up with bugs that just
>>> sit there waiting for more info from the OP that we never get.
>>
>> Good point. Wouldn't that be the same status enumerator as above
>> (or at least, very similar) ?
> 
> I'd say that if the "pending" state period is over with no response, set
> status to "closed" and resolution to "lack of info" *if* it isn't already
> set to another value. This allows to handle both the cases where you need
> more info to process the bug, and where you processed it but want to give
> the OP the opportunity to comment before closing it.

OK.

>>>     Users submit bugs, setting title, and optionally components,
>>>     platforms, version,
>>>     and severity.
>>>
>>>
>>> Don't let them set severity.  I have gotten into mini competitions with
>>> OPs over resetting the severity.  They think they know better than me
>>> what is severe and what isn't.  And everyone's bug to them is
>>> severe.  =)
>>
>> I guess that's your call. I have made good experience with such a flag.
>> And, it doesn't have to affect your ranking, it's merely a hint, you
>> know. :-)
> 
> Can't the field become locked after the original submission?

Sure. However, the reason for me to distinguish between severity and priority
is precisely to be able to draw the line between the evaluation of the user,
and the evaluation of the bug fixer.
I would find it rude for developers to reset the severity, and I think it
isn't the user's business to tell developers in what order to process bugs
either. (Note that I'm talking about roles here, not actual persons. A single
person may well play both roles...)

Therefor I believe that severity should be writable by everybody (though
developers should respect the ranking given by the OP), while priorities
should be writable only by (potential) bug fixers, i.e. developers.


Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Thu Nov 23 02:36:51 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Wed, 22 Nov 2006 20:36:51 -0500
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
Message-ID: <4564FB33.80903@sympatico.ca>

Hi there,

I'v just copied a new set of files into the tracker, and attempted to
reinitialise it with 'roundup-admin -i `pwd` initialise' as user roundup
(having logged in as 'sudo -u roundup -i'.

I get a stack trace due to a permission error:

OSError: [Errno 13] Permission denied: '/home/roundup/trackers/tracker/db/files/msg/0/msg4'

The file in question is owned by www-data:roundup, but not group-writable. Is that
the old umask problem again ?

Can you please help ? The tracker is in an unusable state right now...

Many thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Thu Nov 23 09:35:51 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 23 Nov 2006 09:35:51 +0100
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4564FB33.80903@sympatico.ca>
References: <4564FB33.80903@sympatico.ca>
Message-ID: <200611230935.52191.forsberg@efod.se>

torsdag 23 november 2006 02:36 skrev Stefan Seefeld:
> Hi there,
>
> I'v just copied a new set of files into the tracker, and attempted to
> reinitialise it with 'roundup-admin -i `pwd` initialise' as user roundup
> (having logged in as 'sudo -u roundup -i'.
>
> I get a stack trace due to a permission error:
>
> OSError: [Errno 13] Permission denied:
> '/home/roundup/trackers/tracker/db/files/msg/0/msg4'
>
> The file in question is owned by www-data:roundup, but not group-writable.
> Is that the old umask problem again ?
>
> Can you please help ? The tracker is in an unusable state right now...

Check out the permissions for the meta tracker, and set the same permissions 
for the python-dev tracker. 

I don't have time to help more than that right now (very busy week). Hopefully 
I'll be able to catch up with the conversations on the mailing list tonight 
or tomorrow.

cheers,
\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Thu Nov 23 14:48:51 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 23 Nov 2006 08:48:51 -0500
Subject: [Tracker-discuss] tracker updates
Message-ID: <4565A6C3.1010603@sympatico.ca>

Hi there,

as threatened before, I have made changes to the schema as well as
the html templates in a more drastic way. The (IMO) rather useless
sf.net properties 'category' and 'group' are replaced by 'type',
'severity', 'components', 'versions', and 'platforms'.

I have removed the 'keyword' property (named 'Topic' in the cgi interface),
as the above schema should be rich enough to capture that. We can certainly
add it back, if there still is a need to tag bugs by arbitrary keywords, too.

Please note that all but the type are optional. It's good if the submitter
can provide these details, but he doesn't have to.

In this tracker there are now three roles 'User', 'Developer', and 'Coordinator',
and some fields are not writable to everyone. For example, the status can't
be modified by users, and the assignee field can only be set to a developer.

Also, I have added some very simple logic to make sure resolution gets
set whenever status changes to 'closed', and superseder is set when resolution
is changed to 'duplicate'. Many more similar checks can be added as we further
constrain the workflow.

To test, please log in as either 'user' (password 'user'), 'devel' (password 'devel'),
or 'coord' (password 'coord') to see what you can and can't do in these roles.


Comments ?

Thanks,
		Stefan

PS: I made up all the enumerators, notably for 'component', 'version', and 'platform'.
    It's merely to illustrate their purpose. In the end, all these types will be
    editable for coordinators, so they can add new enumerators as needed.

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Thu Nov 23 14:59:53 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 23 Nov 2006 14:59:53 +0100
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <4565A6C3.1010603@sympatico.ca>
References: <4565A6C3.1010603@sympatico.ca>
Message-ID: <200611231459.53265.forsberg@efod.se>

torsdag 23 november 2006 14:48 skrev Stefan Seefeld:
> Hi there,
>
> as threatened before, I have made changes to the schema as well as
> the html templates in a more drastic way. The (IMO) rather useless
> sf.net properties 'category' and 'group' are replaced by 'type',
> 'severity', 'components', 'versions', and 'platforms'.
>
> I have removed the 'keyword' property (named 'Topic' in the cgi interface),
> as the above schema should be rich enough to capture that. We can certainly
> add it back, if there still is a need to tag bugs by arbitrary keywords,
> too.

Is there a mapping between the old properties and the new ones? I'm thinking 
about the importer, which will need to cope with the changes. 

Cheers,
\EF
-- 
http://efod.se/

From seefeld at sympatico.ca  Thu Nov 23 15:04:38 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 23 Nov 2006 09:04:38 -0500
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <200611231459.53265.forsberg@efod.se>
References: <4565A6C3.1010603@sympatico.ca>
	<200611231459.53265.forsberg@efod.se>
Message-ID: <4565AA76.50703@sympatico.ca>

Erik Forsberg wrote:

> Is there a mapping between the old properties and the new ones? I'm thinking 
> about the importer, which will need to cope with the changes. 

Not yet. We will have to define the mapping, once everyone agrees on the
new schema.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From roche at upfrontsystems.co.za  Thu Nov 23 15:57:46 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 23 Nov 2006 16:57:46 +0200
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4564FB33.80903@sympatico.ca>
References: <4564FB33.80903@sympatico.ca>
Message-ID: <1164293866.14509.43.camel@localhost.localdomain>

On Wed, 2006-11-22 at 20:36 -0500, Stefan Seefeld wrote:
> Hi there,
> 
> I'v just copied a new set of files into the tracker, and attempted to
> reinitialise it with 'roundup-admin -i `pwd` initialise' as user roundup
> (having logged in as 'sudo -u roundup -i'.
> 
> I get a stack trace due to a permission error:
> 
> OSError: [Errno 13] Permission denied: '/home/roundup/trackers/tracker/db/files/msg/0/msg4'
> 
> The file in question is owned by www-data:roundup, but not group-writable. Is that
> the old umask problem again ?

I doubt it, this was only a problem when issues were created through the
mail gateway. The files you mention above are all owned by www-data, so
they were created through the web.

> Can you please help ? The tracker is in an unusable state right now...

Permissions fixed, but I can't see why roundup-initialize should create
message files or modify file permissions.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From seefeld at sympatico.ca  Thu Nov 23 16:04:44 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 23 Nov 2006 10:04:44 -0500
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <1164293866.14509.43.camel@localhost.localdomain>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
Message-ID: <4565B88C.8000804@sympatico.ca>

Roch? Compaan wrote:

> I doubt it, this was only a problem when issues were created through the
> mail gateway. The files you mention above are all owned by www-data, so
> they were created through the web.

OK. Shouldn't they be group-writable ? What would happen if I tried to
modify them by mail, i.e. by means of ronudup-mailgw, invoked through
exim or some other MTA ?

>> Can you please help ? The tracker is in an unusable state right now...
> 
> Permissions fixed, but I can't see why roundup-initialize should create
> message files or modify file permissions.

roundup-admin initialise doesn't create them, but it attempts to remove existing ones.

Thanks,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From izak at upfrontsystems.co.za  Thu Nov 23 16:15:00 2006
From: izak at upfrontsystems.co.za (Izak Burger)
Date: Thu, 23 Nov 2006 17:15:00 +0200
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4565B88C.8000804@sympatico.ca>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
	<4565B88C.8000804@sympatico.ca>
Message-ID: <4565BAF4.4050405@upfrontsystems.co.za>

Stefan Seefeld wrote:
> OK. Shouldn't they be group-writable ? What would happen if I tried to
> modify them by mail, i.e. by means of ronudup-mailgw, invoked through
> exim or some other MTA ?

If an issue is created using the web, it will end up with permissions 
644, owned by www-data, group roundup.  That is a problem.  If you later 
try to modify this file as the roundup user it will fail.  As far as I 
know roundup-mailgw does not delete or modify files, so it shouldn't be 
a problem.  But if you run roundup-admin (like you did) it might cause 
problems (which it did :-) ).

Setting the umask to 002 before you touch a file would be one solution.

There is one other very simple solution to all this.  We get to keep the 
mod_python performance advantage, and we solve the permission problem. 
All we need to do is run apache as roundup and not as www-data, ie we 
dedicate apache to running roundup.

If nobody objects I will implement that solution.

regards,
Izak

From seefeld at sympatico.ca  Thu Nov 23 16:20:35 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 23 Nov 2006 10:20:35 -0500
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4565BAF4.4050405@upfrontsystems.co.za>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
	<4565B88C.8000804@sympatico.ca>
	<4565BAF4.4050405@upfrontsystems.co.za>
Message-ID: <4565BC43.3030403@sympatico.ca>

Izak Burger wrote:
> Stefan Seefeld wrote:
>> OK. Shouldn't they be group-writable ? What would happen if I tried to
>> modify them by mail, i.e. by means of ronudup-mailgw, invoked through
>> exim or some other MTA ?
> 
> If an issue is created using the web, it will end up with permissions
> 644, owned by www-data, group roundup.  That is a problem.  If you later
> try to modify this file as the roundup user it will fail.  As far as I
> know roundup-mailgw does not delete or modify files, so it shouldn't be
> a problem.  But if you run roundup-admin (like you did) it might cause
> problems (which it did :-) ).

I think at least theoretically roundup-mailgw should be able to do
*anything* that can be done through the web, too. I'm not sure whether
there are actual commands embeddable into the mail subject line to
delete or modify files in the db, but they easily could.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov 23 17:15:11 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 23 Nov 2006 08:15:11 -0800
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4565BC43.3030403@sympatico.ca>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
	<4565B88C.8000804@sympatico.ca>
	<4565BAF4.4050405@upfrontsystems.co.za>
	<4565BC43.3030403@sympatico.ca>
Message-ID: <f74a6c2f0611230815o3b5bb640g233b1a2a13a57d5d@mail.gmail.com>

I don't know how you have the mail set up but if you use the 'alias' method
then the mail user has to be in roundup user's group.

On 11/23/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Izak Burger wrote:
> > Stefan Seefeld wrote:
> >> OK. Shouldn't they be group-writable ? What would happen if I tried to
> >> modify them by mail, i.e. by means of ronudup-mailgw, invoked through
> >> exim or some other MTA ?
> >
> > If an issue is created using the web, it will end up with permissions
> > 644, owned by www-data, group roundup.  That is a problem.  If you later
> > try to modify this file as the roundup user it will fail.  As far as I
> > know roundup-mailgw does not delete or modify files, so it shouldn't be
> > a problem.  But if you run roundup-admin (like you did) it might cause
> > problems (which it did :-) ).
>
> I think at least theoretically roundup-mailgw should be able to do
> *anything* that can be done through the web, too. I'm not sure whether
> there are actual commands embeddable into the mail subject line to
> delete or modify files in the db, but they easily could.
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061123/276b8fec/attachment.htm 

From roche at upfrontsystems.co.za  Thu Nov 23 17:45:27 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 23 Nov 2006 18:45:27 +0200
Subject: [Tracker-discuss] file permissions on
	psf:~roundup/trackers/tracker/*
In-Reply-To: <4565BC43.3030403@sympatico.ca>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
	<4565B88C.8000804@sympatico.ca> <4565BAF4.4050405@upfrontsystems.co.za>
	<4565BC43.3030403@sympatico.ca>
Message-ID: <1164300327.26501.18.camel@kwaaitjie>

On Thu, 2006-11-23 at 10:20 -0500, Stefan Seefeld wrote:
> Izak Burger wrote:
> > Stefan Seefeld wrote:
> >> OK. Shouldn't they be group-writable ? What would happen if I tried to
> >> modify them by mail, i.e. by means of ronudup-mailgw, invoked through
> >> exim or some other MTA ?
> > 
> > If an issue is created using the web, it will end up with permissions
> > 644, owned by www-data, group roundup.  That is a problem.  If you later
> > try to modify this file as the roundup user it will fail.  As far as I
> > know roundup-mailgw does not delete or modify files, so it shouldn't be
> > a problem.  But if you run roundup-admin (like you did) it might cause
> > problems (which it did :-) ).
> 
> I think at least theoretically roundup-mailgw should be able to do
> *anything* that can be done through the web, too. I'm not sure whether
> there are actual commands embeddable into the mail subject line to
> delete or modify files in the db, but they easily could.

roundup-mailgw *can* do anything that can be done through the web and
vice verse, but only if the file permissions are *group writable*. This
is often misconfigured. And realize that directories are not created
where the group has write permissions by default. Even if you set the
sticky bit on the group write permission, subdirectories are created
without the group write permission set.

A system wide umask to make all directories group writable by default is
not an acceptable solution.

The roundup codebase has to create directories where the group can write
to it, or everything has to run under the same user. At this point I'm
going to support Izak's recommendation to run Apache as the roundup user
so that we can put an end to the permission problems.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From roche at upfrontsystems.co.za  Thu Nov 23 17:53:35 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Thu, 23 Nov 2006 18:53:35 +0200
Subject: [Tracker-discuss] file permissions
	on	psf:~roundup/trackers/tracker/*
In-Reply-To: <f74a6c2f0611230815o3b5bb640g233b1a2a13a57d5d@mail.gmail.com>
References: <4564FB33.80903@sympatico.ca>
	<1164293866.14509.43.camel@localhost.localdomain>
	<4565B88C.8000804@sympatico.ca> <4565BAF4.4050405@upfrontsystems.co.za>
	<4565BC43.3030403@sympatico.ca>
	<f74a6c2f0611230815o3b5bb640g233b1a2a13a57d5d@mail.gmail.com>
Message-ID: <1164300816.26501.27.camel@kwaaitjie>

On Thu, 2006-11-23 at 08:15 -0800, Paul Dubois wrote:
> I don't know how you have the mail set up but if you use the 'alias'
> method then the mail user has to be in roundup user's group.

The mail is delivered as the roundup user, but if the files are owned by
www-data and not group writable it doesn't help.

The problem does not lie with mail delivery, since Postfix switches to
the roundup user and delivers the mail as the roundup user. Apache
however cannot run CGIs as another user. Having different users create
directories without them being group writable is the problem.

Directories are created allowing only the user to write to them by
default. To change this you have to modify the system umask which is not
an option security wise.

One might say that this is a Roundup software problem, but it is really
a problem with Apache - it's can't run a CGI under a different user. 

The permission problems you see will be a problem on all distros that
don't have a umask set to 0002 (and I don't think there is one).

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From Doug.Napoleone at nuance.com  Fri Nov 24 07:43:32 2006
From: Doug.Napoleone at nuance.com (Napoleone, Doug)
Date: Fri, 24 Nov 2006 01:43:32 -0500
Subject: [Tracker-discuss] Question on Multiple Projects
Message-ID: <37E3DF6920CC664D924AFA9966C33EE802DDBB@bn-exchdmz>

Hello,
    My name is Douglas Napoleone and I am working on software for the python
convention. I have been keeping track of the progress and figure it's time
to ask some questions before the schema becomes set in stone. 

I was hoping a roundup project could be created for managing the pycon
software bugs. I know roundup can do this at it's base, but I was not sure
if there were any plans to have this support enabled as all the talk has
been limited to python-dev.

This is not a priority, and should not take any time away from the
python-dev work. I also don't mind being a first run QA for the system if it
helps.

I have been using a wiki on the pycon site to manage bugs
(http://us.pycon.org/TX2007/PyConTechBugs), but it is becomming
unmaintainable. The system is going to be opened up to the public for anyone
to volunteer and work on the code; a better bug system with feature
management is going to be crucical. I have some privately hosted trac
systems I could use for this year, worst case. As the code is hosted on
svn.python.org, the long term wish is to have things unified. 

Thanks to everyone for all your hard work!

    -Doug Napoleone

From brett at python.org  Fri Nov 24 19:41:29 2006
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Nov 2006 10:41:29 -0800
Subject: [Tracker-discuss] Question on Multiple Projects
In-Reply-To: <37E3DF6920CC664D924AFA9966C33EE802DDBB@bn-exchdmz>
References: <37E3DF6920CC664D924AFA9966C33EE802DDBB@bn-exchdmz>
Message-ID: <bbaeab100611241041h79ac5701rde82b0e7543549e6@mail.gmail.com>

On 11/23/06, Napoleone, Doug <Doug.Napoleone at nuance.com> wrote:
> Hello,
>     My name is Douglas Napoleone and I am working on software for the python
> convention. I have been keeping track of the progress and figure it's time
> to ask some questions before the schema becomes set in stone.
>
> I was hoping a roundup project could be created for managing the pycon
> software bugs. I know roundup can do this at it's base, but I was not sure
> if there were any plans to have this support enabled as all the talk has
> been limited to python-dev.
>

The long-term hope is to host the trackers for several projects that
have any direct ties to python-dev.  Let us first get the python-dev
tracker up and catch our breath.  Then we will evaluate how we want to
handle adding more trackers for other groups.

-Brett

> This is not a priority, and should not take any time away from the
> python-dev work. I also don't mind being a first run QA for the system if it
> helps.
>
> I have been using a wiki on the pycon site to manage bugs
> (http://us.pycon.org/TX2007/PyConTechBugs), but it is becomming
> unmaintainable. The system is going to be opened up to the public for anyone
> to volunteer and work on the code; a better bug system with feature
> management is going to be crucical. I have some privately hosted trac
> systems I could use for this year, worst case. As the code is hosted on
> svn.python.org, the long term wish is to have things unified.
>
> Thanks to everyone for all your hard work!
>
>     -Doug Napoleone
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>

From roche at upfrontsystems.co.za  Sat Nov 25 15:13:26 2006
From: roche at upfrontsystems.co.za (=?ISO-8859-1?Q?Roch=E9?= Compaan)
Date: Sat, 25 Nov 2006 16:13:26 +0200
Subject: [Tracker-discuss] Reverting to roundup-server
Message-ID: <1164464006.2414.42.camel@kwaaitjie>

After discussion between me, Izak, Stefan and Richard Jones, we've
decided to revert to using roundup-server behind Apache.

The performance difference should be negligible given that the most
expensive tasks in Roundup are database lookups and queries. The
difference in permission hassles is not negligible, and is negatively
effecting productivity. Richard also pointed out that Roundup's umask
implementation might be buggy. The umask code doesn't have tests yet
because he also uses roundup-server in his configurations and never
actually depended on umask settings.

-- 
Roch? Compaan
Upfront Systems                   http://www.upfrontsystems.co.za


From forsberg at efod.se  Sat Nov 25 22:36:58 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 25 Nov 2006 22:36:58 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45635D6A.4060509@sympatico.ca> (Stefan Seefeld's message of
	"Tue, 21 Nov 2006 15:11:22 -0500")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca>
Message-ID: <87slg7mcn9.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

Sorry for being late with comments - it's been a _veery_ busy week.

> OK, fair enough. So, let me present a little hand-drawn schema I'm aiming
> for, with some comments. The goal is to allow users to report bugs with
> as much detail as possible, without getting into their way. All properties
> are typed (i.e. use links to predefined entities), instead of simple strings,
> to avoid typos and make querying easier.

This is all good. 
>
> bug = (title,
>        messages,
>        files,
>        type,
>        components,
>        platforms,
>        version,
>        severity,
>        dependencies,
>        status,
>        resolution,
>        superseder)

I know there has been discussions back and forth about the naming of
the main database type - "bug" or "issue" or something else. 

Personally, my opinion is that it should not be "bug", because one
might also want to enter feature requests (which are not bugs) and
other kinds of "issues", which takes us back to "issue" which is a
nice and general name. OTOH, I guess the Python project handles its
feature requests mostly by PEPs, so perhaps everything entered into
this database will actually be bugs?

I don't think the name of the class matters that much, though. At my
work, we use a bugzilla instance for tracking both bugs and feature
requests, and it confuses our sales people at least once a month :).

> pep = (title, messages, files, ...)
>
> milestone = (name, messages, eta, bugs, peps)

I don't see the milestones in the current test tracker? 

I think it's important to be able to add a reference to the intended
milestone(s) from the bug, not the opposite. Perhaps there should be a
Link(milestone) or Multilink(milestone) on bug instead of a
Multilink(bug) on milestone?

I don't know how the decisions on which bugs should be part of which
releases are made - perhaps one of the release managers could give a
hint on how this should work to make the process easy? 

Btw, perhaps we could use milestones for keeping track of bugs that
need to be backported? If a bug could belong to several milestones
(and be open/closed in several milestones), it could first be closed
on the milestone for the next big release, then be closed on the
milestone for a backport release. 

This also depends on how the Python release process works, and I don't
know much about it, so some feedback would be appreciated. Also, I
don't know if it's currently possible to design such a solution with
roundup. Just a wild idea :)

> * status: one of (new, open, closed)
>
> * resolution, set when status is set to closed: one of (fixed, invalid, duplicate)

I like this. It's very much how Bugzilla does it, and I like how
Bugzilla does it. We might consider a different UI than select boxes -
Bugzilla uses radio buttons, for example "close bug, mark as duplicate
of <superseder>"

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFaLd5rJurFAusidkRAgLEAKDNKDvEEHwI7TLeD15d6ZoerEvDwQCfQxE5
RHszzQU9v29PUEu+ChuJ9PA=
=7eGB
-----END PGP SIGNATURE-----

From forsberg at efod.se  Sat Nov 25 22:46:18 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 25 Nov 2006 22:46:18 +0100
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <4565A6C3.1010603@sympatico.ca> (Stefan Seefeld's message of
	"Thu, 23 Nov 2006 08:48:51 -0500")
References: <4565A6C3.1010603@sympatico.ca>
Message-ID: <87k61jmc7p.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:


> Comments ?

I like the layout. Very clean! 

As mentioned in another mail, I miss the milestone field, but I guess
that's just because you haven't had the time, or something like that?

Btw, it bugs out if you try to set a superseder. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFaLmprJurFAusidkRAvMJAKCXpCre5/Ld117otECUu35H3rzC4QCfY+zy
KpGLzIBq2BwpqLXg4ccBrq4=
=dQ+g
-----END PGP SIGNATURE-----

From pfdubois at gmail.com  Sat Nov 25 22:50:51 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 25 Nov 2006 13:50:51 -0800
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <87k61jmc7p.fsf@uterus.efod.se>
References: <4565A6C3.1010603@sympatico.ca> <87k61jmc7p.fsf@uterus.efod.se>
Message-ID: <f74a6c2f0611251350n52591002j487773ab17f295e9@mail.gmail.com>

On 11/25/06, Erik Forsberg <forsberg at efod.se> wrote:
>
>
> Btw, it bugs out if you try to set a superseder.



This reminds me of a question I have been meaning to ask. I don't think
'superceder' actually does anything in 'classic'. I ended up changing it to
mean 'see also' in my tracker. Is superceder actually supposed to have some
action associated with it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061125/98d263db/attachment.html 

From seefeld at sympatico.ca  Sat Nov 25 23:05:49 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 25 Nov 2006 17:05:49 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87slg7mcn9.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>
Message-ID: <4568BE3D.40206@sympatico.ca>

Erik Forsberg wrote:

> Personally, my opinion is that it should not be "bug", because one
> might also want to enter feature requests (which are not bugs) and
> other kinds of "issues", which takes us back to "issue" which is a
> nice and general name. OTOH, I guess the Python project handles its
> feature requests mostly by PEPs, so perhaps everything entered into
> this database will actually be bugs?

Well, I thought we would eventually handle PEPs, too !
And I also suggested 'milestone' (which isn't yet part of the current
live schema, but can be added simply and non-intrusively).

So, these three would all be 'issues' in the general sense that roundup
is an 'issue tracker'.

Finally, I don't agree that 'feature requests are not bugs'. The formal
handling of PEPs aside, I believe there is a blurry line, where some
bugs may turn into feature requests ('add better documentation' or
'complete this API'), so it is good to be able to turn one into the
other by a simple change of an enumerator.

But, may be this is really up to the people who will actually deal
with these issues to decide whether they want it that way or the other.

> I don't think the name of the class matters that much, though. At my
> work, we use a bugzilla instance for tracking both bugs and feature
> requests, and it confuses our sales people at least once a month :).

Heh, just provide some filters so they only see what they want to see.

>>> pep = (title, messages, files, ...)
>>>
>>> milestone = (name, messages, eta, bugs, peps)
> 
> I don't see the milestones in the current test tracker? 

Correct.

> I think it's important to be able to add a reference to the intended
> milestone(s) from the bug, not the opposite. Perhaps there should be a
> Link(milestone) or Multilink(milestone) on bug instead of a
> Multilink(bug) on milestone?

Hmm, I don't agree that 'fixed for milestone X.Y' should be a property
of a bug. On the other hand, I can easily see it to be convenient to
assign due dates or somesuch from the bug's display. But that is just
a matter of adding the relevant logic to the bug.item.html template
(and may be to the bug.search.html template, too).

> I don't know how the decisions on which bugs should be part of which
> releases are made - perhaps one of the release managers could give a
> hint on how this should work to make the process easy? 
> 
> Btw, perhaps we could use milestones for keeping track of bugs that
> need to be backported? If a bug could belong to several milestones
> (and be open/closed in several milestones), it could first be closed
> on the milestone for the next big release, then be closed on the
> milestone for a backport release. 

That's an interesting point. Milestones are mostly associated with
particular branches, while bugs (at least in my suggested schema)
could be associated with multiple versions / branches. Isn't that
an argument in favor of putting the link between bug and milestone
into the milestone, not the bug ? :-)

> This also depends on how the Python release process works, and I don't
> know much about it, so some feedback would be appreciated. Also, I
> don't know if it's currently possible to design such a solution with
> roundup. Just a wild idea :)

Yeah, I agree. "It's just a matter of coding" is certainly true, in particular
with the wonderful roundup design. However, more feedback from the python-dev
people would be useful to decide how to proceed.

>>> * status: one of (new, open, closed)
>>>
>>> * resolution, set when status is set to closed: one of (fixed, invalid, duplicate)
> 
> I like this. It's very much how Bugzilla does it, and I like how
> Bugzilla does it. We might consider a different UI than select boxes -
> Bugzilla uses radio buttons, for example "close bug, mark as duplicate
> of <superseder>"

Interesting idea. Yeah, the GUI could certainly be made more convenient to use.
(For example some javascript to only enable the resolution field if status is
being set to 'closed', or somesuch to better guide the user through the form.)

Thanks for the feedback !

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sat Nov 25 23:10:19 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 25 Nov 2006 17:10:19 -0500
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <87k61jmc7p.fsf@uterus.efod.se>
References: <4565A6C3.1010603@sympatico.ca> <87k61jmc7p.fsf@uterus.efod.se>
Message-ID: <4568BF4B.1010808@sympatico.ca>

Erik Forsberg wrote:
> Stefan Seefeld <seefeld at sympatico.ca> writes:
> 
> 
>>> Comments ?
> 
> I like the layout. Very clean! 

Thanks !

> As mentioned in another mail, I miss the milestone field, but I guess
> that's just because you haven't had the time, or something like that?

Right, I wanted to focus on the bug and its template(s). Now that I
have some more positive feedback on the milestone idea, I can add it,
too.

> Btw, it bugs out if you try to set a superseder. 

I can believe that. :-)
The auditors I added should check that superseder is set iff status is
closed and resolution is duplicate. However, we also ought to make
sure the to-be superseder itself is not yet closed, exists, and is
different from the current bug. And probably much more consistency
checks...

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sat Nov 25 23:15:52 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 25 Nov 2006 17:15:52 -0500
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <f74a6c2f0611251350n52591002j487773ab17f295e9@mail.gmail.com>
References: <4565A6C3.1010603@sympatico.ca> <87k61jmc7p.fsf@uterus.efod.se>
	<f74a6c2f0611251350n52591002j487773ab17f295e9@mail.gmail.com>
Message-ID: <4568C098.1050301@sympatico.ca>

Paul Dubois wrote:

> This reminds me of a question I have been meaning to ask. I don't think
> 'superceder' actually does anything in 'classic'. I ended up changing it
> to mean 'see also' in my tracker. Is superceder actually supposed to
> have some action associated with it?

I think the idea is to be able to have a long-term process that spans
multiple bugs, so you can close one bug and indicate that some followup
will be handled elsewhere.

In particular, in my suggested schema a duplicate bug would be closed
as 'duplicate' with the superseder field set to the bug this one is a
duplicate of.

So, I think while 'see also' merely means that two bugs are somehow
related, 'superseder' has stronger semantics implying that the superdeded
bug is actually closed.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Sat Nov 25 23:37:19 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 25 Nov 2006 23:37:19 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4568BE3D.40206@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca>
Message-ID: <4568C59F.90809@v.loewis.de>

Stefan Seefeld schrieb:
> Erik Forsberg wrote:
> 
>> Personally, my opinion is that it should not be "bug", because one
>> might also want to enter feature requests (which are not bugs) and
>> other kinds of "issues", which takes us back to "issue" which is a
>> nice and general name. OTOH, I guess the Python project handles its
>> feature requests mostly by PEPs, so perhaps everything entered into
>> this database will actually be bugs?
> 
> Well, I thought we would eventually handle PEPs, too !


I'm not quite sure what you mean by that. No, the Python project does
*not* handle feature requests mostly by PEPs; many new features are
added without any discussion at all (like adding a new optional
parameter to an existing function, or supporting a new release of
an operating system where the old release was supported).

PEPs are there primarily for controversial new features; if there is
no controversy, there is no point in writing a PEP. Also, PEPs are only
for "major" new features, where the effort of writing a PEP is justified
because it is still smaller than the effort of implementing and
defending it.

PEPs aren't handled through the tracker, and shouldn't be. PEPs are
discussed on many forums, and the PEP authors have the task of merging
all comments into the PEP text.

> But, may be this is really up to the people who will actually deal
> with these issues to decide whether they want it that way or the other.

I can repeat was voiced earlier: the SF view of having separate lists
(for bugs and patches) is confusing. Things that start out as a bug
report often get a patch added, at which point they should become
"patches". OTOH, some "patches" primarily report a bug, and the patch
provided is not useful. So it seems the users want a single list.

I also can report that some users (including yours truly) would
prefer to rank reports based on whether patches are included, giving
higher priority to issues that include a proposed solution.

> That's an interesting point. Milestones are mostly associated with
> particular branches, while bugs (at least in my suggested schema)
> could be associated with multiple versions / branches. Isn't that
> an argument in favor of putting the link between bug and milestone
> into the milestone, not the bug ? :-)

It should be easy to close a bug at once for both the trunk and the
"active" maintenance branch. Backports should occur immediately and
along with actual fix (IMO); people following this policy should have
an easy way of closing the bug "twice".

OTOH, we have lived well so far without including a "closed in
this branch only" field. Submitters occasionally complain that
they though it was closed only to find that the next bugfix
release did not include the patch (because the fix was on the trunk
only); these days, presence of multiple svn revision numbers
can be taken as an indication that it got fixed on multiple
branches.

Regards,
Martin


From seefeld at sympatico.ca  Sat Nov 25 23:49:43 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 25 Nov 2006 17:49:43 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4568C59F.90809@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <4568C59F.90809@v.loewis.de>
Message-ID: <4568C887.6060706@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> Erik Forsberg wrote:
>>
>>> Personally, my opinion is that it should not be "bug", because one
>>> might also want to enter feature requests (which are not bugs) and
>>> other kinds of "issues", which takes us back to "issue" which is a
>>> nice and general name. OTOH, I guess the Python project handles its
>>> feature requests mostly by PEPs, so perhaps everything entered into
>>> this database will actually be bugs?
>> Well, I thought we would eventually handle PEPs, too !
> 
> 
> I'm not quite sure what you mean by that. No, the Python project does
> *not* handle feature requests mostly by PEPs; many new features are
> added without any discussion at all (like adding a new optional
> parameter to an existing function, or supporting a new release of
> an operating system where the old release was supported).
> 
> PEPs are there primarily for controversial new features; if there is
> no controversy, there is no point in writing a PEP. Also, PEPs are only
> for "major" new features, where the effort of writing a PEP is justified
> because it is still smaller than the effort of implementing and
> defending it.
> 
> PEPs aren't handled through the tracker, and shouldn't be. PEPs are
> discussed on many forums, and the PEP authors have the task of merging
> all comments into the PEP text.

I see. FWIW, what I had in mind was similar: have a 'feature request'
enumerator that can be set in the 'type' property of bugs, suitable for
the 'minor' features you talk about.

And, have a completely different issue type 'pep' that has its own life
cycle, which could help to manage PEPs. Actually, I think it was amk who
mentioned the possibility to handle PEPs in the tracker.
I have no opinion whether PEPs should be handled with the tracker or not,
but it certainly *can* be done, even with all the required infrastructure
such as handling the evolution of PEP documents, managing discussions
across suitable mailing lists or other media, etc.
I can see the tracker making the life for PEP authors easier.

>> But, may be this is really up to the people who will actually deal
>> with these issues to decide whether they want it that way or the other.
> 
> I can repeat was voiced earlier: the SF view of having separate lists
> (for bugs and patches) is confusing. Things that start out as a bug
> report often get a patch added, at which point they should become
> "patches". OTOH, some "patches" primarily report a bug, and the patch
> provided is not useful. So it seems the users want a single list.

Yes, I agree.

> I also can report that some users (including yours truly) would
> prefer to rank reports based on whether patches are included, giving
> higher priority to issues that include a proposed solution.

How would you tag patches (attachments, generally) to decide / indicate
whether it actually contains a patch and not some other content, and whether
it really fixes the bug ? Doesn't this involve at least some developer
interaction anyway, at which point we could simply set a 'contains fix'
flag that would be part of the bug type, or absorb into the status
enumeration as 'fix_provided_but_needs_testing', as suggested earlier ?

>> That's an interesting point. Milestones are mostly associated with
>> particular branches, while bugs (at least in my suggested schema)
>> could be associated with multiple versions / branches. Isn't that
>> an argument in favor of putting the link between bug and milestone
>> into the milestone, not the bug ? :-)
> 
> It should be easy to close a bug at once for both the trunk and the
> "active" maintenance branch. Backports should occur immediately and
> along with actual fix (IMO); people following this policy should have
> an easy way of closing the bug "twice".
> 
> OTOH, we have lived well so far without including a "closed in
> this branch only" field. Submitters occasionally complain that
> they though it was closed only to find that the next bugfix
> release did not include the patch (because the fix was on the trunk
> only); these days, presence of multiple svn revision numbers
> can be taken as an indication that it got fixed on multiple
> branches.

OK.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From forsberg at efod.se  Sat Nov 25 23:59:34 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sat, 25 Nov 2006 23:59:34 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4568BE3D.40206@sympatico.ca> (Stefan Seefeld's message of "Sat, 
	25 Nov 2006 17:05:49 -0500")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca>
Message-ID: <87ac2fku95.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> Erik Forsberg wrote:
>
>> Personally, my opinion is that it should not be "bug", because one
>> might also want to enter feature requests (which are not bugs) and
>> other kinds of "issues", which takes us back to "issue" which is a
>> nice and general name. OTOH, I guess the Python project handles its
>> feature requests mostly by PEPs, so perhaps everything entered into
>> this database will actually be bugs?
>
> Well, I thought we would eventually handle PEPs, too !
> And I also suggested 'milestone' (which isn't yet part of the current
> live schema, but can be added simply and non-intrusively).
>
> So, these three would all be 'issues' in the general sense that roundup
> is an 'issue tracker'.
>
> Finally, I don't agree that 'feature requests are not bugs'. The formal
> handling of PEPs aside, I believe there is a blurry line, where some
> bugs may turn into feature requests ('add better documentation' or
> 'complete this API'), so it is good to be able to turn one into the
> other by a simple change of an enumerator.

Hmm.. I have a feeling that you misunderstand what I'm trying to say. 

I fully agree that you should be able to turn a feature request into a
bug very easily, and that is exactly why I think the main class should
not be named "bug". I don't want another class for feature requests, I
want the main class to cover as many types of issues (see, there it is
again, the perfect word for it! :) as possible. 

>> I think it's important to be able to add a reference to the intended
>> milestone(s) from the bug, not the opposite. Perhaps there should be a
>> Link(milestone) or Multilink(milestone) on bug instead of a
>> Multilink(bug) on milestone?
>
> Hmm, I don't agree that 'fixed for milestone X.Y' should be a property
> of a bug. On the other hand, I can easily see it to be convenient to
> assign due dates or somesuch from the bug's display. But that is just
> a matter of adding the relevant logic to the bug.item.html template
> (and may be to the bug.search.html template, too).

Actually, I don't think it matters that much which of the two classes
in the relation has the actual link property, as long as it's easy to
set a link from the bug display. 

At work, where we use bugzilla, we use milestones a lot. Typically,
during a week, a bunch of new bugs are found. They are entered into
bugzilla and the milestone is then set to '--' which is bugzillaish
for "not yet decided". During our weekly development meeting, we then
iterate through the bugs with milestone "--" and set the milestone to
something more appropriate such as "release X.Y". 

If we would first have to find the bug, then locate the milestone and
add the bug there, it would be much less convenient. 

The above provided as an example of why I think being able to set
milestones from the bug display is important. The python-dev people
might use a completely different procedure (some kind of Silly Walk,
perhaps? :)  )

> Yeah, I agree. "It's just a matter of coding" is certainly true, in
> particular with the wonderful roundup design. However, more feedback
> from the python-dev people would be useful to decide how to proceed.

Yup.

Implementing this might need some kind of "Link with a property"
property-type in roundup. We want to store not only a link from the
milestone to the issue (or from the issue to the milestone ;-) ), but
also the status (open/closed/...). That is currently not possible as
far as I understand - I asked about this a while ago in this thread:

http://permalink.gmane.org/gmane.comp.bug-tracking.roundup.user/6890

Perhaps there are ways to do this without this kind of link type? 

> (For example some javascript to only enable the resolution field if status is
> being set to 'closed', or somesuch to better guide the user through the form.)
You must call it AJAX, or the Web 2.0-meter will not react :-). 

Cheers,
\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFaMrWrJurFAusidkRAkk1AJ9bt22Fxd2kp6Ul6d5kGNN9hUz8lACfZD4d
8L2bfwqqUnR81Of+AUcYvAk=
=cmwz
-----END PGP SIGNATURE-----

From pfdubois at gmail.com  Sun Nov 26 01:07:07 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 25 Nov 2006 16:07:07 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87ac2fku95.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <87ac2fku95.fsf@uterus.efod.se>
Message-ID: <f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>

I substantially agree with Erik's views. I have seen wishes/faqs/bugs morph
one to the other so many times that I find 'issue' just right. We also have
'notices' that sort first so that everyone sees them, intended to last a
week or two.

I think the design discussion of 'milestone' tells us that we don't yet know
what we want so we should push that back to 'phase 2'. FWIW certainly we set
the due date from the issue; we have a meeting, decide what goes in the next
release, and the group leader goes and sets the due date, or sets it after
conversing with the assignee.

Let's be minimal and fast on this first go.

On 11/25/06, Erik Forsberg <forsberg at efod.se> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stefan Seefeld <seefeld at sympatico.ca> writes:
>
> > Erik Forsberg wrote:
> >
> >> Personally, my opinion is that it should not be "bug", because one
> >> might also want to enter feature requests (which are not bugs) and
> >> other kinds of "issues", which takes us back to "issue" which is a
> >> nice and general name. OTOH, I guess the Python project handles its
> >> feature requests mostly by PEPs, so perhaps everything entered into
> >> this database will actually be bugs?
> >
> > Well, I thought we would eventually handle PEPs, too !
> > And I also suggested 'milestone' (which isn't yet part of the current
> > live schema, but can be added simply and non-intrusively).
> >
> > So, these three would all be 'issues' in the general sense that roundup
> > is an 'issue tracker'.
> >
> > Finally, I don't agree that 'feature requests are not bugs'. The formal
> > handling of PEPs aside, I believe there is a blurry line, where some
> > bugs may turn into feature requests ('add better documentation' or
> > 'complete this API'), so it is good to be able to turn one into the
> > other by a simple change of an enumerator.
>
> Hmm.. I have a feeling that you misunderstand what I'm trying to say.
>
> I fully agree that you should be able to turn a feature request into a
> bug very easily, and that is exactly why I think the main class should
> not be named "bug". I don't want another class for feature requests, I
> want the main class to cover as many types of issues (see, there it is
> again, the perfect word for it! :) as possible.
>
> >> I think it's important to be able to add a reference to the intended
> >> milestone(s) from the bug, not the opposite. Perhaps there should be a
> >> Link(milestone) or Multilink(milestone) on bug instead of a
> >> Multilink(bug) on milestone?
> >
> > Hmm, I don't agree that 'fixed for milestone X.Y' should be a property
> > of a bug. On the other hand, I can easily see it to be convenient to
> > assign due dates or somesuch from the bug's display. But that is just
> > a matter of adding the relevant logic to the bug.item.html template
> > (and may be to the bug.search.html template, too).
>
> Actually, I don't think it matters that much which of the two classes
> in the relation has the actual link property, as long as it's easy to
> set a link from the bug display.
>
> At work, where we use bugzilla, we use milestones a lot. Typically,
> during a week, a bunch of new bugs are found. They are entered into
> bugzilla and the milestone is then set to '--' which is bugzillaish
> for "not yet decided". During our weekly development meeting, we then
> iterate through the bugs with milestone "--" and set the milestone to
> something more appropriate such as "release X.Y".
>
> If we would first have to find the bug, then locate the milestone and
> add the bug there, it would be much less convenient.
>
> The above provided as an example of why I think being able to set
> milestones from the bug display is important. The python-dev people
> might use a completely different procedure (some kind of Silly Walk,
> perhaps? :)  )
>
> > Yeah, I agree. "It's just a matter of coding" is certainly true, in
> > particular with the wonderful roundup design. However, more feedback
> > from the python-dev people would be useful to decide how to proceed.
>
> Yup.
>
> Implementing this might need some kind of "Link with a property"
> property-type in roundup. We want to store not only a link from the
> milestone to the issue (or from the issue to the milestone ;-) ), but
> also the status (open/closed/...). That is currently not possible as
> far as I understand - I asked about this a while ago in this thread:
>
> http://permalink.gmane.org/gmane.comp.bug-tracking.roundup.user/6890
>
> Perhaps there are ways to do this without this kind of link type?
>
> > (For example some javascript to only enable the resolution field if
> status is
> > being set to 'closed', or somesuch to better guide the user through the
> form.)
> You must call it AJAX, or the Web 2.0-meter will not react :-).
>
> Cheers,
> \EF
> - --
> Erik Forsberg                 http://efod.se
> GPG/PGP Key: 1024D/0BAC89D9
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
>
> iD8DBQFFaMrWrJurFAusidkRAkk1AJ9bt22Fxd2kp6Ul6d5kGNN9hUz8lACfZD4d
> 8L2bfwqqUnR81Of+AUcYvAk=
> =cmwz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061125/977750d4/attachment.html 

From pfdubois at gmail.com  Sun Nov 26 01:09:22 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sat, 25 Nov 2006 16:09:22 -0800
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <4568C098.1050301@sympatico.ca>
References: <4565A6C3.1010603@sympatico.ca> <87k61jmc7p.fsf@uterus.efod.se>
	<f74a6c2f0611251350n52591002j487773ab17f295e9@mail.gmail.com>
	<4568C098.1050301@sympatico.ca>
Message-ID: <f74a6c2f0611251609h54844d9fg3505f87a0974f424@mail.gmail.com>

Yeah, I get it, but what I meant was that by default there is no such
action; 'superceder' in the classic tracker sounds nice but it does bupkiss.

BTW can we make this list default to 'reply to list'?

On 11/25/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
>
> > This reminds me of a question I have been meaning to ask. I don't think
> > 'superceder' actually does anything in 'classic'. I ended up changing it
> > to mean 'see also' in my tracker. Is superceder actually supposed to
> > have some action associated with it?
>
> I think the idea is to be able to have a long-term process that spans
> multiple bugs, so you can close one bug and indicate that some followup
> will be handled elsewhere.
>
> In particular, in my suggested schema a duplicate bug would be closed
> as 'duplicate' with the superseder field set to the bug this one is a
> duplicate of.
>
> So, I think while 'see also' merely means that two bugs are somehow
> related, 'superseder' has stronger semantics implying that the superdeded
> bug is actually closed.
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061125/6f4f8dfd/attachment.htm 

From seefeld at sympatico.ca  Sun Nov 26 05:10:02 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sat, 25 Nov 2006 23:10:02 -0500
Subject: [Tracker-discuss] tracker updates
In-Reply-To: <f74a6c2f0611251609h54844d9fg3505f87a0974f424@mail.gmail.com>
References: <4565A6C3.1010603@sympatico.ca> <87k61jmc7p.fsf@uterus.efod.se>	
	<f74a6c2f0611251350n52591002j487773ab17f295e9@mail.gmail.com>	
	<4568C098.1050301@sympatico.ca>
	<f74a6c2f0611251609h54844d9fg3505f87a0974f424@mail.gmail.com>
Message-ID: <4569139A.4010708@sympatico.ca>

Paul Dubois wrote:
> Yeah, I get it, but what I meant was that by default there is no such
> action; 'superceder' in the classic tracker sounds nice but it does bupkiss.

OK. And I wasn't talking about the 'classic' tracker (which I have never used),
but my current python-dev proposal. :-)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Sun Nov 26 09:33:30 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 09:33:30 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4568C887.6060706@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
Message-ID: <4569515A.9010705@v.loewis.de>

Stefan Seefeld schrieb:
> How would you tag patches (attachments, generally) to decide / indicate
> whether it actually contains a patch and not some other content, and whether
> it really fixes the bug ? Doesn't this involve at least some developer
> interaction anyway, at which point we could simply set a 'contains fix'
> flag that would be part of the bug type, or absorb into the status
> enumeration as 'fix_provided_but_needs_testing', as suggested earlier ?

I have no preference here. Having a "patch" tag might work; classifying
attachments as patches might also work. Typically, *all* patches in
"open" submissions still need review: if they are successfully reviewed,
the patch gets either accepted or rejected; if accepted, it gets
committed and the issue closed. So I don't see the need to distinguish
between "has patch" and "has working patch". If the patch is not
acceptable as-is, the submitter may be asked to rework it. I had
no need to filter for that status: if I open the issue, I can easily
see that it is still in the feedback phase (and reject the patch
if the submitter is unresponsive).

Regards,
Martin


From martin at v.loewis.de  Sun Nov 26 09:49:45 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 09:49:45 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87ac2fku95.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<87ac2fku95.fsf@uterus.efod.se>
Message-ID: <45695529.9030809@v.loewis.de>

Erik Forsberg schrieb:
> I fully agree that you should be able to turn a feature request into a
> bug very easily, and that is exactly why I think the main class should
> not be named "bug". I don't want another class for feature requests, I
> want the main class to cover as many types of issues (see, there it is
> again, the perfect word for it! :) as possible. 

I may have missed some discussion; IMO, to the end user, the name
of the main class should be invisible. It can be called "bug", "issue",
"contribution", or "jabberwocky". As an end user, I don't want to have
to type the name of the main class into the computer, ever. In
particular, I hope that I can refer to some issue as
bugs.python.org/<issue>.

> At work, where we use bugzilla, we use milestones a lot. Typically,
> during a week, a bunch of new bugs are found. They are entered into
> bugzilla and the milestone is then set to '--' which is bugzillaish
> for "not yet decided". During our weekly development meeting, we then
> iterate through the bugs with milestone "--" and set the milestone to
> something more appropriate such as "release X.Y". 

In Python, we never do that. By default, all contributions are targeted
for the next release, with two exceptions: when the next release is
close, we tell (in natural language) the submitter that there is no
chance it can go into this release. The other exception is that some
patches are submitted towards Python 3 now.

SF has a field indicating a version number - we use that to record
in what version a bug was found, so it always talks about past versions,
not future versions.

We currently use priorities to show
- that a submission should be integrated into the next release if
  at all possible
- that a submission blocks a release, i.e. we can't release without
  that issue being resolved
That distinction is mostly made just before a release; a single
"target version" field would not help as it would not distinguish
between blockers and non-blockers.

> The above provided as an example of why I think being able to set
> milestones from the bug display is important. The python-dev people
> might use a completely different procedure (some kind of Silly Walk,
> perhaps? :)  )

See above. In open source, it is really unrealistic to assume that
a bug can be fixed with a given deadline. It may well take years
to fix a certain bug even if the bug is critical in some contexts.
Even for patches, we now have patches that have been completely
unreviewed for more than three years. So setting target versions
is just day-dreaming.

Regards,
Martin

From martin at v.loewis.de  Sun Nov 26 09:55:29 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 09:55:29 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<87ac2fku95.fsf@uterus.efod.se>
	<f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>
Message-ID: <45695681.2000505@v.loewis.de>

Paul Dubois schrieb:
> I think the design discussion of 'milestone' tells us that we don't yet
> know what we want so we should push that back to 'phase 2'. FWIW
> certainly we set the due date from the issue; we have a meeting, decide
> what goes in the next release, and the group leader goes and sets the
> due date, or sets it after conversing with the assignee.

Just as I wrote to Erik: in Python, we don't set due dates. It's all
volunteers, so you can't force anybody to do something by a certain
date.

Even release plans follow that principle: the release (alpha, beta, rc,
final) is on a scheduled date; what is done by that date is done, what
isn't, is not done. So if somebody misses beta1, the new feature has
to wait for the next release.

> Let's be minimal and fast on this first go.

That is very reasonable. So far, we have used something like
"target milestones" only during releases so far, and the next
release is well ahead (late 2007, early 2008; 2.5.1 will be
released earlier, but we won't have new features in it).

Regards,
Martin

From seefeld at sympatico.ca  Sun Nov 26 13:56:20 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 07:56:20 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45695681.2000505@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>
	<45695681.2000505@v.loewis.de>
Message-ID: <45698EF4.1010701@sympatico.ca>

Martin v. L?wis wrote:
> Paul Dubois schrieb:
>> I think the design discussion of 'milestone' tells us that we don't yet
>> know what we want so we should push that back to 'phase 2'. FWIW
>> certainly we set the due date from the issue; we have a meeting, decide
>> what goes in the next release, and the group leader goes and sets the
>> due date, or sets it after conversing with the assignee.
> 
> Just as I wrote to Erik: in Python, we don't set due dates. It's all
> volunteers, so you can't force anybody to do something by a certain
> date.
> 
> Even release plans follow that principle: the release (alpha, beta, rc,
> final) is on a scheduled date; what is done by that date is done, what
> isn't, is not done. So if somebody misses beta1, the new feature has
> to wait for the next release.

This is why I see milestones almost *defined* by the list of bugs they
contain: instead of assigning due dates to bugs, you define a milestone
to be reached once a set of bugs is fixed.

This is what I used in other projects, and I thought it might work
well in python-dev, too.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sun Nov 26 14:12:17 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 08:12:17 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45695529.9030809@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<87ac2fku95.fsf@uterus.efod.se> <45695529.9030809@v.loewis.de>
Message-ID: <456992B1.8080802@sympatico.ca>

Martin v. L?wis wrote:
> Erik Forsberg schrieb:
>> I fully agree that you should be able to turn a feature request into a
>> bug very easily, and that is exactly why I think the main class should
>> not be named "bug". I don't want another class for feature requests, I
>> want the main class to cover as many types of issues (see, there it is
>> again, the perfect word for it! :) as possible. 
> 
> I may have missed some discussion; IMO, to the end user, the name
> of the main class should be invisible. It can be called "bug", "issue",
> "contribution", or "jabberwocky". As an end user, I don't want to have
> to type the name of the main class into the computer, ever. In
> particular, I hope that I can refer to some issue as
> bugs.python.org/<issue>.

Well, by default, <issue> in roundup is spelled <issue_class_name><id>

i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
apache rewrite rules.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sun Nov 26 15:00:24 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 09:00:24 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456992B1.8080802@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>
	<45695529.9030809@v.loewis.de> <456992B1.8080802@sympatico.ca>
Message-ID: <45699DF8.8050001@sympatico.ca>

Stefan Seefeld wrote:

> Well, by default, <issue> in roundup is spelled <issue_class_name><id>
> 
> i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
> apache rewrite rules.

Oh, and the same name appears in mail subject lines (and is required
for replies to the tracker to be dispatched properly).

So, the issue class name and id will be visible to users.


Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From g.brandl at gmx.net  Sun Nov 26 16:39:31 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 26 Nov 2006 16:39:31 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45699DF8.8050001@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>
	<456992B1.8080802@sympatico.ca> <45699DF8.8050001@sympatico.ca>
Message-ID: <4569B533.6000202@gmx.net>

Stefan Seefeld wrote:
> Stefan Seefeld wrote:
> 
>> Well, by default, <issue> in roundup is spelled <issue_class_name><id>
>> 
>> i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
>> apache rewrite rules.
> 
> Oh, and the same name appears in mail subject lines (and is required
> for replies to the tracker to be dispatched properly).
> 
> So, the issue class name and id will be visible to users.

Then I vote for "issue" instead of "bug".

(As a side, note, it would be nice to have http://bugs.python.org/12345
as the URI of an issue.)

Georg

From forsberg at efod.se  Sun Nov 26 16:46:39 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Sun, 26 Nov 2006 16:46:39 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45695529.9030809@v.loewis.de> (Martin v. =?iso-8859-1?Q?L=F6?=
	=?iso-8859-1?Q?wis's?= message of
	"Sun, 26 Nov 2006 09:49:45 +0100")
References: <455891F0.2050209@sympatico.ca>
	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>
	<87y7qfoz3r.fsf@uterus.efod.se> <4558F237.8030407@v.loewis.de>
	<87u012pkfm.fsf@uterus.efod.se> <87d57nq5oa.fsf_-_@uterus.efod.se>
	<45631769.6020200@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <87ac2fku95.fsf@uterus.efod.se>
	<45695529.9030809@v.loewis.de>
Message-ID: <87bqmujjmo.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Martin v. L?wis" <martin at v.loewis.de> writes:

> I may have missed some discussion; IMO, to the end user, the name
> of the main class should be invisible. It can be called "bug", "issue",
> "contribution", or "jabberwocky". As an end user, I don't want to have
> to type the name of the main class into the computer, ever. In
> particular, I hope that I can refer to some issue as
> bugs.python.org/<issue>.

I think we can promise bugs.python.org/issue<N>, and getting rid of
"issue" is probably also possible using some Apache redirect magic.

I agree that the name of the main class is an implementation detail
that should be hidden for the user. For me, it's better if it's called
'issue' as this is the default in roundup, which means less confusion
when borrowing code from other roundup installations. 

> In Python, we never do that. By default, all contributions are targeted
> for the next release, with two exceptions: when the next release is
> close, we tell (in natural language) the submitter that there is no
> chance it can go into this release. The other exception is that some
> patches are submitted towards Python 3 now.

Thanks! This is exactly the kind of information I wanted!

> SF has a field indicating a version number - we use that to record
> in what version a bug was found, so it always talks about past versions,
> not future versions.

The current test tracker also has this field, and keeps the semantics
of recording in what version the bug first was found.

> We currently use priorities to show
> - that a submission should be integrated into the next release if
>   at all possible
> - that a submission blocks a release, i.e. we can't release without
>   that issue being resolved
> That distinction is mostly made just before a release; a single
> "target version" field would not help as it would not distinguish
> between blockers and non-blockers.

Could we use dependencies to track blockers? The release manager could
add a bug "Release Python 2.6" and then add the blocker bugs as
dependencies to this bug. As long as the blocker bugs are not closed,
the dependencies are not resolved, and the release can't be done. 

Perhaps not optimal, but it might be a way to do it without further
schema changes. 

>> The above provided as an example of why I think being able to set
>> milestones from the bug display is important. The python-dev people
>> might use a completely different procedure (some kind of Silly Walk,
>> perhaps? :)  )
>
> See above. In open source, it is really unrealistic to assume that
> a bug can be fixed with a given deadline. It may well take years
> to fix a certain bug even if the bug is critical in some contexts.
> Even for patches, we now have patches that have been completely
> unreviewed for more than three years. So setting target versions
> is just day-dreaming.

OK. Given this information, I'll have to agree with Paul - let's not
add any milestone field at this point since there's no consensus on
its usability. Let's instead focus on getting the new tracker live
without too many new fancy features. 

I suggest the following:

1) Let's rename the 'bug' class back to 'issue'. I see no pros with
   naming it 'bug', only cons. Paul seems to agree.

2) Re-add the 'priority' field, to allow python-dev to use it as used
   before (to show if an issue should be included or not in the next
   release). We could add the extra twist that only people with the
   developer role can change it.

I suggest that we freeze schema changes here, to make it possible to
work on the importer and detectors without having to adjust for a
moving target.

3) Get the importer and detectors working. More specifically, I think
   we need to close the issues marked as "bug" in
   http://psf.upfronthosting.co.za/roundup/meta/issue

4) Import once, and let python-dev look at it for a week to see if
   they can come up with any showstoppers. During this week, I'd like
   release managers to try doing their thing using the test data to
   make sure it's possible to do releases using the new tracker. 

   I think testing with live data gives a better view of how roundup
   works, which is why I'm suggesting this step. It also gives us a
   chance to find any outstanding bugs in the importer. 

5) If there are no big showstopper issues in phase 4), import again
   and go live!

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFabbfrJurFAusidkRAkq0AKCJY8/3pLzbpb3UQk57dRjqv+uSmwCfaK11
sKLe7QqCwozUZaCynRuDRb4=
=RJ7B
-----END PGP SIGNATURE-----

From martin at v.loewis.de  Sun Nov 26 19:09:10 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 19:09:10 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <45698EF4.1010701@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>	<45695681.2000505@v.loewis.de>
	<45698EF4.1010701@sympatico.ca>
Message-ID: <4569D846.5000800@v.loewis.de>

Stefan Seefeld schrieb:
> This is why I see milestones almost *defined* by the list of bugs they
> contain: instead of assigning due dates to bugs, you define a milestone
> to be reached once a set of bugs is fixed.
> 
> This is what I used in other projects, and I thought it might work
> well in python-dev, too.

I can't see how: what would examples for milestones be? You seem
not to be talking about releases here. If not, what is the purpose
of having milestones in the first place?

Regards,
Martin

From martin at v.loewis.de  Sun Nov 26 19:12:42 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 19:12:42 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456992B1.8080802@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>
	<45695529.9030809@v.loewis.de> <456992B1.8080802@sympatico.ca>
Message-ID: <4569D91A.4050706@v.loewis.de>

Stefan Seefeld schrieb:
> Well, by default, <issue> in roundup is spelled <issue_class_name><id>
> 
> i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
> apache rewrite rules.

I would appreciate that, yes; it doesn't have to work that way from
the beginning, though. There must be stable, minimal URLs for issues
IMO because people will type them by hand, or at least copy them
from their web browser.

It may be that http://bugs.python.org/roundup/issue234782 would
be considered as "short enough" by others, so don't take my word
as definitive.

Regards,
Martin

From martin at v.loewis.de  Sun Nov 26 19:43:21 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 19:43:21 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87bqmujjmo.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>
	<87bqmujjmo.fsf@uterus.efod.se>
Message-ID: <4569E049.1020700@v.loewis.de>

Erik Forsberg schrieb:
> Could we use dependencies to track blockers? The release manager could
> add a bug "Release Python 2.6" and then add the blocker bugs as
> dependencies to this bug. As long as the blocker bugs are not closed,
> the dependencies are not resolved, and the release can't be done. 

I think that could work. The list of blockers is typically short,
so we have even used a wiki page in the past. Using a separate issue
should work fine.

> I suggest the following:

Sounds all fine with me.

Regards,
Martin

From seefeld at sympatico.ca  Sun Nov 26 23:31:16 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 17:31:16 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4569B533.6000202@gmx.net>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>
	<456992B1.8080802@sympatico.ca> <45699DF8.8050001@sympatico.ca>
	<4569B533.6000202@gmx.net>
Message-ID: <456A15B4.50005@sympatico.ca>

Georg Brandl wrote:
> Stefan Seefeld wrote:
>> Stefan Seefeld wrote:
>>
>>> Well, by default, <issue> in roundup is spelled <issue_class_name><id>
>>>
>>> i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
>>> apache rewrite rules.
>>
>> Oh, and the same name appears in mail subject lines (and is required
>> for replies to the tracker to be dispatched properly).
>>
>> So, the issue class name and id will be visible to users.
> 
> Then I vote for "issue" instead of "bug".

OK, issue it will be, then.

> (As a side, note, it would be nice to have http://bugs.python.org/12345
> as the URI of an issue.)

Well, to be consistent you should at least have http://issues.python.org/12345. :-)

But there is another point:

The reason the issue class name is part of the URL is that roundup provides
the means to serve multiple entities. For example you may want to change your
own contact address, which roundup stores as a property of a 'user' class.
So you may want to access 'http://issues.python.org/user25', or do the same
by mail using the subject line starting with [user25]. For roundup that is
conceptually the same as if you changed 'issue12', say.

Regards,
		Stefan


-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sun Nov 26 23:34:16 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 17:34:16 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4569D91A.4050706@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>
	<45695529.9030809@v.loewis.de> <456992B1.8080802@sympatico.ca>
	<4569D91A.4050706@v.loewis.de>
Message-ID: <456A1668.9070209@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> Well, by default, <issue> in roundup is spelled <issue_class_name><id>
>>
>> i.e. 'issue35', or 'bug266'. If you don't want that we have to play with
>> apache rewrite rules.
> 
> I would appreciate that, yes; it doesn't have to work that way from
> the beginning, though. There must be stable, minimal URLs for issues
> IMO because people will type them by hand, or at least copy them
> from their web browser.

See my other reply concerning the appearance (or not) of the issue class
name in the URL.

> It may be that http://bugs.python.org/roundup/issue234782 would
> be considered as "short enough" by others, so don't take my word
> as definitive.

Well, at least 'roundup/' is redundant in the URL above, so it can indeed
be further shortened. To my eye 'http://issues.python.org/issue36' is
as short as you can make it, without removing useful information.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Sun Nov 26 23:38:05 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 17:38:05 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4569D846.5000800@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>	<45695681.2000505@v.loewis.de>
	<45698EF4.1010701@sympatico.ca> <4569D846.5000800@v.loewis.de>
Message-ID: <456A174D.3030800@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> This is why I see milestones almost *defined* by the list of bugs they
>> contain: instead of assigning due dates to bugs, you define a milestone
>> to be reached once a set of bugs is fixed.
>>
>> This is what I used in other projects, and I thought it might work
>> well in python-dev, too.
> 
> I can't see how: what would examples for milestones be? You seem
> not to be talking about releases here. If not, what is the purpose
> of having milestones in the first place?

If you define milestone 1 .. milestone N, and assign issues to them,
this is a way to prioritize issues, and a way to measure how close you
are to the next milestone. 'X issues left before the next release' is
useful information to have, isn't it ? Of course, you can attach more
to a milestone (such as an ETA).
I only introduced it as a suggestion to replace numerical priorities.

Whether this makes sense for your development process is something I
can't judge at all.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Sun Nov 26 23:48:10 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 23:48:10 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456A15B4.50005@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>	<456992B1.8080802@sympatico.ca>
	<45699DF8.8050001@sympatico.ca>	<4569B533.6000202@gmx.net>
	<456A15B4.50005@sympatico.ca>
Message-ID: <456A19AA.8060004@v.loewis.de>

Stefan Seefeld schrieb:
> The reason the issue class name is part of the URL is that roundup provides
> the means to serve multiple entities. For example you may want to change your
> own contact address, which roundup stores as a property of a 'user' class.
> So you may want to access 'http://issues.python.org/user25', or do the same
> by mail using the subject line starting with [user25]. For roundup that is
> conceptually the same as if you changed 'issue12', say.

While that is the technical reason, it is no justification. For users,
there *is* a notion of a "main" class. So it is fine that "user25" is
a valid object id - still "12" could be the id of an object on its
own (namely, "issue12"). If one class is designated the "main" class,
URLs that start with numbers could uniquely identify objects of the
main class - ids of other classes would continue to start with the
class name.

Support for the notion of a "main" class could be in roundup itself,
or it could be in Apache rewrite rules.

Regards,
Martin

From martin at v.loewis.de  Sun Nov 26 23:55:39 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 26 Nov 2006 23:55:39 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456A174D.3030800@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<f74a6c2f0611251607u6be40c3cnd9bec98b928f0f14@mail.gmail.com>	<45695681.2000505@v.loewis.de>	<45698EF4.1010701@sympatico.ca>
	<4569D846.5000800@v.loewis.de> <456A174D.3030800@sympatico.ca>
Message-ID: <456A1B6B.2090908@v.loewis.de>

Stefan Seefeld schrieb:
> If you define milestone 1 .. milestone N, and assign issues to them,
> this is a way to prioritize issues, and a way to measure how close you
> are to the next milestone. 'X issues left before the next release' is
> useful information to have, isn't it ? Of course, you can attach more
> to a milestone (such as an ETA).
> I only introduced it as a suggestion to replace numerical priorities.
> 
> Whether this makes sense for your development process is something I
> can't judge at all.

Ah, ok. I'd say it makes no sense. The Python project has a single
milestone at the moment: Python 3000. It didn't have any milestones
before (perhaps Python 2 was one, as well), and it may not have any
milestones afterwards.

There really isn't any "planning" of features. Features get added when
there implementation is complete; it's not that people stop working
on something and work on something else just because it is deemed
more important.

Even priorities are largely irrelevant. Contributors have their own
views of what issues are important; some value backwards compatibility
and put efforts into *not* adding new features (because they fear
incompatibility), others value reliability of the interpreter and
fixes reported ways of crashing the interpreter the day those are
reported.

Regards,
Martin

From seefeld at sympatico.ca  Mon Nov 27 02:48:42 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Sun, 26 Nov 2006 20:48:42 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <87bqmujjmo.fsf@uterus.efod.se>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>
	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>
	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>
	<87bqmujjmo.fsf@uterus.efod.se>
Message-ID: <456A43FA.2040507@sympatico.ca>

Erik Forsberg wrote:
> "Martin v. L?wis" <martin at v.loewis.de> writes:

>>> In Python, we never do that. By default, all contributions are targeted
>>> for the next release, with two exceptions: when the next release is
>>> close, we tell (in natural language) the submitter that there is no
>>> chance it can go into this release. The other exception is that some
>>> patches are submitted towards Python 3 now.
> 
> Thanks! This is exactly the kind of information I wanted!
> 
>>> SF has a field indicating a version number - we use that to record
>>> in what version a bug was found, so it always talks about past versions,
>>> not future versions.
> 
> The current test tracker also has this field, and keeps the semantics
> of recording in what version the bug first was found.
> 
>>> We currently use priorities to show
>>> - that a submission should be integrated into the next release if
>>>   at all possible
>>> - that a submission blocks a release, i.e. we can't release without
>>>   that issue being resolved
>>> That distinction is mostly made just before a release; a single
>>> "target version" field would not help as it would not distinguish
>>> between blockers and non-blockers.
> 
> Could we use dependencies to track blockers? The release manager could
> add a bug "Release Python 2.6" and then add the blocker bugs as
> dependencies to this bug. As long as the blocker bugs are not closed,
> the dependencies are not resolved, and the release can't be done. 
> 
> Perhaps not optimal, but it might be a way to do it without further
> schema changes. 

I'm a bit confused now (about Martin's use case): I suggested milestones
to replace priorities with much stronger semantics, as this would allow
to express the relationship of 'this bug needs to be fixed before that
milestone is complete'. What you, Erik, suggest here with a fake bug
and the dependencies property sounds like an attempt to do the exact
same without having to introduce the 'milestone' issue type.

Am I missing something ?

>>>> The above provided as an example of why I think being able to set
>>>> milestones from the bug display is important. The python-dev people
>>>> might use a completely different procedure (some kind of Silly Walk,
>>>> perhaps? :)  )
>>> See above. In open source, it is really unrealistic to assume that
>>> a bug can be fixed with a given deadline. It may well take years
>>> to fix a certain bug even if the bug is critical in some contexts.
>>> Even for patches, we now have patches that have been completely
>>> unreviewed for more than three years. So setting target versions
>>> is just day-dreaming.

So how does this compare to your statement above that an issue may
block a release ?

> OK. Given this information, I'll have to agree with Paul - let's not
> add any milestone field at this point since there's no consensus on
> its usability. Let's instead focus on getting the new tracker live
> without too many new fancy features. 

I agree. My current plan is to switch 'bug' back to 'issue', and resolve
the bugs we have discovered in the templates so far.

> I suggest the following:
> 
> 1) Let's rename the 'bug' class back to 'issue'. I see no pros with
>    naming it 'bug', only cons. Paul seems to agree.

Right.

> 2) Re-add the 'priority' field, to allow python-dev to use it as used
>    before (to show if an issue should be included or not in the next
>    release). We could add the extra twist that only people with the
>    developer role can change it.

Here I disagree, or at least, I ask for clarification: either it is important
to be able to tag blockers, in which case milestones seems to be a much
better approach, or it isn't, in which case priorities don't really add
anything. Can someone please help me see the light ?

> I suggest that we freeze schema changes here, to make it possible to
> work on the importer and detectors without having to adjust for a
> moving target.

Sounds good. I'd still like to fine-tune the enumerators: what 'types',
'platforms', 'versions', 'status', 'resolution', etc. should be set
during initialization, and what is the mapping from the sf.net tracker
to these ?

> 3) Get the importer and detectors working. More specifically, I think
>    we need to close the issues marked as "bug" in
>    http://psf.upfronthosting.co.za/roundup/meta/issue
> 
> 4) Import once, and let python-dev look at it for a week to see if
>    they can come up with any showstoppers. During this week, I'd like
>    release managers to try doing their thing using the test data to
>    make sure it's possible to do releases using the new tracker. 
> 
>    I think testing with live data gives a better view of how roundup
>    works, which is why I'm suggesting this step. It also gives us a
>    chance to find any outstanding bugs in the importer. 
> 
> 5) If there are no big showstopper issues in phase 4), import again
>    and go live!


Sounds good to me.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Mon Nov 27 05:48:09 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 26 Nov 2006 20:48:09 -0800
Subject: [Tracker-discuss] Schema
Message-ID: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>

(A) Martin said, which I think sets the list of versions (and also means it
is a single value, not a set):

>
> >
> >>> SF has a field indicating a version number - we use that to record
> >>> in what version a bug was found, so it always talks about past
> versions,
> >>> not future versions.
> >


(B) and he said:

> >>> We currently use priorities to show
> >>> - that a submission should be integrated into the next release if
> >>>   at all possible
> >>> - that a submission blocks a release, i.e. we can't release without
> >>>   that issue being resolved
> >>> That distinction is mostly made just before a release; a single
> >>> "target version" field would not help as it would not distinguish
> >>> between blockers and non-blockers.



and suggestions were made about how to deal with blockers. So to sum up what
Martin and others have said, they do not use priorities except for this
pre-release period.
 Here is another idea for this then: don't have a priority but do have a
check box or yes/no (probably visible, or at least writeable, by Developers)
that says something like 'Needed for next release if at all possible'. Then
a simple search will find all such issues that are still open, etc.

C. Question: did someone say we should have this platform thing? Since a
platform-dependent bug is probably less frequent than one that is not, we at
least have to make platform-independent the default.

Since the text of the complaint should contain this information, it seems
redundant and messy to me, especially since we can't possibly deal with all
the new platforms that will arise. (Solaris on an X-Box 380).


> The rest of the plan is good with me. BTW I'm still having trouble posting
to the draft tracker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061126/acfa0683/attachment-0001.htm 

From nnorwitz at gmail.com  Mon Nov 27 06:58:44 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sun, 26 Nov 2006 21:58:44 -0800
Subject: [Tracker-discuss] Schema
In-Reply-To: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
Message-ID: <ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>

On 11/26/06, Paul Dubois <pfdubois at gmail.com> wrote:
>
>  and suggestions were made about how to deal with blockers. So to sum up
> what Martin and others have said, they do not use priorities except for this
> pre-release period.

This is mostly true, but let me clarify.  Priorities are typically
only *reviewed* just before release. Typically I'll assign any bug
that crashes the interpreter a 7-9.  I do this when I first see the
bug report.  These high priority bugs usually don't stay open very
long.  We also set some regressions to a higher priority.

During release, we used priority 8 to signal the bug should be fixed
if possible before release.  Priority 9 was used for bugs that were
showstoppers.  They had to be fixed before release.  7's were
sometimes also used, but that was only for information and didn't
affect release.

>  Here is another idea for this then: don't have a priority but do have a
> check box or yes/no (probably visible, or at least writeable, by Developers)
> that says something like 'Needed for next release if at all possible'. Then
> a simple search will find all such issues that are still open, etc.

Since it's not a boolean this won't really work.  See above.

n

From pfdubois at gmail.com  Mon Nov 27 07:42:11 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Sun, 26 Nov 2006 22:42:11 -0800
Subject: [Tracker-discuss] Schema
In-Reply-To: <ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>
Message-ID: <f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>

So it sounds like there are really 4 values?
normal
high
fix if possible before release
showstopper

As I've said before, I think it is better to use words, not numbers, and
especially not operationally meaningless distinctions like 4 vs. 5


On 11/26/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
>
> On 11/26/06, Paul Dubois <pfdubois at gmail.com> wrote:
> >
> >  and suggestions were made about how to deal with blockers. So to sum up
> > what Martin and others have said, they do not use priorities except for
> this
> > pre-release period.
>
> This is mostly true, but let me clarify.  Priorities are typically
> only *reviewed* just before release. Typically I'll assign any bug
> that crashes the interpreter a 7-9.  I do this when I first see the
> bug report.  These high priority bugs usually don't stay open very
> long.  We also set some regressions to a higher priority.
>
> During release, we used priority 8 to signal the bug should be fixed
> if possible before release.  Priority 9 was used for bugs that were
> showstoppers.  They had to be fixed before release.  7's were
> sometimes also used, but that was only for information and didn't
> affect release.
>
> >  Here is another idea for this then: don't have a priority but do have a
> > check box or yes/no (probably visible, or at least writeable, by
> Developers)
> > that says something like 'Needed for next release if at all possible'.
> Then
> > a simple search will find all such issues that are still open, etc.
>
> Since it's not a boolean this won't really work.  See above.
>
> n
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061126/b4ba385a/attachment.html 

From g.brandl at gmx.net  Mon Nov 27 08:35:05 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 27 Nov 2006 08:35:05 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>
	<f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
Message-ID: <456A9529.2010806@gmx.net>

Paul Dubois wrote:
> So it sounds like there are really 4 values?
> normal
> high
> fix if possible before release
> showstopper

Add something like "low", and I think it's a reasonable selection.

> As I've said before, I think it is better to use words, not numbers, and 
> especially not operationally meaningless distinctions like 4 vs. 5

Totally Ack.

Georg

From nnorwitz at gmail.com  Mon Nov 27 09:07:55 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Mon, 27 Nov 2006 00:07:55 -0800
Subject: [Tracker-discuss] Schema
In-Reply-To: <456A9529.2010806@gmx.net>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>
	<f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
	<456A9529.2010806@gmx.net>
Message-ID: <ee2a432c0611270007i3c2a8740ub82f79e3c9e30158@mail.gmail.com>

On 11/26/06, Georg Brandl <g.brandl at gmx.net> wrote:
> Paul Dubois wrote:
> > So it sounds like there are really 4 values?
> > normal
> > high
> > fix if possible before release
> > showstopper
>
> Add something like "low", and I think it's a reasonable selection.

Works for me.

n

From forsberg at efod.se  Mon Nov 27 09:16:01 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Mon, 27 Nov 2006 09:16:01 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <ee2a432c0611270007i3c2a8740ub82f79e3c9e30158@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
	<456A9529.2010806@gmx.net>
	<ee2a432c0611270007i3c2a8740ub82f79e3c9e30158@mail.gmail.com>
Message-ID: <200611270916.02025.forsberg@efod.se>

m?ndag 27 november 2006 09:07 skrev Neal Norwitz:
> On 11/26/06, Georg Brandl <g.brandl at gmx.net> wrote:
> > Paul Dubois wrote:
> > > So it sounds like there are really 4 values?
> > > normal
> > > high
> > > fix if possible before release
> > > showstopper
> >
> > Add something like "low", and I think it's a reasonable selection.
>
> Works for me.

OK. I suggest that the importer will translate SF priorities as follows:

9 -> showstopper
8 -> fix if possible before release
7 -> high
6 -> normal
1-5 -> low

Does that sound reasonable?

Cheers,
\EF
-- 
http://efod.se/

From martin at v.loewis.de  Mon Nov 27 09:35:09 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 09:35:09 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456A43FA.2040507@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>	<87bqmujjmo.fsf@uterus.efod.se>
	<456A43FA.2040507@sympatico.ca>
Message-ID: <456AA33D.4020807@v.loewis.de>

Stefan Seefeld schrieb:
> I'm a bit confused now (about Martin's use case): I suggested milestones
> to replace priorities with much stronger semantics, as this would allow
> to express the relationship of 'this bug needs to be fixed before that
> milestone is complete'. What you, Erik, suggest here with a fake bug
> and the dependencies property sounds like an attempt to do the exact
> same without having to introduce the 'milestone' issue type.

No, it's not the exact same. With a milestone system, I understood that
you would associate each bug with a milestone. With the release
blockers, only selected few bugs block a release; most bugs never block
any release.

>>>> See above. In open source, it is really unrealistic to assume that
>>>> a bug can be fixed with a given deadline. It may well take years
>>>> to fix a certain bug even if the bug is critical in some contexts.
>>>> Even for patches, we now have patches that have been completely
>>>> unreviewed for more than three years. So setting target versions
>>>> is just day-dreaming.
> 
> So how does this compare to your statement above that an issue may
> block a release ?

Like so: if we have a true release blocker, we can't release. If
nobody fixes the blocker, we can't release, period. It's not that
we tell somebody "fix it by this and that day", but instead,
we tell everybody "if it doesn't get fixed, we can't release".
In many cases, this encourages some volunteer to contribute a fix.
In some cases, the release manager then may decide "maybe it isn't
a release blocker, after all"; there are no hard criteria for it.
In other cases, the release manager himself fixes it, just so that
the release can proceed.

>> 2) Re-add the 'priority' field, to allow python-dev to use it as used
>>    before (to show if an issue should be included or not in the next
>>    release). We could add the extra twist that only people with the
>>    developer role can change it.
> 
> Here I disagree, or at least, I ask for clarification: either it is important
> to be able to tag blockers, in which case milestones seems to be a much
> better approach, or it isn't, in which case priorities don't really add
> anything. Can someone please help me see the light ?

I doubt it, somewhat. I, too, see the introduction of milestones as an
unnecessary complication, because I don't see how they should get used.
Its more a gut feeling "please leave this simple", than any objective
evaluation. I understand that it is easy to introduce such a feature
later.

Regards,
Martin


From martin at v.loewis.de  Mon Nov 27 09:44:13 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 09:44:13 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
Message-ID: <456AA55D.7030502@v.loewis.de>

Paul Dubois schrieb:
> and suggestions were made about how to deal with blockers. So to sum up
> what Martin and others have said, they do not use priorities except for
> this pre-release period.

I forgot to mention another use case for priorities: some developers
use them to prioritize things for themselves. Some of my issues have
priority 7, indicating that these are the ones I want to look at next.
(priority 8 is used for "please really work on it for the next release",
and 9 is "blocker").

>  Here is another idea for this then: don't have a priority but do have a
> check box or yes/no (probably visible, or at least writeable, by
> Developers) that says something like 'Needed for next release if at all
> possible'. Then a simple search will find all such issues that are still
> open, etc.

That would also work, IMO.

> C. Question: did someone say we should have this platform thing? Since a
> platform-dependent bug is probably less frequent than one that is not,
> we at least have to make platform-independent the default.

(can't look at the demo tracker right now)

It's true that platform-specific bugs are rare; they typically involve
either Apple OS X or MS Windows (and often are packaging problems).
It would be good to be able to search for Windows bugs; I don't think
anybody wants to search for HP-UX-specific problems.

Grouping these two platforms with a list of functional groups (like
regular expressions, XML) might work just fine: a bug in one of these
functional groups is typically not platform-specific.

Regards,
Martin


From martin at v.loewis.de  Mon Nov 27 09:46:39 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 09:46:39 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>
	<f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
Message-ID: <456AA5EF.9000100@v.loewis.de>

Paul Dubois schrieb:
> So it sounds like there are really 4 values?
> normal
> high
> fix if possible before release
> showstopper
> 
> As I've said before, I think it is better to use words, not numbers, and
> especially not operationally meaningless distinctions like 4 vs. 5

I think that would describe it well. Submitters sometimes also want to
assign "low"; they use numbers below 5. I'm not sure whether this is
an important distinction.

Regards,
Martin

From martin at v.loewis.de  Mon Nov 27 09:48:09 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 09:48:09 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <200611270916.02025.forsberg@efod.se>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>	<456A9529.2010806@gmx.net>	<ee2a432c0611270007i3c2a8740ub82f79e3c9e30158@mail.gmail.com>
	<200611270916.02025.forsberg@efod.se>
Message-ID: <456AA649.1030201@v.loewis.de>

Erik Forsberg schrieb:
> OK. I suggest that the importer will translate SF priorities as follows:
> 
> 9 -> showstopper
> 8 -> fix if possible before release
> 7 -> high
> 6 -> normal
> 1-5 -> low
> 
> Does that sound reasonable?

The default (5) should probably be "normal" (i.e. 6 and 7 is "high");
otherwise, it's fine.

Regards,
Martin

From seefeld at sympatico.ca  Mon Nov 27 15:07:24 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 27 Nov 2006 09:07:24 -0500
Subject: [Tracker-discuss] Schema
In-Reply-To: <456AA5EF.9000100@v.loewis.de>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>	<f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>
	<456AA5EF.9000100@v.loewis.de>
Message-ID: <456AF11C.6060807@sympatico.ca>

Martin v. L?wis wrote:
> Paul Dubois schrieb:
>> So it sounds like there are really 4 values?
>> normal
>> high
>> fix if possible before release
>> showstopper
>>
>> As I've said before, I think it is better to use words, not numbers, and
>> especially not operationally meaningless distinctions like 4 vs. 5
> 
> I think that would describe it well. Submitters sometimes also want to
> assign "low"; they use numbers below 5. I'm not sure whether this is
> an important distinction.

For avoidance of doubt: are you expecting any submitters to be able to set
the priority ? I thought we had agreed that this was the privilege of
developers, i.e. that *user* would use a *severity* instead. (See current
schema.)
I really do think that the distinction between severity and priority
should be made, no matter how you actually spell the two.

(In my current schema, as well as the live tracker, the 'priority field'
 can be set if you are logged in as developer. Thus, creating an issue
as developer should let you set it during creation, too, but not as a
user.)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Mon Nov 27 15:14:26 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 27 Nov 2006 09:14:26 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456AA33D.4020807@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>	<87ac2fku95.fsf@uterus.efod.se>	<45695529.9030809@v.loewis.de>	<87bqmujjmo.fsf@uterus.efod.se>
	<456A43FA.2040507@sympatico.ca> <456AA33D.4020807@v.loewis.de>
Message-ID: <456AF2C2.10600@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> I'm a bit confused now (about Martin's use case): I suggested milestones
>> to replace priorities with much stronger semantics, as this would allow
>> to express the relationship of 'this bug needs to be fixed before that
>> milestone is complete'. What you, Erik, suggest here with a fake bug
>> and the dependencies property sounds like an attempt to do the exact
>> same without having to introduce the 'milestone' issue type.
> 
> No, it's not the exact same. With a milestone system, I understood that
> you would associate each bug with a milestone. With the release
> blockers, only selected few bugs block a release; most bugs never block
> any release.

I see. Well, as Erik suggested, the links from milestone to bugs could be
annotated, i.e. for some bugs being set in a milestone are mere
estimates, for others they are hard requirements.

You could equally well use the milestone type to only list those bugs
that are strictly required.


> 
>>>>> See above. In open source, it is really unrealistic to assume that
>>>>> a bug can be fixed with a given deadline. It may well take years
>>>>> to fix a certain bug even if the bug is critical in some contexts.
>>>>> Even for patches, we now have patches that have been completely
>>>>> unreviewed for more than three years. So setting target versions
>>>>> is just day-dreaming.
>> So how does this compare to your statement above that an issue may
>> block a release ?
> 
> Like so: if we have a true release blocker, we can't release. If
> nobody fixes the blocker, we can't release, period. It's not that
> we tell somebody "fix it by this and that day", but instead,
> we tell everybody "if it doesn't get fixed, we can't release".

Right, that's exactly what I have in mind with my 'milestone' proposal.

> In many cases, this encourages some volunteer to contribute a fix.
> In some cases, the release manager then may decide "maybe it isn't
> a release blocker, after all"; there are no hard criteria for it.

...in which case he would remove it from the milestone.

> In other cases, the release manager himself fixes it, just so that
> the release can proceed.

even better. :-)

> 
>>> 2) Re-add the 'priority' field, to allow python-dev to use it as used
>>>    before (to show if an issue should be included or not in the next
>>>    release). We could add the extra twist that only people with the
>>>    developer role can change it.
>> Here I disagree, or at least, I ask for clarification: either it is important
>> to be able to tag blockers, in which case milestones seems to be a much
>> better approach, or it isn't, in which case priorities don't really add
>> anything. Can someone please help me see the light ?
> 
> I doubt it, somewhat. I, too, see the introduction of milestones as an
> unnecessary complication, because I don't see how they should get used.
> Its more a gut feeling "please leave this simple", than any objective
> evaluation. I understand that it is easy to introduce such a feature
> later.

I agree.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Mon Nov 27 15:00:46 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Mon, 27 Nov 2006 09:00:46 -0500
Subject: [Tracker-discuss] schema updates
Message-ID: <456AEF8E.8030708@sympatico.ca>

Hi there,

I'v just checked in changes to the tracker to revert 'bug' to 'issue'
and re-add 'priority' (though with named values, not numbers), settable
for developers only.

The tracker has been reinitialized and restarted.


It sounds we are (finally) converging on the schema. I'd like people
to approve it, so we can then fine-tune the enumerators used that have
an impact on the work flow (i.e. will be used by auditors and notification
triggers, say).

Is it realistic to aim for the coming weekend (say, monday the 4th.) to
finish that part of the design ?

As soon as that is done, we should

* define the mapping from the sf.net schema to our new schema, so the
  importer can be adjusted.

* fine-tune the tracker behavior so we can complete the detectors.

* fine-tune the web interface.

* start experimenting with real data, i.e. use the importer.

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From Doug.Napoleone at nuance.com  Mon Nov 27 17:44:17 2006
From: Doug.Napoleone at nuance.com (Napoleone, Doug)
Date: Mon, 27 Nov 2006 11:44:17 -0500
Subject: [Tracker-discuss] Question on Multiple Projects
Message-ID: <37E3DF6920CC664D924AFA9966C33EE85227F3@bn-exchdmz>

Brett Cannon wrote:
> The long-term hope is to host the trackers for several 
> projects that have any direct ties to python-dev.  Let us 
> first get the python-dev tracker up and catch our breath.  
> Then we will evaluate how we want to handle adding more 
> trackers for other groups.

Thanks for the fast response and sorry I could not respond earlier.
We will go with another solution for at least the next 4 months.
Thanks for all your hard work, and hope to see you at PyCon2007!

    -doug

From brett at python.org  Mon Nov 27 21:26:17 2006
From: brett at python.org (Brett Cannon)
Date: Mon, 27 Nov 2006 12:26:17 -0800
Subject: [Tracker-discuss] schema updates
In-Reply-To: <456AEF8E.8030708@sympatico.ca>
References: <456AEF8E.8030708@sympatico.ca>
Message-ID: <bbaeab100611271226p78ad58cfy75843b02807c6015@mail.gmail.com>

My laptop is in the shop so I don't have my normal bookmakr for the meta and
test tracker URLs (which is why I have been so quiet as of late).  Can you
send them to me so I can at least spend what little computer time I do have
give it a quick look-over?

-Brett

On 11/27/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Hi there,
>
> I'v just checked in changes to the tracker to revert 'bug' to 'issue'
> and re-add 'priority' (though with named values, not numbers), settable
> for developers only.
>
> The tracker has been reinitialized and restarted.
>
>
> It sounds we are (finally) converging on the schema. I'd like people
> to approve it, so we can then fine-tune the enumerators used that have
> an impact on the work flow (i.e. will be used by auditors and notification
> triggers, say).
>
> Is it realistic to aim for the coming weekend (say, monday the 4th.) to
> finish that part of the design ?
>
> As soon as that is done, we should
>
> * define the mapping from the sf.net schema to our new schema, so the
>   importer can be adjusted.
>
> * fine-tune the tracker behavior so we can complete the detectors.
>
> * fine-tune the web interface.
>
> * start experimenting with real data, i.e. use the importer.
>
> Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061127/39e50f13/attachment.htm 

From martin at v.loewis.de  Mon Nov 27 23:52:30 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 23:52:30 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <37E3DF6920CC664D924AFA9966C33EE802DDC3@bn-exchdmz>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>
	<37E3DF6920CC664D924AFA9966C33EE802DDC3@bn-exchdmz>
Message-ID: <456B6C2E.8070906@v.loewis.de>

Napoleone, Doug schrieb:
> This was quite true when Mac was big-endian based. Now that they are intel
> based it would be good to have some way of identifying endian issues which
> do occur on HP-UX, older Mac's, Sun, etc.

The question is whether that warrants support in the tracker. I say no,
and I also doubt that the endianness issues affect HP-UX, Sun etc.
The issues we see are primarily cross-compilation issues, due to the
fat binary support. Those don't exist on pure big endian machines,
for which I believe the support is sufficient.

Regards,
Martin

From martin at v.loewis.de  Mon Nov 27 23:55:55 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 27 Nov 2006 23:55:55 +0100
Subject: [Tracker-discuss] Schema
In-Reply-To: <456AF11C.6060807@sympatico.ca>
References: <f74a6c2f0611262048x1cbf892dsc7b357aca1f89861@mail.gmail.com>	<ee2a432c0611262158o4981aad9g4663660d842de569@mail.gmail.com>	<f74a6c2f0611262242w6f270f14gaa89b004828380fe@mail.gmail.com>	<456AA5EF.9000100@v.loewis.de>
	<456AF11C.6060807@sympatico.ca>
Message-ID: <456B6CFB.3000709@v.loewis.de>

Stefan Seefeld schrieb:
> For avoidance of doubt: are you expecting any submitters to be able to set
> the priority ? I thought we had agreed that this was the privilege of
> developers, i.e. that *user* would use a *severity* instead. (See current
> schema.)

If that isn't supported, that's fine. I said that submitters sometimes
*want* to express that they consider their issue of little importance
(just as they more often want to express that it is of high importance)
- on both cases, to them, that is.

> (In my current schema, as well as the live tracker, the 'priority field'
>  can be set if you are logged in as developer. Thus, creating an issue
> as developer should let you set it during creation, too, but not as a
> user.)

That's fine.

Regards,
Martin

From pfdubois at gmail.com  Tue Nov 28 01:22:59 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Mon, 27 Nov 2006 16:22:59 -0800
Subject: [Tracker-discuss] schema updates
In-Reply-To: <bbaeab100611271226p78ad58cfy75843b02807c6015@mail.gmail.com>
References: <456AEF8E.8030708@sympatico.ca>
	<bbaeab100611271226p78ad58cfy75843b02807c6015@mail.gmail.com>
Message-ID: <f74a6c2f0611271622s19cfdd49v172d9f1556c8bcb1@mail.gmail.com>

http://psf.upfronthosting.co.za/roundup/tracker/

for the tracker, change tracker to meta for the meta.

On 11/27/06, Brett Cannon <brett at python.org> wrote:
>
> My laptop is in the shop so I don't have my normal bookmakr for the meta
> and test tracker URLs (which is why I have been so quiet as of late).  Can
> you send them to me so I can at least spend what little computer time I do
> have give it a quick look-over?
>
> -Brett
>
> On 11/27/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> >
> > Hi there,
> >
> > I'v just checked in changes to the tracker to revert 'bug' to 'issue'
> > and re-add 'priority' (though with named values, not numbers), settable
> > for developers only.
> >
> > The tracker has been reinitialized and restarted.
> >
> >
> > It sounds we are (finally) converging on the schema. I'd like people
> > to approve it, so we can then fine-tune the enumerators used that have
> > an impact on the work flow (i.e. will be used by auditors and
> > notification
> > triggers, say).
> >
> > Is it realistic to aim for the coming weekend (say, monday the 4th.) to
> > finish that part of the design ?
> >
> > As soon as that is done, we should
> >
> > * define the mapping from the sf.net schema to our new schema, so the
> >   importer can be adjusted.
> >
> > * fine-tune the tracker behavior so we can complete the detectors.
> >
> > * fine-tune the web interface.
> >
> > * start experimenting with real data, i.e. use the importer.
> >
> > Thanks,
> >                 Stefan
> >
> > --
> >
> >       ...ich hab' noch einen Koffer in Berlin...
> > _______________________________________________
> > Tracker-discuss mailing list
> > Tracker-discuss at python.org
> > http://mail.python.org/mailman/listinfo/tracker-discuss
> >
>
>
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061127/807f29c0/attachment-0001.htm 

From forsberg at efod.se  Tue Nov 28 07:34:37 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Tue, 28 Nov 2006 07:34:37 +0100
Subject: [Tracker-discuss] schema updates
In-Reply-To: <456AEF8E.8030708@sympatico.ca> (Stefan Seefeld's message of
	"Mon, 27 Nov 2006 09:00:46 -0500")
References: <456AEF8E.8030708@sympatico.ca>
Message-ID: <87hcwkkrk2.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seefeld <seefeld at sympatico.ca> writes:

> I'v just checked in changes to the tracker to revert 'bug' to 'issue'
> and re-add 'priority' (though with named values, not numbers), settable
> for developers only.
>
> The tracker has been reinitialized and restarted.

Nice!

> It sounds we are (finally) converging on the schema. I'd like people
> to approve it, so we can then fine-tune the enumerators used that have
> an impact on the work flow (i.e. will be used by auditors and notification
> triggers, say).
>
> Is it realistic to aim for the coming weekend (say, monday the 4th.) to
> finish that part of the design ?

Seems realistic to me. 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFa9h9rJurFAusidkRAhukAKDkbgjYXD/Ff2aqNo0qDHETgqihTwCeOfAS
p3oOOR926aZ4nx2evIw+i1U=
=G2Ze
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Thu Nov 30 13:39:55 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 07:39:55 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
Message-ID: <456ED11B.10508@sympatico.ca>

This is a little reminder to recall that we hope to settle on the new
python tracker schema by comming monday the 4th.

Please review and comment on the available fields at

http://psf.upfronthosting.co.za/roundup/tracker/

and in particular:

* type, severity, components, versions, platforms,
  as general issue descriptors

* status and its enumerators, as this is where most of the behavior
  will be determined. What are the possible states ? Which transitions
  are allowed (and by whom) ? What actions may these transitions trigger ?


As early as next week we may start importing the tracker data from
sf.net, as well as fine-tune the web interface. So the schema should
be settled by then.

Many thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Thu Nov 30 18:25:43 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 18:25:43 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456ED11B.10508@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
Message-ID: <456F1417.7030802@v.loewis.de>

Stefan Seefeld schrieb:
> Please review and comment on the available fields at
> 
> http://psf.upfronthosting.co.za/roundup/tracker/

How can I identify issues that have patches with them?

Regards,
Martin

From pfdubois at gmail.com  Thu Nov 30 19:04:25 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 10:04:25 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456ED11B.10508@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
Message-ID: <f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>

When one thinks about roundup users you need to remember that web interface
use will be small compared to email. This remark applies to items in the
schema, such as component or version or platform -- the email user will not
be setting these. They need 'not set' defaults so that a developer doing
triage can set them later.

The problem with the patch attached business is that many will submit the
patch by email attachment and they won't see any checkbox to check. Yes,
they could do it on the title line as in

Subject: blah blah [patch=yes]

but my users rarely know about this.

One cannot actually see the class list unless logged in as admin; if not
logged in at all they can't see half of it. I don't know the admin pw.
Anyway, this may limit the useful replies to Stefan's request for input.

I'm unclear about the version field. I think Martin said that should be only
past versions, indicating the version in which the person found the bug. For
an rfe it isn't going to make sense, so again it needs a not-set.

I think there was consensus that we don't need 'platform' (?). I hope not;
it would be a maintenance nightmare.





On 11/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> This is a little reminder to recall that we hope to settle on the new
> python tracker schema by comming monday the 4th.
>
> Please review and comment on the available fields at
>
> http://psf.upfronthosting.co.za/roundup/tracker/
>
> and in particular:
>
> * type, severity, components, versions, platforms,
>   as general issue descriptors
>
> * status and its enumerators, as this is where most of the behavior
>   will be determined. What are the possible states ? Which transitions
>   are allowed (and by whom) ? What actions may these transitions trigger ?
>
>
> As early as next week we may start importing the tracker data from
> sf.net, as well as fine-tune the web interface. So the schema should
> be settled by then.
>
> Many thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/15a73629/attachment.htm 

From forsberg at efod.se  Thu Nov 30 19:17:15 2006
From: forsberg at efod.se (Erik Forsberg)
Date: Thu, 30 Nov 2006 19:17:15 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	(Paul Dubois's message of "Thu, 30 Nov 2006 10:04:25 -0800")
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
Message-ID: <87irgw4x5g.fsf@uterus.efod.se>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Paul Dubois" <pfdubois at gmail.com> writes:

> When one thinks about roundup users you need to remember that web interface
> use will be small compared to email. This remark applies to items in the
> schema, such as component or version or platform -- the email user will not
> be setting these. They need 'not set' defaults so that a developer doing
> triage can set them later.
>
> The problem with the patch attached business is that many will submit the
> patch by email attachment and they won't see any checkbox to check. Yes,
> they could do it on the title line as in

I suggest that we add a "has patch" (or perhaps "has attachement")
property (boolean) on issue, and set it by detector. That way, it will
be easy (and efficient) to search for issues that have
attachements. Still, the users don't need to do anything, as it
happens automatically. 

Perhaps there's a better (and still effiecient) way of doing the same thing? 

\EF
- -- 
Erik Forsberg                 http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFFbyArrJurFAusidkRAmdMAKDb8eHQ74crBM7ga+yvUhsDb6ZkewCg4dmq
7c3xCo1NPb9GI9UHHjiT3pE=
=FfV8
-----END PGP SIGNATURE-----

From seefeld at sympatico.ca  Thu Nov 30 19:27:21 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 13:27:21 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
Message-ID: <456F2289.1050305@sympatico.ca>

Paul Dubois wrote:
> When one thinks about roundup users you need to remember that web
> interface use will be small compared to email. This remark applies to
> items in the schema, such as component or version or platform -- the
> email user will not be setting these. They need 'not set' defaults so
> that a developer doing triage can set them later.

I agree, all these need to have reasonably defaults.
However, I'm not so sure about the importance of email as far as
issue *creation* is concerned. I think it is reasonable to expect
users typically to use the web interface to create issues, and then
let any followup happen mostly by mail.

> The problem with the patch attached business is that many will submit
> the patch by email attachment and they won't see any checkbox to check.
> Yes, they could do it on the title line as in
> 
> Subject: blah blah [patch=yes]
> 
> but my users rarely know about this.

Right, that's cumbersome.

> One cannot actually see the class list unless logged in as admin; if not
> logged in at all they can't see half of it. I don't know the admin pw.
> Anyway, this may limit the useful replies to Stefan's request for input.

??

The schema is available in the repository, if you really want to see the
classes.
However, there isn't anything going on behind the scenes, i.e. you should
see everything there is to be seen when when logged in with maximum permissions,
such as as 'coord'/'coord', or even 'devel'/'devel', as I suggested earlier.

> I'm unclear about the version field. I think Martin said that should be
> only past versions, indicating the version in which the person found the
> bug. For an rfe it isn't going to make sense, so again it needs a not-set.

I agree. But since it isn't clear what type the user will choose, we have
to display the versions field, too (as long as we don't play tricks with
javascript). So this kind of validation can only be applied in an auditor.

> I think there was consensus that we don't need 'platform' (?). I hope
> not; it would be a maintenance nightmare.

Was there ? I haven't heard any comment about that. Here again, I expect
users may just leave that untouched, meaning "I don't know". And in fact,
for a large chunk of issues the platform may not actually matter. But for
some it will, and so it is good to be able to express it.

Thanks for your comments !

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov 30 19:52:20 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 10:52:20 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F2289.1050305@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2289.1050305@sympatico.ca>
Message-ID: <f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>

It isn't reasonable to expect users to use the web page; in fact it is
roundup's big advantage that they do not. Perhaps your working situation is
different, but for us this fact was the one single thing that made Roundup
work where other bug trackers had failed.

On 11/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
> > When one thinks about roundup users you need to remember that web
> > interface use will be small compared to email. This remark applies to
> > items in the schema, such as component or version or platform -- the
> > email user will not be setting these. They need 'not set' defaults so
> > that a developer doing triage can set them later.
>
> I agree, all these need to have reasonably defaults.
> However, I'm not so sure about the importance of email as far as
> issue *creation* is concerned. I think it is reasonable to expect
> users typically to use the web interface to create issues, and then
> let any followup happen mostly by mail.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/6aaf298f/attachment.html 

From martin at v.loewis.de  Thu Nov 30 20:10:54 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 20:10:54 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
Message-ID: <456F2CBE.9060503@v.loewis.de>

Paul Dubois schrieb:
> When one thinks about roundup users you need to remember that web
> interface use will be small compared to email.

I somewhat doubt that prediction. For initial submission, I think
the majority of new issues will come through the website (especially
if we tell users that this is the preferred channel).

Regards,
Martin

From seefeld at sympatico.ca  Thu Nov 30 20:25:48 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 14:25:48 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <4569515A.9010705@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de>
Message-ID: <456F303C.1090809@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> How would you tag patches (attachments, generally) to decide / indicate
>> whether it actually contains a patch and not some other content, and whether
>> it really fixes the bug ? Doesn't this involve at least some developer
>> interaction anyway, at which point we could simply set a 'contains fix'
>> flag that would be part of the bug type, or absorb into the status
>> enumeration as 'fix_provided_but_needs_testing', as suggested earlier ?
> 
> I have no preference here. Having a "patch" tag might work; classifying
> attachments as patches might also work. Typically, *all* patches in
> "open" submissions still need review: if they are successfully reviewed,
> the patch gets either accepted or rejected; if accepted, it gets
> committed and the issue closed. So I don't see the need to distinguish
> between "has patch" and "has working patch". If the patch is not
> acceptable as-is, the submitter may be asked to rework it. I had
> no need to filter for that status: if I open the issue, I can easily
> see that it is still in the feedback phase (and reject the patch
> if the submitter is unresponsive).

Martin,

sorry I dropped the ball here. I'm not sure I completely understand, so let
me suggest two concrete procedures. May be that will help us move forward:

1) additional status enumeration

new -> open -> needs_review -> needs_feedback -> closed

* An assignee opens the issue, finds it has a patch attached, and puts the issue
  into the 'needs_review' state.

* After a successfull review, the patch gets applied, and the issue is closed.

* Alternatively, the patch is rejected, so the issue goes into either
  'needs_feedback' if the submitter is asked to rework the patch, or into
  'closed' (with resolution set to 'invalid', 'rejected', or some such).

* The 'needs_feedback' would be the pending state we have been talking about,
  with an associated timer to make sure the issue can be closed if the submitter
  is unresponsive.

Of course, the status may also change from 'open' to 'needs_feedback'
or 'closed' directly, if either there is no attachment at all, or it is
reviewed quickly.


2) a boolean 'contains patch' flag

The issue would have a 'contains patch' flag that can either be set by the
submitter, or by an assignee after he verified that an attachment is in fact
a patch. As Paul pointed out, it may be simpler to not expose this flag to
submitters at all, since, if used the mail gateway, the flag would be (almost)
unaccessible anyway.
This version doesn't cover the handling of the 'needs feedback' status yet.


In terms of schema / workflow complexity, the two are roughly equivalent,
though the first is a bit more expressive. (In the second scenario, can the
'contains patch' flag be unset ? How does the assignee mark that the patch needs
to be reworked ? Etc.)

I leave it up to you (or any other python-dev folks) to choose, or propose
other alternatives.


Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Thu Nov 30 20:40:49 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 11:40:49 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F303C.1090809@sympatico.ca>
References: <455891F0.2050209@sympatico.ca> <45631769.6020200@sympatico.ca>
	<45634D90.8060806@v.loewis.de> <45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se> <4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
Message-ID: <bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>

On 11/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Martin v. L?wis wrote:
> > Stefan Seefeld schrieb:
> >> How would you tag patches (attachments, generally) to decide / indicate
> >> whether it actually contains a patch and not some other content, and
> whether
> >> it really fixes the bug ? Doesn't this involve at least some developer
> >> interaction anyway, at which point we could simply set a 'contains fix'
> >> flag that would be part of the bug type, or absorb into the status
> >> enumeration as 'fix_provided_but_needs_testing', as suggested earlier ?
> >
> > I have no preference here. Having a "patch" tag might work; classifying
> > attachments as patches might also work. Typically, *all* patches in
> > "open" submissions still need review: if they are successfully reviewed,
> > the patch gets either accepted or rejected; if accepted, it gets
> > committed and the issue closed. So I don't see the need to distinguish
> > between "has patch" and "has working patch". If the patch is not
> > acceptable as-is, the submitter may be asked to rework it. I had
> > no need to filter for that status: if I open the issue, I can easily
> > see that it is still in the feedback phase (and reject the patch
> > if the submitter is unresponsive).
>
> Martin,
>
> sorry I dropped the ball here. I'm not sure I completely understand, so
> let
> me suggest two concrete procedures. May be that will help us move forward:
>
> 1) additional status enumeration
>
> new -> open -> needs_review -> needs_feedback -> closed
>
> * An assignee opens the issue, finds it has a patch attached, and puts the
> issue
>   into the 'needs_review' state.
>
> * After a successfull review, the patch gets applied, and the issue is
> closed.
>
> * Alternatively, the patch is rejected, so the issue goes into either
>   'needs_feedback' if the submitter is asked to rework the patch, or into
>   'closed' (with resolution set to 'invalid', 'rejected', or some such).
>
> * The 'needs_feedback' would be the pending state we have been talking
> about,
>   with an associated timer to make sure the issue can be closed if the
> submitter
>   is unresponsive.
>
> Of course, the status may also change from 'open' to 'needs_feedback'
> or 'closed' directly, if either there is no attachment at all, or it is
> reviewed quickly.


The only issue I have with this is that needs_review is rather generic.
Does a bug need reviewing to verify it is really a bug?  review_path might
work better.

2) a boolean 'contains patch' flag
>
> The issue would have a 'contains patch' flag that can either be set by the
> submitter, or by an assignee after he verified that an attachment is in
> fact
> a patch. As Paul pointed out, it may be simpler to not expose this flag to
> submitters at all, since, if used the mail gateway, the flag would be
> (almost)
> unaccessible anyway.
> This version doesn't cover the handling of the 'needs feedback' status
> yet.


I really don't think the email worry will be an issue.  Creating issues by
email probably will not happen that often (do we even want to allow it
because of possible spam issues?).  And if we do go with a flag, it should
be controllable by the submitter since it is not that critical of a thing
for us to control.

In terms of schema / workflow complexity, the two are roughly equivalent,
> though the first is a bit more expressive. (In the second scenario, can
> the
> 'contains patch' flag be unset ? How does the assignee mark that the patch
> needs
> to be reworked ? Etc.)


At the moment comments carry the brunt of the burden to signal that a patch
needs work.  It's worked out, but then again if we have another status
specifying that a patch needs review then perhaps we can eventually use that
to send out reminder emails to tend to it and then auto-close eventually.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/eae3e110/attachment.htm 

From pfdubois at gmail.com  Thu Nov 30 20:42:07 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 11:42:07 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F2CBE.9060503@v.loewis.de>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2CBE.9060503@v.loewis.de>
Message-ID: <f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>

I'm sorry that my experience with reality does not agree with your
intellectual model of how people behave.  (:->

I have actually done the experiment.
    Buzilla, no email, just a website -> not used
    Roundup, email, and a website -> kaboom! explosive growth of bug reports
and team communications.

Same people, same amount of management emphasis, etc.

I have no reason to feel we ought to tell users that the website is
preferred. You've picked a tool that sets people free, so do not suggest
they wear handcuffs. Let me say it again: the email interface / nosy lists
are what makes Roundup superior.

On 11/30/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>
> Paul Dubois schrieb:
> > When one thinks about roundup users you need to remember that web
> > interface use will be small compared to email.
>
> I somewhat doubt that prediction. For initial submission, I think
> the majority of new issues will come through the website (especially
> if we tell users that this is the preferred channel).
>
> Regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/657f30bc/attachment.html 

From pfdubois at gmail.com  Thu Nov 30 20:48:23 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 11:48:23 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <4568C59F.90809@v.loewis.de>
	<4568C887.6060706@sympatico.ca> <4569515A.9010705@v.loewis.de>
	<456F303C.1090809@sympatico.ca>
	<bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>
Message-ID: <f74a6c2f0611301148j725bffcfj4d9c4e1788cf82f3@mail.gmail.com>

On 11/30/06, Brett Cannon <brett at python.org> wrote:

>
>
> I really don't think the email worry will be an issue.  Creating issues by
> email probably will not happen that often (do we even want to allow it
> because of possible spam issues?).
>

Red herring. You don't allow *anonymous* email submissions. It has to come
from the email account of a registered user, and they had to register on the
web site.

And again, my experience is at odds with your speculation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/685f11a3/attachment.htm 

From seefeld at sympatico.ca  Thu Nov 30 21:06:10 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 15:06:10 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca> <45631769.6020200@sympatico.ca>	
	<45634D90.8060806@v.loewis.de> <45635D6A.4060509@sympatico.ca>	
	<87slg7mcn9.fsf@uterus.efod.se> <4568BE3D.40206@sympatico.ca>	
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>	
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
	<bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>
Message-ID: <456F39B2.8060809@sympatico.ca>

Brett Cannon wrote:

> The only issue I have with this is that needs_review is rather generic. 
> Does a bug need reviewing to verify it is really a bug?  review_path
> might work better.

Fair enough. 'review_patch' sounds good.


> I really don't think the email worry will be an issue.  Creating issues
> by email probably will not happen that often (do we even want to allow
> it because of possible spam issues?).  And if we do go with a flag, it
> should be controllable by the submitter since it is not that critical of
> a thing for us to control.

Good.

>     In terms of schema / workflow complexity, the two are roughly
>     equivalent,
>     though the first is a bit more expressive. (In the second scenario,
>     can the
>     'contains patch' flag be unset ? How does the assignee mark that the
>     patch needs
>     to be reworked ? Etc.)
> 
> 
> At the moment comments carry the brunt of the burden to signal that a
> patch needs work.  It's worked out, but then again if we have another
> status specifying that a patch needs review then perhaps we can
> eventually use that to send out reminder emails to tend to it and then
> auto-close eventually.

Thanks for your feedback !

		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Thu Nov 30 21:13:42 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 15:13:42 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
Message-ID: <456F3B76.1020203@sympatico.ca>

Paul Dubois wrote:
> I'm sorry that my experience with reality does not agree with your
> intellectual model of how people behave.  (:->
> 
> I have actually done the experiment.
>     Buzilla, no email, just a website -> not used
>     Roundup, email, and a website -> kaboom! explosive growth of bug
> reports and team communications.
> 
> Same people, same amount of management emphasis, etc.

Well, well, then you should also add 'Roundup, no email, just a website'
as a data point. Or else you may draw false conclusions. ;-)

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov 30 21:24:26 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 12:24:26 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F3B76.1020203@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F3B76.1020203@sympatico.ca>
Message-ID: <f74a6c2f0611301224v4bd906c5see7d3c884663328@mail.gmail.com>

Oh, I did do that experiment. I forgot to say -- I had a Roundup on a
classified system and until I figured out how to satisfy the security
requirements we had no email interface, for a year. Little or no usage.
Added email --> kaboom.

On 11/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
> > I'm sorry that my experience with reality does not agree with your
> > intellectual model of how people behave.  (:->
> >
> > I have actually done the experiment.
> >     Buzilla, no email, just a website -> not used
> >     Roundup, email, and a website -> kaboom! explosive growth of bug
> > reports and team communications.
> >
> > Same people, same amount of management emphasis, etc.
>
> Well, well, then you should also add 'Roundup, no email, just a website'
> as a data point. Or else you may draw false conclusions. ;-)
>
> Regards,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/ca03ecd2/attachment.html 

From martin at v.loewis.de  Thu Nov 30 21:34:56 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 21:34:56 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F303C.1090809@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
Message-ID: <456F4070.2090204@v.loewis.de>

Stefan Seefeld schrieb:
> 1) additional status enumeration
> 
> new -> open -> needs_review -> needs_feedback -> closed

I agree with Brett: needs_review still wouldn't allow me
to search for patch-containing submissions; giving an
explicit "patch needs review" status would be necessary.

I'm slightly uncomfortable about that approach since it
codifies a process which isn't codified so far. The
discomfort is only about the codification - I can see
that the implied process could actually work.

Regards,
Martin

From martin at v.loewis.de  Thu Nov 30 21:38:19 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 21:38:19 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
Message-ID: <456F413B.30102@v.loewis.de>

Paul Dubois schrieb:
> I'm sorry that my experience with reality does not agree with your
> intellectual model of how people behave.  (:->
> 
> I have actually done the experiment.
>     Buzilla, no email, just a website -> not used
>     Roundup, email, and a website -> kaboom! explosive growth of bug
> reports and team communications.

Everybody certainly has his own experience; I found that people
do use the SF web-only tracker massively. I feel that we couldn't
stand more submissions; we can't catch up with what we get now.
So the idea that people will report more bugs if they can do so
by email is really scary.

Regards,
Martin

From seefeld at sympatico.ca  Thu Nov 30 22:14:32 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 16:14:32 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2289.1050305@sympatico.ca>
	<f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>
Message-ID: <456F49B8.5050805@sympatico.ca>

Paul Dubois wrote:
> It isn't reasonable to expect users to use the web page; in fact it is
> roundup's big advantage that they do not. Perhaps your working situation
> is different, but for us this fact was the one single thing that made
> Roundup work where other bug trackers had failed.

Yes, yes, I think we all agree that the mail gateway is a Good Thing.

I'm not sure, though, what we are arguing about now, given that we
seem to agree *not* to use a 'has_patch' flag, but instead use the
status to control the work-flow, i.e. let assignees look at an attachment
in order to triage the issue.

Am I missing something ?

-- 

      ...ich hab' noch einen Koffer in Berlin...

From brett at python.org  Thu Nov 30 22:34:01 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 13:34:01 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <f74a6c2f0611301148j725bffcfj4d9c4e1788cf82f3@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca> <45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se> <4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
	<bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>
	<f74a6c2f0611301148j725bffcfj4d9c4e1788cf82f3@mail.gmail.com>
Message-ID: <bbaeab100611301334t20adf32cr86b2bcd91fbdf6b5@mail.gmail.com>

On 11/30/06, Paul Dubois <pfdubois at gmail.com> wrote:
>
> On 11/30/06, Brett Cannon <brett at python.org> wrote:
>
> >
> >
> > I really don't think the email worry will be an issue.  Creating issues
> > by email probably will not happen that often (do we even want to allow it
> > because of possible spam issues?).
> >
>
> Red herring. You don't allow *anonymous* email submissions. It has to come
> from the email account of a registered user, and they had to register on the
> web site.
>

That's good to know.

And again, my experience is at odds with your speculation.
>

That's fine; I am fine with being proven wrong.  But with the main reporters
of bugs not being the developers or a core set of users but users varying
from very casual to heavy I just don't expect people to learn the email
interface to report bugs when most people don't report more than a handful a
year.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/92251bb1/attachment.htm 

From brett at python.org  Thu Nov 30 22:38:43 2006
From: brett at python.org (Brett Cannon)
Date: Thu, 30 Nov 2006 13:38:43 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F49B8.5050805@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2289.1050305@sympatico.ca>
	<f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>
	<456F49B8.5050805@sympatico.ca>
Message-ID: <bbaeab100611301338x39edd157m875e6175508cef48@mail.gmail.com>

On 11/30/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>
> Paul Dubois wrote:
> > It isn't reasonable to expect users to use the web page; in fact it is
> > roundup's big advantage that they do not. Perhaps your working situation
> > is different, but for us this fact was the one single thing that made
> > Roundup work where other bug trackers had failed.
>
> Yes, yes, I think we all agree that the mail gateway is a Good Thing.


Yes.

I'm not sure, though, what we are arguing about now, given that we
> seem to agree *not* to use a 'has_patch' flag, but instead use the
> status to control the work-flow, i.e. let assignees look at an attachment
> in order to triage the issue.
>
> Am I missing something ?


I think at this point people are saying that they don't think that the email
gateway will be used  very much for *creating* new issues and thus we should
not bend over backwards to accomodate it for that purpose.  If that turns
out to be a wrong assumption than we can change things.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/de8ada28/attachment.html 

From g.brandl at gmx.net  Thu Nov 30 22:44:00 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 30 Nov 2006 22:44:00 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F413B.30102@v.loewis.de>
References: <456ED11B.10508@sympatico.ca>		<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>		<456F2CBE.9060503@v.loewis.de>	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F413B.30102@v.loewis.de>
Message-ID: <456F50A0.50403@gmx.net>

Martin v. L?wis wrote:
> Paul Dubois schrieb:
>> I'm sorry that my experience with reality does not agree with your
>> intellectual model of how people behave.  (:->
>> 
>> I have actually done the experiment.
>>     Buzilla, no email, just a website -> not used
>>     Roundup, email, and a website -> kaboom! explosive growth of bug
>> reports and team communications.
> 
> Everybody certainly has his own experience; I found that people
> do use the SF web-only tracker massively. I feel that we couldn't
> stand more submissions; we can't catch up with what we get now.
> So the idea that people will report more bugs if they can do so
> by email is really scary.

Another point is that we may have to notify people unfamiliar with
Roundup that they can just click "Reply" to add a comment to the
issue, perhaps with a footer in the email.

Another thing: can attachments be created by sending a mail with
attachments?

Georg

From seefeld at sympatico.ca  Thu Nov 30 22:46:07 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 16:46:07 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <87irgw4x5g.fsf@uterus.efod.se>
References: <456ED11B.10508@sympatico.ca>	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<87irgw4x5g.fsf@uterus.efod.se>
Message-ID: <456F511F.3000707@sympatico.ca>

Erik Forsberg wrote:
> "Paul Dubois" <pfdubois at gmail.com> writes:
> 
>>> When one thinks about roundup users you need to remember that web interface
>>> use will be small compared to email. This remark applies to items in the
>>> schema, such as component or version or platform -- the email user will not
>>> be setting these. They need 'not set' defaults so that a developer doing
>>> triage can set them later.
>>>
>>> The problem with the patch attached business is that many will submit the
>>> patch by email attachment and they won't see any checkbox to check. Yes,
>>> they could do it on the title line as in
> 
> I suggest that we add a "has patch" (or perhaps "has attachement")
> property (boolean) on issue, and set it by detector. That way, it will
> be easy (and efficient) to search for issues that have
> attachements. Still, the users don't need to do anything, as it
> happens automatically. 

What does that flag tell us that we couldn't find with a (named) query ?

How does the detector distinguish between a patch and some other attachment,
such as a stack trace, or other log ?

The point is that someone needs to triage 'manually', at some point.
Either the submitter, when setting that flag, or the assignee, when reviewing
the attachment.


I thought we discussed that already...

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From pfdubois at gmail.com  Thu Nov 30 22:48:05 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 13:48:05 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F50A0.50403@gmx.net>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F413B.30102@v.loewis.de> <456F50A0.50403@gmx.net>
Message-ID: <f74a6c2f0611301348h504784a7gc3b065b56d1eaafe@mail.gmail.com>

>
> Another thing: can attachments be created by sending a mail with
> attachments?
>
> Georg



Yes!  Write a patch and mail it!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/1234385c/attachment.htm 

From nnorwitz at gmail.com  Thu Nov 30 22:49:03 2006
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Thu, 30 Nov 2006 13:49:03 -0800
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F4070.2090204@v.loewis.de>
References: <455891F0.2050209@sympatico.ca> <45634D90.8060806@v.loewis.de>
	<45635D6A.4060509@sympatico.ca> <87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca> <4568C59F.90809@v.loewis.de>
	<4568C887.6060706@sympatico.ca> <4569515A.9010705@v.loewis.de>
	<456F303C.1090809@sympatico.ca> <456F4070.2090204@v.loewis.de>
Message-ID: <ee2a432c0611301349sf00e6dei9c001fc62e1c1b0d@mail.gmail.com>

On 11/30/06, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Stefan Seefeld schrieb:
> > 1) additional status enumeration
> >
> > new -> open -> needs_review -> needs_feedback -> closed
>
> I agree with Brett: needs_review still wouldn't allow me
> to search for patch-containing submissions; giving an
> explicit "patch needs review" status would be necessary.
>
> I'm slightly uncomfortable about that approach since it
> codifies a process which isn't codified so far. The
> discomfort is only about the codification - I can see
> that the implied process could actually work.

But don't we mostly do that already?  At least those of us that review
bugs often (like yourself, Georg and me).  I suspect the people that
care are already on this list.  They will speak up if they disagree.
We can always change the process if it doesn't work out, so I'm ok
with doing this.  If it helps clarify to users (and developers!) the
state of any particular issue and what needs to happen next, that's a
good thing.

n

From g.brandl at gmx.net  Thu Nov 30 22:54:29 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 30 Nov 2006 22:54:29 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F511F.3000707@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	<87irgw4x5g.fsf@uterus.efod.se>
	<456F511F.3000707@sympatico.ca>
Message-ID: <456F5315.6000507@gmx.net>

Stefan Seefeld wrote:
> Erik Forsberg wrote:
>> "Paul Dubois" <pfdubois at gmail.com> writes:
>> 
>>>> When one thinks about roundup users you need to remember that web interface
>>>> use will be small compared to email. This remark applies to items in the
>>>> schema, such as component or version or platform -- the email user will not
>>>> be setting these. They need 'not set' defaults so that a developer doing
>>>> triage can set them later.
>>>>
>>>> The problem with the patch attached business is that many will submit the
>>>> patch by email attachment and they won't see any checkbox to check. Yes,
>>>> they could do it on the title line as in
>> 
>> I suggest that we add a "has patch" (or perhaps "has attachement")
>> property (boolean) on issue, and set it by detector. That way, it will
>> be easy (and efficient) to search for issues that have
>> attachements. Still, the users don't need to do anything, as it
>> happens automatically. 
> 
> What does that flag tell us that we couldn't find with a (named) query ?
> 
> How does the detector distinguish between a patch and some other attachment,
> such as a stack trace, or other log ?

In an ideal world, it could look at the file extension which would have to be
.patch or .diff. Unfortunately, we frequently get patches that end in .txt or
don't have an extension at all.

> The point is that someone needs to triage 'manually', at some point.
> Either the submitter, when setting that flag, or the assignee, when reviewing
> the attachment.

Which is reasonable, IMHO. Someone needs to read and probably reclassify the
bug/patch anyway.

Georg

From g.brandl at gmx.net  Thu Nov 30 22:57:02 2006
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 30 Nov 2006 22:57:02 +0100
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456ED11B.10508@sympatico.ca>
References: <456ED11B.10508@sympatico.ca>
Message-ID: <456F53AE.3020004@gmx.net>

Stefan Seefeld wrote:
> This is a little reminder to recall that we hope to settle on the new
> python tracker schema by comming monday the 4th.
> 
> Please review and comment on the available fields at
> 
> http://psf.upfronthosting.co.za/roundup/tracker/

I have a different problem: there seems to be something wrong with i18n
(I have a German setup here), e.g. trying to access this URL

http://psf.upfronthosting.co.za/roundup/tracker/issue?@template=item

will result in this traceback:


Traceback (most recent call last):
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/client.py", 
line 732, in renderContext
     result = pt.render(self, None, None, **args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/templating.py", 
line 323, in render
     getEngine().getContext(c), output, tal=1, strictinsert=0)()
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 192, in __call__
     self.interpret(self.program)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 236, in interpret
     handlers[opcode](self, args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 666, in do_useMacro
     self.interpret(macro)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 236, in interpret
     handlers[opcode](self, args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 411, in do_optTag_tal
     self.do_optTag(stuff)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 396, in do_optTag
     return self.no_tag(start, program)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 391, in no_tag
     self.interpret(program)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 236, in interpret
     handlers[opcode](self, args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 689, in do_defineSlot
     self.interpret(slot)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 236, in interpret
     handlers[opcode](self, args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 632, in do_condition
     self.interpret(block)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 236, in interpret
     handlers[opcode](self, args)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 555, in do_insertTranslation
     xlated_msgid = self.translate(msgid, default, i18ndict, obj)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TAL/TALInterpreter.py", 
line 618, in translate
     msgid, i18ndict, default=default)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TranslationService.py", 
line 77, in translate
     target_language=target_language)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TranslationService.py", 
line 32, in translate
     _msg = self.gettext(msgid)
   File 
"/home/roundup/roundup-1.3.0/lib/python2.4/site-packages/roundup/cgi/TranslationService.py", 
line 38, in gettext
     return self.ugettext(msgid).encode(self.OUTPUT_ENCODING)
   File "gettext.py", line 391, in ugettext
     return unicode(message)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 397: 
ordinal not in range(128)

From pfdubois at gmail.com  Thu Nov 30 22:57:43 2006
From: pfdubois at gmail.com (Paul Dubois)
Date: Thu, 30 Nov 2006 13:57:43 -0800
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <bbaeab100611301338x39edd157m875e6175508cef48@mail.gmail.com>
References: <456ED11B.10508@sympatico.ca>
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>
	<456F2289.1050305@sympatico.ca>
	<f74a6c2f0611301052y2e1a4ffdp6e4d1f5396ddb049@mail.gmail.com>
	<456F49B8.5050805@sympatico.ca>
	<bbaeab100611301338x39edd157m875e6175508cef48@mail.gmail.com>
Message-ID: <f74a6c2f0611301357w64bd8c49k53f9393fe3cbcf08@mail.gmail.com>

Yes, Stefan, the discussion about submitting issues by email, is now
orthogonal to your patch idea. I like the solution you came up with.

Brett, the 'people' who are saying that the email gateway won't be used very
much seems to consist so far of two people, one of whom at least has no
experience with Roundup. Although this point is moot for this particular
issue (patch flag), it is relevant to the schema design in general. We have
to be prepared for an email submitter, who is in some degree similar to a
lazy web submitter, who isn't going to touch anything they don't have to
touch.

My sysadmins have three ways to tell them you need services, in this order
of preference.
    a. Use their website
    b. Email them
    c. Phone them or catch them in the hall
Guess what order really happens. (:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/bc4a4346/attachment.html 

From seefeld at sympatico.ca  Thu Nov 30 23:26:37 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 17:26:37 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <bbaeab100611301334t20adf32cr86b2bcd91fbdf6b5@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca>
	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>
	<4568BE3D.40206@sympatico.ca>	<4568C59F.90809@v.loewis.de>
	<4568C887.6060706@sympatico.ca>	<4569515A.9010705@v.loewis.de>
	<456F303C.1090809@sympatico.ca>	<bbaeab100611301140k68d12aa7v18f5687e9866df36@mail.gmail.com>	<f74a6c2f0611301148j725bffcfj4d9c4e1788cf82f3@mail.gmail.com>
	<bbaeab100611301334t20adf32cr86b2bcd91fbdf6b5@mail.gmail.com>
Message-ID: <456F5A9D.8050607@sympatico.ca>

Brett Cannon wrote:

>     And again, my experience is at odds with your speculation. 
> 
> 
> That's fine; I am fine with being proven wrong.  But with the main
> reporters of bugs not being the developers or a core set of users but
> users varying from very casual to heavy I just don't expect people to
> learn the email interface to report bugs when most people don't report
> more than a handful a year.

FWIW, any mail sent to the issue tracker mail address that isn't part
of an existing discussion will result in a new issue to be created.
(mails whose subject line starts with [issue25] will be dispatched to
issue 25 etc.)

It's really dead easy. Thus, I fully understand why Paul suggests that
the mail interface will be used a lot.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Thu Nov 30 23:38:23 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 17:38:23 -0500
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F4070.2090204@v.loewis.de>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
	<456F4070.2090204@v.loewis.de>
Message-ID: <456F5D5F.9000605@sympatico.ca>

Martin v. L?wis wrote:
> Stefan Seefeld schrieb:
>> 1) additional status enumeration
>>
>> new -> open -> needs_review -> needs_feedback -> closed
> 
> I agree with Brett: needs_review still wouldn't allow me
> to search for patch-containing submissions; giving an
> explicit "patch needs review" status would be necessary.

OK, then what about

new -> open -> needs_patch_review -> needs_feedback -> closed

?

> I'm slightly uncomfortable about that approach since it
> codifies a process which isn't codified so far. The
> discomfort is only about the codification - I can see
> that the implied process could actually work.

Great ! What if we don't actually constrain any status transitions ?
At least as long as people aren't sure about the work flow.

Would that be better ?

Thanks,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From seefeld at sympatico.ca  Thu Nov 30 23:40:55 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 17:40:55 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F50A0.50403@gmx.net>
References: <456ED11B.10508@sympatico.ca>		<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>		<456F2CBE.9060503@v.loewis.de>	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>	<456F413B.30102@v.loewis.de>
	<456F50A0.50403@gmx.net>
Message-ID: <456F5DF7.5070807@sympatico.ca>

Georg Brandl wrote:

> Another point is that we may have to notify people unfamiliar with
> Roundup that they can just click "Reply" to add a comment to the
> issue, perhaps with a footer in the email.

Right. I think by default mails already contain a footer with some
info (such as an URL to the issue's web interface, etc.)

> Another thing: can attachments be created by sending a mail with
> attachments?

Yes. By default all attachments to a mail end up as attachments
to the issue. (We can use auditors to close any potential security holes,
if needed.)

Easy, isn't it ?

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...

From martin at v.loewis.de  Thu Nov 30 23:46:07 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 23:46:07 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <ee2a432c0611301349sf00e6dei9c001fc62e1c1b0d@mail.gmail.com>
References: <455891F0.2050209@sympatico.ca> <45634D90.8060806@v.loewis.de>	
	<45635D6A.4060509@sympatico.ca>
	<87slg7mcn9.fsf@uterus.efod.se>	 <4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de>	 <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de>	 <456F303C.1090809@sympatico.ca>
	<456F4070.2090204@v.loewis.de>
	<ee2a432c0611301349sf00e6dei9c001fc62e1c1b0d@mail.gmail.com>
Message-ID: <456F5F2F.6020403@v.loewis.de>

Neal Norwitz schrieb:
>> I'm slightly uncomfortable about that approach since it
>> codifies a process which isn't codified so far. The
>> discomfort is only about the codification - I can see
>> that the implied process could actually work.
> 
> But don't we mostly do that already?

That's true. Still, we currently have a flag "is patch"
(by having the issue in the patches tracker), so it would
be a deviation from the status quo not to have that anymore.

I know these fine points are not important for the initial
setup, as they can be changed afterwards. So coding a work-flow
into the tracker is fine with me, I guess.

Regards,
Martin

From martin at v.loewis.de  Thu Nov 30 23:48:56 2006
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 30 Nov 2006 23:48:56 +0100
Subject: [Tracker-discuss] Feature/Change request handling procedure
In-Reply-To: <456F5D5F.9000605@sympatico.ca>
References: <455891F0.2050209@sympatico.ca>	<bbaeab100611131238j4da6b044h2a4de1ab12a7fe02@mail.gmail.com>	<87y7qfoz3r.fsf@uterus.efod.se>	<4558F237.8030407@v.loewis.de>	<87u012pkfm.fsf@uterus.efod.se>	<87d57nq5oa.fsf_-_@uterus.efod.se>	<45631769.6020200@sympatico.ca>	<45634D90.8060806@v.loewis.de>	<45635D6A.4060509@sympatico.ca>	<87slg7mcn9.fsf@uterus.efod.se>	<4568BE3D.40206@sympatico.ca>
	<4568C59F.90809@v.loewis.de> <4568C887.6060706@sympatico.ca>
	<4569515A.9010705@v.loewis.de> <456F303C.1090809@sympatico.ca>
	<456F4070.2090204@v.loewis.de> <456F5D5F.9000605@sympatico.ca>
Message-ID: <456F5FD8.7020103@v.loewis.de>

Stefan Seefeld schrieb:
> OK, then what about
> 
> new -> open -> needs_patch_review -> needs_feedback -> closed

That should work. For bugs, something similar should exist:
how about "confirmed"?

> Great ! What if we don't actually constrain any status transitions ?
> At least as long as people aren't sure about the work flow.
> 
> Would that be better ?

Certainly: there shouldn't be any constraints for "developer" people.
For submitters, there will be constraints, although I'm uncertain what
they should be (e.g. submitters should certainly be allowed to withdraw
their submissions).

Regards,
Martin

From seefeld at sympatico.ca  Thu Nov 30 23:55:42 2006
From: seefeld at sympatico.ca (Stefan Seefeld)
Date: Thu, 30 Nov 2006 17:55:42 -0500
Subject: [Tracker-discuss] Reminder: please review tracker schema !
In-Reply-To: <456F413B.30102@v.loewis.de>
References: <456ED11B.10508@sympatico.ca>	
	<f74a6c2f0611301004l272020a1yd90a36b8928f29f6@mail.gmail.com>	
	<456F2CBE.9060503@v.loewis.de>
	<f74a6c2f0611301142m788c3639l6312dd9a99167e14@mail.gmail.com>
	<456F413B.30102@v.loewis.de>
Message-ID: <456F616E.5070103@sympatico.ca>

Martin v. L?wis wrote:

> Everybody certainly has his own experience; I found that people
> do use the SF web-only tracker massively. I feel that we couldn't
> stand more submissions; we can't catch up with what we get now.
> So the idea that people will report more bugs if they can do so
> by email is really scary.

As long as they report real bugs that shouldn't make a difference.
What I find dangerous is that writing mail is so tempting that
people may forget to do their homework and research (via the
web interface) whether the bug they are about to report isn't
already reported.
This could result in a lot of spurious bug reports, which someone
has to review just to mark them as duplicate.

Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...