You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2006/11/19 11:22:40 UTC
OFBiz developers, Jira issue tracker and releases
I've seen a good progress, during the last few months, in the activity
around the issues in our issue tracker: new contributors/developers have
joined this great project and are helping a lot with bug fixes,
enhancements, proposals; on the other hand, the committers are working
hard to review/update/resolve the new issues coming in (more now than in
the past).
I think that one of the reasons for this positive change is that the
Jira notifications are posted directly to the dev list, so that
conversations happening as comments in a Jira issue are not so different
form the ones posted to the list.
In order to further improve this activity, I'd suggest a few small
changes to the way Jira is administered now:
1) put more people in the "ofbiz-developers" Jira group; the advantages are:
1a) we can officially define the group of (established) OFBiz
developers/contributors (that are the ones that sooner or later could
become committers); I think that the decision to include a new persons
should be taken using the ASF voting procedure
1b) they will be able to assign issues to them, and help update and
clean the old issues
2) create in Jira at least two target releases, one would be the post
graduation release (cooming soon), while the second could be a longer
term release, with no Release Date, that will be released as soon as all
the issues assigned to it will be completed; issues can be assigned to
the longer term release only in one of the following situations:
2a) by community vote ("Vote: set the target for Jira issue #OFBIZ-XYZ
to release X")
2b) the developer that assigns the issue to the release, also assigns
the issue to himself ("ok, I'll work on this issue, and I'll complete it
in a reasonable amount of time, because I want it in the X release");
these issues should be bug fixes or obvious improvements (I mean
something that doesn't need a community vote because the consensus is
implied)
In my opinion, with these simple rules in place we will promote two main
objectives:
A) increase, motivate the developers' group
B) share some community driven goals for releases
What do you think of these ideas?
Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jacopo,
Please don't forget my 3d point :
3) Ask Apache Jira infra if it's possible to allow developpers to put the time spent on a task as we were able on the old Jira.
I used it sometimes and I miss it now (or I could not find it ?)
Thanks
Jacques
> Hi David,
>
> David Welton wrote:
> >
> > The three levels are 'contributors, committers, and PMC members'.
> > Contributors are people who send in patches and help out some. If you
> > guys want to add some people like that to JIRA, but not give them
> > committ access, I think that's fine too.
> >
>
> yes, that was the idea... what do others think of this?
>
> Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by David E Jones <jo...@undersunconsulting.com>.
On Nov 20, 2006, at 3:18 AM, Jacopo Cappellato wrote:
> Hi David,
>
> David Welton wrote:
>> The three levels are 'contributors, committers, and PMC members'.
>> Contributors are people who send in patches and help out some. If
>> you
>> guys want to add some people like that to JIRA, but not give them
>> committ access, I think that's fine too.
>
> yes, that was the idea... what do others think of this?
We have done a bit of this in the past and I think it's a good idea
so that frequent contributors can help maintain issues even if they
can't commit changes. I can think of a couple of situations where
this would be helpful:
1. a stepping stone for future committers
2. a tool that can be used by those who want to help with testing of
OFBiz, and testing and review of contributions (patches, etc), even
if they aren't interested in becoming a committer
-David
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacopo Cappellato <ti...@sastau.it>.
Hi David,
David Welton wrote:
>
> The three levels are 'contributors, committers, and PMC members'.
> Contributors are people who send in patches and help out some. If you
> guys want to add some people like that to JIRA, but not give them
> committ access, I think that's fine too.
>
yes, that was the idea... what do others think of this?
Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by David Welton <da...@gmail.com>.
> Yes, a bit more overhead (I agree that we would not probably need to
> vote to decide that a guy should become a developer) however I think
> that this would nicely represent the three roles of developers,
> committers, PMC members as described here:
>
> http://www.apache.org/foundation/how-it-works.html#roles
The three levels are 'contributors, committers, and PMC members'.
Contributors are people who send in patches and help out some. If you
guys want to add some people like that to JIRA, but not give them
committ access, I think that's fine too.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacopo Cappellato <ti...@sastau.it>.
David Welton wrote:
>
>> Yes, right now in the list there are only the committers (with some
>> exceptions)... do you think that there would be problems in having a
>> list of jira-developers not equals to the list of committers? (I mean
>> both problems related to ASF policies and procedural problems).
>
> It seems like more overhead than it's worth to have three separate but
> mostly overlapping groups of people, but it's up to you guys to manage
> it.
>
Yes, a bit more overhead (I agree that we would not probably need to
vote to decide that a guy should become a developer) however I think
that this would nicely represent the three roles of developers,
committers, PMC members as described here:
http://www.apache.org/foundation/how-it-works.html#roles
Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by David Welton <da...@gmail.com>.
> > Shouldn't it just be the committers, or PMC members?
> Yes, right now in the list there are only the committers (with some
> exceptions)... do you think that there would be problems in having a
> list of jira-developers not equals to the list of committers? (I mean
> both problems related to ASF policies and procedural problems).
It seems like more overhead than it's worth to have three separate but
mostly overlapping groups of people, but it's up to you guys to manage
it.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacopo Cappellato <ti...@sastau.it>.
David Welton wrote:
>> >> 1) put more people in the "ofbiz-developers" Jira group; the
>> advantages are:
>> >
>> > Yes it would be useful. How to define eligible persons, asking
>> persons or waiting that they ask ?
>>
>> I think that both ways are good... for example I already have a list in
>> my mind for persons that will be eligible.
>
> Shouldn't it just be the committers, or PMC members?
>
Yes, right now in the list there are only the committers (with some
exceptions)... do you think that there would be problems in having a
list of jira-developers not equals to the list of committers? (I mean
both problems related to ASF policies and procedural problems).
Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by David Welton <da...@gmail.com>.
> >> 1) put more people in the "ofbiz-developers" Jira group; the advantages are:
> >
> > Yes it would be useful. How to define eligible persons, asking persons or waiting that they ask ?
>
> I think that both ways are good... for example I already have a list in
> my mind for persons that will be eligible.
Shouldn't it just be the committers, or PMC members?
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacopo Cappellato <ti...@sastau.it>.
Jacques Le Roux wrote:
>>
>> 1) put more people in the "ofbiz-developers" Jira group; the advantages are:
>
> Yes it would be useful. How to define eligible persons, asking persons or waiting that they ask ?
I think that both ways are good... for example I already have a list in
my mind for persons that will be eligible.
>
>> 2) create in Jira at least two target releases, one would be the post
>> graduation release (cooming soon), while the second could be a longer
>> term release, with no Release Date, that will be released as soon as all
>> the issues assigned to it will be completed; issues can be assigned to
>> the longer term release only in one of the following situations:
>> 2a) by community vote ("Vote: set the target for Jira issue #OFBIZ-XYZ
>> to release X")
>> 2b) the developer that assigns the issue to the release, also assigns
>> the issue to himself ("ok, I'll work on this issue, and I'll complete it
>> in a reasonable amount of time, because I want it in the X release");
>> these issues should be bug fixes or obvious improvements (I mean
>> something that doesn't need a community vote because the consensus is
>> implied)
>
> Yes, I'm not sure it's the better way to manage releases (or it's enough I mean) but surely it should help.
I agree with you that this is not enough... but it could be a starting
point.
Jacopo
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ti...@sastau.it>
> I've seen a good progress, during the last few months, in the activity
> around the issues in our issue tracker: new contributors/developers have
> joined this great project and are helping a lot with bug fixes,
> enhancements, proposals; on the other hand, the committers are working
> hard to review/update/resolve the new issues coming in (more now than in
> the past).
> I think that one of the reasons for this positive change is that the
> Jira notifications are posted directly to the dev list, so that
> conversations happening as comments in a Jira issue are not so different
> form the ones posted to the list.
>
> In order to further improve this activity, I'd suggest a few small
> changes to the way Jira is administered now:
>
> 1) put more people in the "ofbiz-developers" Jira group; the advantages are:
> 1a) we can officially define the group of (established) OFBiz
> developers/contributors (that are the ones that sooner or later could
> become committers); I think that the decision to include a new persons
> should be taken using the ASF voting procedure
> 1b) they will be able to assign issues to them, and help update and
> clean the old issues
Yes it would be useful. How to define eligible persons, asking persons or waiting that they ask ?
> 2) create in Jira at least two target releases, one would be the post
> graduation release (cooming soon), while the second could be a longer
> term release, with no Release Date, that will be released as soon as all
> the issues assigned to it will be completed; issues can be assigned to
> the longer term release only in one of the following situations:
> 2a) by community vote ("Vote: set the target for Jira issue #OFBIZ-XYZ
> to release X")
> 2b) the developer that assigns the issue to the release, also assigns
> the issue to himself ("ok, I'll work on this issue, and I'll complete it
> in a reasonable amount of time, because I want it in the X release");
> these issues should be bug fixes or obvious improvements (I mean
> something that doesn't need a community vote because the consensus is
> implied)
Yes, I'm not sure it's the better way to manage releases (or it's enough I mean) but surely it should help.
>
> In my opinion, with these simple rules in place we will promote two main
> objectives:
>
> A) increase, motivate the developers' group
> B) share some community driven goals for releases
>
> What do you think of these ideas?
>
> Jacopo
I would had a 3d point :
3) Ask Apache Jira infra if it's possible to allow developpers to put the time spent on a task as we were able on the old Jira.
I used it sometimes and I miss it now (or I could not find it ?)
Jacques
Re: OFBiz developers, Jira issue tracker and releases
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <jo...@undersunconsulting.com>
> In general I'm not sure about assigning issues to future releases. We
> tried this on the old Jira server and it failed miserably, and made
> things a bit confusing. In the new Jira server we started with no
> version numbers in order to push everything into the "SVN" version,
> which should probably be called "trunk" instead.
IMHO "trunk" shall not be sufficient (we call it mostly svn because of OpenTaps). I propose "Apache trunk"
> One way or another we should establish some policies or patterns for
> this. Assigning a version number to an issue initially or after
> resolution can mean a number of things otherwise. My vote would be
> that only past release numbers go into Jira, and when attached to an
> issue that it means the problem exists in that issue, and when
> associated with a fix that it means the fix went into that branch.
"and when attached to an issue that it means the problem exists in that ISSUE" (here ISSUE is not release ?)
+1
> We could probably do this along with issues planned for future
> releases, and hopefully it wouldn't be too confusing. Even if it
> weren't too confusing is it really realistic to expect with the way
> things are generally done in the OFBiz community that this would
> result in plans for future releases that would be actionable and
> "actioned"?
Not sure to have well understood this last chapter, we will see anyway...
Jacques
> -David
>
>
> ========================================
> Real releases, like the one we plan to do shortly after graduation
> from incubation, will have a branch and such. Whether we will do a
> branch at the release candidate phase, or even do a release candidate
> phase for real releases, is yet to be decided. The nature of OFBiz is
> quite a bit different from many open source projects and for reasons
> that have been discussed in probably thousands of messages over the
> years doing a "feature freeze" or anything like that in order to move
> to a "stable" release seems now to be more than the OFBiz community
> has resources to do properly.
>
> Because of that the plan is to have community driven releases. In
> other words, we do announce a release intention and ask people to
> test things and if there aren't any major show-stoppers, we do a
> branch and a release based on that branch. Once we do a branch like
> this a sub-community develops that can collaborate on making that
> branch a good stable artifact set over time as bug fixes only are
> back-ported and issues specific to that branch are fixed over time.
> ========================================
>
Re: OFBiz developers, Jira issue tracker and releases
Posted by David E Jones <jo...@undersunconsulting.com>.
On Nov 19, 2006, at 3:22 AM, Jacopo Cappellato wrote:
> 2) create in Jira at least two target releases, one would be the
> post graduation release (cooming soon), while the second could be a
> longer term release, with no Release Date, that will be released as
> soon as all the issues assigned to it will be completed; issues can
> be assigned to the longer term release only in one of the following
> situations:
> 2a) by community vote ("Vote: set the target for Jira issue #OFBIZ-
> XYZ to release X")
> 2b) the developer that assigns the issue to the release, also
> assigns the issue to himself ("ok, I'll work on this issue, and
> I'll complete it in a reasonable amount of time, because I want it
> in the X release"); these issues should be bug fixes or obvious
> improvements (I mean something that doesn't need a community vote
> because the consensus is implied)
While discussing the test snapshot releases and some of the
possibilities for real releases I wrote a bit about what I hope will
be a more successful way to do a release. I'll copy that below.
If we go with this approach of getting to a point with no show-
stoppers then doing a branched release that is improved and supported
over time then a version takes on a different meaning in Jira. It
would be mostly for bugs and would mean that the bug exists in the
specified release.
In general I'm not sure about assigning issues to future releases. We
tried this on the old Jira server and it failed miserably, and made
things a bit confusing. In the new Jira server we started with no
version numbers in order to push everything into the "SVN" version,
which should probably be called "trunk" instead.
One way or another we should establish some policies or patterns for
this. Assigning a version number to an issue initially or after
resolution can mean a number of things otherwise. My vote would be
that only past release numbers go into Jira, and when attached to an
issue that it means the problem exists in that issue, and when
associated with a fix that it means the fix went into that branch.
We could probably do this along with issues planned for future
releases, and hopefully it wouldn't be too confusing. Even if it
weren't too confusing is it really realistic to expect with the way
things are generally done in the OFBiz community that this would
result in plans for future releases that would be actionable and
"actioned"?
-David
========================================
Real releases, like the one we plan to do shortly after graduation
from incubation, will have a branch and such. Whether we will do a
branch at the release candidate phase, or even do a release candidate
phase for real releases, is yet to be decided. The nature of OFBiz is
quite a bit different from many open source projects and for reasons
that have been discussed in probably thousands of messages over the
years doing a "feature freeze" or anything like that in order to move
to a "stable" release seems now to be more than the OFBiz community
has resources to do properly.
Because of that the plan is to have community driven releases. In
other words, we do announce a release intention and ask people to
test things and if there aren't any major show-stoppers, we do a
branch and a release based on that branch. Once we do a branch like
this a sub-community develops that can collaborate on making that
branch a good stable artifact set over time as bug fixes only are
back-ported and issues specific to that branch are fixed over time.
========================================