| RE: [wtp-pmc] Marking bugs for official patch |
|
Milestone 3.0 P should cover all patches released after the
official release 3.0. I don't think we need 3.0 P1, 3.0 P2,
...
If we need patches for 3.0.1 then we will have target
milestone 3.0.1 P for them.
From: wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of raghunathan.srinivasan@xxxxxxxxxx Sent: Thursday, June 19, 2008 8:12 PM To: WTP PMC communications (including coordination, announcements, and Groupdiscussions) Subject: 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] 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 |