Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-pmc] Marking bugs for official patch

If there are multiple patches on a release, do we name them as 3.0 P1, 3.0 P2..?

 

Once we make a decision on this topic, I suggest we create a wiki to capture this for posterity.

-Raghu


From: Raev, Kaloyan [mailto:kaloyan.raev@xxxxxxx]
Sent: Thursday, June 19, 2008 8:59 AM
To: WTP PMC communications (including coordination, announcements, and Group discussions)
Subject: RE: [wtp-pmc] Marking bugs for official patch

 

OK. It seems that option 1 is more preferable. Therefore, I suggest that we create a new target milestone in Bugzilla, called "3.0 P", where all patch candidate bugs should be targeted. Similarly, Dali and JSF projects should have a new "2.0 P" target milestone. The "P" target milestone should be perceived as an intermediate milestone between the official release and the next maintenance release. That is "3.0 P" is after "3.0", but before "3.0.1". In this order of thoughts any bug fixed at "3.0 P" should be fixed in "3.0.1" as well.

 

I am not sure on how do we use the whiteboard with the "investigate" or "request patch" words. Targeting the bug to "3.0 P" implies the intention to produce an official patch for this bug. If it is later decided that this bug will not be fixed as an official patch, then it should be simply re-targeted to "3.0.1".

 

Nevertheless, we could use the whiteboard to determine the "solution type" of the official patch:

  - "update site" to release the official patch as a "feature patch" on the update site.

  - "rebuild plugin" to rebuild the patched plugin, so the adopter can simply include it in his product.

 

Does the above seem reasonable?

 

Regarding the "milestone cleanup". I doubt it is reasonable hiding certain milestones, if possible at all. While we want need most of them on the bug's page, we should have all of them displayed in the search page. However we could improve the situation by rearranging the sortkey of the milestones. So, the recent ones are on the top. I imagine something like this:

 

3.0 P

3.0.1

Future

--- (default)

3.0 RC4

3.0 RC3

.........

2.0.2 M202

2.0.1 M201

2.0 RC5

..........

2.0

1.5.5 M155

..........

 

The "---" milestone has the sortkey = "0". I think this makes it the default milestone. I have to check if negative sortkeys are possible, to milestones with negative sortkeys can pop above the "---" one.

 

An important note is that sortkeys of already created milestones cannot be changed by the Portal (I will file a bug about this), but only through are request to the webmaster.

 

Greetings,

Kaloyan


Back to the top