Just adding a little caveat here, that, only Resolved jiras can be
bulk updated later on (when a release is approaching), jiras on the
closed as fixed state need to be reopened in order to get edited. If
we are going to use bulk updates, we should make everybody resolve the
jiras, instead of closi
I really don't like making unnecessary 'rules' or policy or trying to
restrict or control who can do something
I think you are probably right, that's why I suggested the alternative rule
of thumb, which is nothing more than common sense really. I think the
important thing is instilling an un
+1 XXX-Next
I don't mind who assigns JIRA to the release number. It can't be done though
until we know that the release number will be (was quite late in the last
cycle). Hopefully we will do more frequent releases from now so there will
be few JIRAs in the XXX-Next box and more with the actual r
Yes +1 to XXX-Next.
I really don't like making unnecessary 'rules' or policy or trying to
restrict or control who can do something. If we can't find a less relaxed
way to do this then I'd prefer to just not include the JIRA list in the
release notes. Couldn't it just be whoever adds the jira list
I think using XXX-Next seems more appropriate now, that we are going out of
milestone releases.
As for the JIRA process, I think that Kevin's original proposal seems good
and would be consistent no matter witch phase of development/release we are,
it also leaves room to the Release Manager to con
I think my proposal is consistent with your desire to get the overview.
When entering the new release phase, all JIRAs fixed in the period since
the last release would be reclassified to the newly created version tag,
along with all JIRAs that the community sees as important for the
forthcoming r
One of the problems with not assigning the specific fix version to JIRA's
till the end is that you can't see whats outstanding from the JIRA overview
page which is something I've found useful and have used it in past releases
to manage what things need to get done. See
http://issues.apache.org/jir
Java SDO has been doing this using an Java-SDO-Mx release rather than
Java-SDO-Next, but as I said on IRC I think the Next naming is much better.
I propose that we adopt the policy that no-one other than a release manager
ever assigns anything other than a *Next value for the fix release of a
JI
OK, I agree. I note that SDO already does this. Any more thoughts about
things we can do to improve the way we can all work in this area? What else
do SDO, DAS do that SCA needs to do? Maybe we can come up with a checklist
for the build and release up on the developer guide section of the web site
I agree with Haleh, we should try to have consistence on areas common to all
Tuscany sub-projects, JIRA, Distributions, Release Process, etc
On 5/21/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
It would be good if all subprojects used whatever scheme it is agreed to
so
a developer going across p
It would be good if all subprojects used whatever scheme it is agreed to so
a developer going across projects does not have to think about adjusting.
On 5/21/07, Simon Laws <[EMAIL PROTECTED]> wrote:
This time round, as so much had changed, we didn't include JIRA numbers in
the release docs. I
This time round, as so much had changed, we didn't include JIRA numbers in
the release docs. It seems like a good thing to do in the future though. If
everyone agrees that this is a good thing we need to be fairly organized
about how we use JIRA otherwise we suffer a lot of pain come release time
12 matches
Mail list logo
