[Tracker-discuss] Feature/Change request handling procedure

[Erik Forsberg]

-----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-----