OFBiz developers, Jira issue tracker and releases

[Jacopo Cappellato]

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

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> 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

[Jacopo Cappellato]

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

[davidnwelton]

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

[Jacopo Cappellato]

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

[davidnwelton]

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

[Jacopo Cappellato]

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

[David E Jones-2]

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

[davidnwelton]

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

[Jacopo Cappellato]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> 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.
> ========================================
>

[David E Jones-2]

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