Patch policy

Patch policy

[Gary Thomas]

** Disclaimer: I'm sure that I'm as guilty as anyone

There seems to be a gap [i.e. failing] in the response to
patches from outsiders.  Sometimes they are handled quite
quickly, sometimes never.  I think we need to establish
some policies on how to handle these efficiently.

In an ideal world, patches from outside our group would
be posted to a database which could be queried by anyone.
Maybe the easiest way to do this would be to forward the
patch to BugZilla.

At the very least, we should try and assign a patch to
a maintainer within some short period of time and then it's
that person's responsibility to take care of it - whatever
the outcome.  As is, I see things come in that I'm comfortable
with that sometimes I take up, sometimes I leave by.  In the
latter case, I simply assume that someone else will handle
it.  I think this is the failing.

I know everyone is busy (or hopefully so!) and this is certainly
not a finger-pointing, but our credibility may be affected.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: Patch policy

[Mark Salter]

> ** Disclaimer: I'm sure that I'm as guilty as anyone
> There seems to be a gap [i.e. failing] in the response to
> patches from outsiders.  Sometimes they are handled quite
> quickly, sometimes never.  I think we need to establish
> some policies on how to handle these efficiently.

> In an ideal world, patches from outside our group would
> be posted to a database which could be queried by anyone.
> Maybe the easiest way to do this would be to forward the
> patch to BugZilla.

> At the very least, we should try and assign a patch to
> a maintainer within some short period of time and then it's
> that person's responsibility to take care of it - whatever
> the outcome.  As is, I see things come in that I'm comfortable
> with that sometimes I take up, sometimes I leave by.  In the
> latter case, I simply assume that someone else will handle
> it.  I think this is the failing.

I've been thinking about this as well. I'm not sure what the
best policy approach is. Anyway, I'm going to take time out to
do some testing with Pierre's patches today. I'll get them
checked in or pushed back in the next day or two.

--Mark

Re: Patch policy

[Andrew Lunn]

> In an ideal world, patches from outside our group would
> be posted to a database which could be queried by anyone.
> Maybe the easiest way to do this would be to forward the
> patch to BugZilla.

Sounds like a reasonable idea. Let bugzilla pick the default owner of
the patch depending on the component. We would probably want to add
more HAL components, one per architecture. 

The messy thing is getting the patch from ecos-patches into
bugzilla. I don't see it being done automagically. Do we have to
retrain all contributers to use bugzilla instead of the list? Does one
of us have to import the patch?

   Andrew

Re: Patch policy

[Gary Thomas]

On Tue, 2003-05-06 at 07:25, Andrew Lunn wrote:
> > In an ideal world, patches from outside our group would
> > be posted to a database which could be queried by anyone.
> > Maybe the easiest way to do this would be to forward the
> > patch to BugZilla.
> 
> Sounds like a reasonable idea. Let bugzilla pick the default owner of
> the patch depending on the component. We would probably want to add
> more HAL components, one per architecture. 
> 
> The messy thing is getting the patch from ecos-patches into
> bugzilla. I don't see it being done automagically. Do we have to
> retrain all contributers to use bugzilla instead of the list? Does one
> of us have to import the patch?
> 

This is policy that we would have to develop (decide on).
One way would be to only accept patches via BugZilla.  Then the
onus would be on the submitter.  To make this policy work, maybe
we'd want to have the default owner of the "bug" be the patches
list, or at least send a copy there.

Anyway, it's just an idea that I think we can mull over a bit.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: Patch policy

[Andrew Lunn]

> This is policy that we would have to develop (decide on).
> One way would be to only accept patches via BugZilla.  Then the
> onus would be on the submitter.  To make this policy work, maybe
> we'd want to have the default owner of the "bug" be the patches
> list, or at least send a copy there.

I think part of the problem is that there is no clear owner of a
patch. So i would not set the default owner to "bug", but rather the
owner of the component, so we have a real name we can point a finger
at. The assignment can be changed manually if its not appropriate.

    Andrew

Re: Patch policy

[Gary Thomas]

On Tue, 2003-05-06 at 07:40, Andrew Lunn wrote:
> > This is policy that we would have to develop (decide on).
> > One way would be to only accept patches via BugZilla.  Then the
> > onus would be on the submitter.  To make this policy work, maybe
> > we'd want to have the default owner of the "bug" be the patches
> > list, or at least send a copy there.
> 
> I think part of the problem is that there is no clear owner of a
> patch. So i would not set the default owner to "bug", but rather the
> owner of the component, so we have a real name we can point a finger
> at. The assignment can be changed manually if its not appropriate.
> 

This sound reasonable.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: Patch policy

[Jonathan Larmour]

Andrew Lunn wrote:
>>This is policy that we would have to develop (decide on).
>>One way would be to only accept patches via BugZilla.  Then the
>>onus would be on the submitter.  To make this policy work, maybe
>>we'd want to have the default owner of the "bug" be the patches
>>list, or at least send a copy there.
> 
> 
> I think part of the problem is that there is no clear owner of a
> patch. So i would not set the default owner to "bug", but rather the
> owner of the component, so we have a real name we can point a finger
> at. The assignment can be changed manually if its not appropriate.

One important thing we're missing though is a sort-of "checklist" for 
patches. We (I) have been lax in the past sometimes, and then the problem 
multiplies when someone uses a laxly written port as a basis for _their_ 
port. Part of that would be coding standards - not so much indent level 
and such like as just making sure comments in files refer to the current 
filename not an old one, author is correct, doesn't mention the 
architecture/platform it was derived from etc. But we have to solve our 
own inconsistencies there too!

A (script-driven) overhaul of our standard preamble would help a lot too - 
authors vs. contributors is somewhat ambiguous. I would prefer 
"maintainer" and contributors, where the former is the person responsible 
for the file (not necessarily one of us, i.e. not necessarily a maintainer 
maintainer :-)) and the latter is _anyone_ who's touched the file (if they 
want). But this is just one of the low priority things to do that there's 
never enough impetus to do.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Jonathan Larmour]

Andrew Lunn wrote:
>>In an ideal world, patches from outside our group would
>>be posted to a database which could be queried by anyone.
>>Maybe the easiest way to do this would be to forward the
>>patch to BugZilla.
> 
> 
> Sounds like a reasonable idea. Let bugzilla pick the default owner of
> the patch depending on the component. We would probably want to add
> more HAL components, one per architecture. 
> 
> The messy thing is getting the patch from ecos-patches into
> bugzilla. I don't see it being done automagically. Do we have to
> retrain all contributers to use bugzilla instead of the list? Does one
> of us have to import the patch?

I'd suggest not using bugzilla actually. I've already been thinking about 
this problem and there are well established patch managers out there. In 
particular I'm thinking of what is on savannah.gnu.org, e.g.: 
http://savannah.gnu.org/patch/?group=inetutils

I think is is a brilliant, and obviously being purpose-built, ideally 
suited solution. My hope is that we can move straight to using this if we 
become a GNU project.

But I didn't bother suggesting it yet :-).

If we don't become a GNU project, we could see about bringing it onto 
sources.redhat.com ( or ecos.sourceware.org if you like :-)).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Jonathan Larmour]

Jonathan Larmour wrote:
> 
> I'd suggest not using bugzilla actually. I've already been thinking 
> about this problem and there are well established patch managers out 
> there. In particular I'm thinking of what is on savannah.gnu.org, e.g.: 
> http://savannah.gnu.org/patch/?group=inetutils

I was talking to Alex, and he has persuaded me now that bugzilla is a good 
solution after all! The problems I had with it were primarily due to there 
not being a good mapping between bug states and patch states.

But it turns out that the Bugzilla folks have now thought of that. The 
primary way to sort this out is using flags, like:

http://bugzilla.mozilla.org/flag-help.html

With flags, the mozilla folks sensibly use bugzilla for patch review.

Alex also pointed out that with Bugzilla, it means that all patches are in 
one place - both patches that we say close bugs, and new patches. This 
means people looking for patches only need to search one place.

The only thing is that we can't just add flags to bugzilla.redhat.com... 
so I suggest we go ahead and make a decision about moving to 
http://bugs.ecos.sourceware.org/

Does it look okay by everyone? If so, we can shut down the old bugzilla, 
move all the existing bugs over, and update the web pages to point to 
bugs.ecos.sourceware.org.

Then once we're running with that and happy that it works, we can start 
looking at what's needed to get patches in there, primarily involving 
documenting patch submission procedure.

One thing I'd still want cleared up is how we keep track of what's 
actually being checked in, i.e. when a patch would transition between 
"approved" and "committed" states. I don't know if Alex has any ideas on that.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Gary Thomas]

On Wed, 2003-05-07 at 14:30, Jonathan Larmour wrote:
> Jonathan Larmour wrote:
> > 
> > I'd suggest not using bugzilla actually. I've already been thinking 
> > about this problem and there are well established patch managers out 
> > there. In particular I'm thinking of what is on savannah.gnu.org, e.g.: 
> > http://savannah.gnu.org/patch/?group=inetutils
> 
> I was talking to Alex, and he has persuaded me now that bugzilla is a good 
> solution after all! The problems I had with it were primarily due to there 
> not being a good mapping between bug states and patch states.
> 
> But it turns out that the Bugzilla folks have now thought of that. The 
> primary way to sort this out is using flags, like:
> 
> http://bugzilla.mozilla.org/flag-help.html
> 
> With flags, the mozilla folks sensibly use bugzilla for patch review.
> 
> Alex also pointed out that with Bugzilla, it means that all patches are in 
> one place - both patches that we say close bugs, and new patches. This 
> means people looking for patches only need to search one place.
> 
> The only thing is that we can't just add flags to bugzilla.redhat.com... 
> so I suggest we go ahead and make a decision about moving to 
> http://bugs.ecos.sourceware.org/
> 
> Does it look okay by everyone? If so, we can shut down the old bugzilla, 
> move all the existing bugs over, and update the web pages to point to 
> bugs.ecos.sourceware.org.
> 

I'm OK with this.  BTW, can we actuall use the eCos logo that's on the
page?

> Then once we're running with that and happy that it works, we can start 
> looking at what's needed to get patches in there, primarily involving 
> documenting patch submission procedure.
> 
> One thing I'd still want cleared up is how we keep track of what's 
> actually being checked in, i.e. when a patch would transition between 
> "approved" and "committed" states. I don't know if Alex has any ideas on that.
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: Patch policy

[Alex Schuilenburg]

Gary Thomas wrote:
>>Does it look okay by everyone? If so, we can shut down the old bugzilla, 
>>move all the existing bugs over, and update the web pages to point to 
>>bugs.ecos.sourceware.org.
> 
> I'm OK with this.  BTW, can we actuall use the eCos logo that's on the
> page?

IMHO yes. The logo is used in the true spirit of open source and not in 
a commercial context.  Plus the logo is simply a link to the src on s.r.c.

I think if Red Hat were to object to it's use in this context, they 
would get egg on their face. As someone once said, it is easier to ask 
for forgiveness than permission especially when Red Hat is concerned, 
and Red Hat have no further commercial interest in eCos.

Usual acknowledgements will apply.
-- Alex

Re: Patch policy

[Jonathan Larmour]

Gary Thomas wrote:
> 
> I'm OK with this.  BTW, can we actuall use the eCos logo that's on the
> page?

An interesting point. Here's my interpretation (although IANAL):

By the strictest legal definition anybody should seek permission for use 
of trademarks. But that's true with _any_ use of trademarks so we couldn't 
even mention "eCos". As you can see, out on the net, that's not true, and 
it is well established that you cannot defend a trademark in one place if 
you've never defended it elsewhere, so we're pretty safe. And established 
practice (and case law) says you can, as long as there's no attempt to 
pass off, normally by acknowledging the trademark.

We also have a considerable defence in using it because of the continuity 
of "permission"... Red Hat established the eCos site on sourceware and 
have continued to allow us to use and enhance it.... this is just one of 
those enhancements. The fact it resides on a different machine should make 
no difference.

What we may need to have on there is a "Legal information" link to 
acknowledge that eCos/RedBoot and the logo are trademarks of Red Hat, or 
just written in small font text at the bottom.

Interestingly, the main s.r.c eCos and redboot websites have _never_ 
mentioned trademarks, nor has the logo ever had a (TM) superscript. The 
logo isn't a registered trademark AFAIK, so RH's legal protection is minimal.

Of course the other strong argument is that Red Hat don't really have any 
desire to make a fuss when the point is that they don't intend to assert 
control over eCos any more.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Alex Schuilenburg]

Jonathan Larmour wrote:
[...]
> Interestingly, the main s.r.c eCos and redboot websites have _never_ 
> mentioned trademarks, nor has the logo ever had a (TM) superscript. The 
> logo isn't a registered trademark AFAIK, so RH's legal protection is 
> minimal.

Incorrect. ECOS and the logo are *both* registered trademarks of Red 
Hat, so be careful there.  The TM superscript does indeed exist for the 
logo on all handouts given away by Red Hat and Cygnus, and I have 
correspondence from Mark Webbink verifying this.


> Of course the other strong argument is that Red Hat don't really have 
> any desire to make a fuss when the point is that they don't intend to 
> assert control over eCos any more.

I agree with this, although I would seek Red Hat's permission and stump 
up the megacash they are asking if I were to use the logo in a 
commercial context.  However, as a free open source project I don't 
believe Red Hat will object to its use in the context proposed.  See my 
previous email...

IANAL

-- Alex

Re: Patch policy

[Jonathan Larmour]

Alex Schuilenburg wrote:
> Jonathan Larmour wrote:
> [...]
> 
>> Interestingly, the main s.r.c eCos and redboot websites have _never_ 
>> mentioned trademarks, nor has the logo ever had a (TM) superscript. 
>> The logo isn't a registered trademark AFAIK, so RH's legal protection 
>> is minimal.
> 
> 
> Incorrect. ECOS and the logo are *both* registered trademarks of Red 
> Hat, so be careful there.

eCos is a *registered* trademark. The logo AFAIK isn't.

 >  The TM superscript does indeed exist for the
> logo on all handouts given away by Red Hat and Cygnus,

TM doesn't mean registered though.... specifically not in fact. I believe 
you that there may well have been handouts with the TM superscript... in 
fact I've just looked and the stickers I have here do have the TM I see. 
But the laxness in applying the TM as evidenced by the existing public use 
of logos by Red Hat makes it very difficult to enforce.

 > and I have
> correspondence from Mark Webbink verifying this.

He lumped the eCos registered trademark and other trademarks together if 
you're referring to what I think you are.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Alex Schuilenburg]

Jonathan Larmour wrote:
[...]
>>> Interestingly, the main s.r.c eCos and redboot websites have _never_ 
>>> mentioned trademarks, nor has the logo ever had a (TM) superscript. 
>>> The logo isn't a registered trademark AFAIK, so RH's legal protection 
>>> is minimal.
>>
>>
>>
>> Incorrect. ECOS and the logo are *both* registered trademarks of Red 
>> Hat, so be careful there.
> 
> eCos is a *registered* trademark. The logo AFAIK isn't.

The logo *is* since it contains the words ECOS and ECOS is a registered 
trademark of Red Hat.  I should have been more specific:  Under 
trademark law, colour, style, font, case, etc all are ignored if the 
text is trademarked. As such, the logo is just a stylised version of the 
text and hence is covered by the ECOS trademark.

>  >  The TM superscript does indeed exist for the
> 
>> logo on all handouts given away by Red Hat and Cygnus,
> 
> 
> TM doesn't mean registered though.... specifically not in fact. I 

Correct.  It can be trademarked under common law - just harder to 
prove/defend.


> believe you that there may well have been handouts with the TM 
> superscript... in fact I've just looked and the stickers I have here do 
> have the TM I see. But the laxness in applying the TM as evidenced by 
> the existing public use of logos by Red Hat makes it very difficult to 
> enforce.

*Very* incorrect. Red Hat are *very* serious when it comes to defending 
their trademarks, and the trademarks do not have to be registered as you 
pointed out.  Not just the "Red Hat" trademark but other trademarks 
also. They have put companies out of business defending their trademark, 
the most recent was last March (IIRC) when they closed down some 
business that was selling versions of Linux with the same codename as 
their latest release.


> 
>  > and I have
> 
>> correspondence from Mark Webbink verifying this.
> 
> 
> He lumped the eCos registered trademark and other trademarks together if 
> you're referring to what I think you are.

If you're referring to what I think you are, then no :-)

And BTW, I believe you have to acknowledge trademarks by their owners. I 
don't think you can get away with "All registered Trade Marks are the 
property of their owners" anymore.  Std practice though is to be told of 
the infringement so you have the opportunity to put things right.  Just 
to be safe and proper, I do suggest you should put in a legal disclaimer.

IANAL
-- Alex

> 
> Jifl

Re: Patch policy

[Jonathan Larmour]

Alex Schuilenburg wrote:
> 
> The logo *is* since it contains the words ECOS and ECOS is a registered 
> trademark of Red Hat.  I should have been more specific:  Under 
> trademark law, colour, style, font, case, etc all are ignored if the 
> text is trademarked. As such, the logo is just a stylised version of the 
> text and hence is covered by the ECOS trademark.

I wonder why I've never seen them use (R) with the logo. Evidently it's a 
good thing IANAL then ;).

>> believe you that there may well have been handouts with the TM 
>> superscript... in fact I've just looked and the stickers I have here 
>> do have the TM I see. But the laxness in applying the TM as evidenced 
>> by the existing public use of logos by Red Hat makes it very difficult 
>> to enforce.
> 
> *Very* incorrect. Red Hat are *very* serious when it comes to defending 
> their trademarks, and the trademarks do not have to be registered as you 
> pointed out.  Not just the "Red Hat" trademark but other trademarks 
> also. They have put companies out of business defending their trademark, 
> the most recent was last March (IIRC) when they closed down some 
> business that was selling versions of Linux with the same codename as 
> their latest release.

But that's presumably "passing off" which is not what we are doing. It's 
impossible to pass sourceware eCos off as a discontinued product ;-). Not 
that it could be, having been established by Red Hat, etc.etc.

> And BTW, I believe you have to acknowledge trademarks by their owners. I 
> don't think you can get away with "All registered Trade Marks are the 
> property of their owners" anymore.  Std practice though is to be told of 
> the infringement so you have the opportunity to put things right.  Just 
> to be safe and proper, I do suggest you should put in a legal disclaimer.

I've done so by editting the footer, although it appears to be global to 
the site, not just the front page. If you have a better idea please say 
(or just go ahead and do as far as I'm concerned). e.g. if you know how to 
add whole new pages to bugzilla.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Alex Schuilenburg]

Jonathan Larmour wrote:
>> And BTW, I believe you have to acknowledge trademarks by their owners. 
>> I don't think you can get away with "All registered Trade Marks are 
>> the property of their owners" anymore.  Std practice though is to be 
>> told of the infringement so you have the opportunity to put things 
>> right.  Just to be safe and proper, I do suggest you should put in a 
>> legal disclaimer.
> 
> 
> I've done so by editting the footer, although it appears to be global to 
> the site, not just the front page. If you have a better idea please say 
> (or just go ahead and do as far as I'm concerned). e.g. if you know how 
> to add whole new pages to bugzilla.

As I said, if you unknowingly infringe on trademark etc, you have to be 
given the opportunity to put it right.  So rather than clutter all the 
pages with Red Hat, I moved the reference out of the std footer and 
simply put a link to a new trademark page from the front page (Legal 
Statement). This is just a simple page listing trademarks as well as the 
"coverall" statement to catch any remainders.

Source is in place so you can add/edit/make pretty as appropriate.
-- Alex

Re: Patch policy

[Alex Schuilenburg]

Jonathan Larmour wrote:
>> I'd suggest not using bugzilla actually. I've already been thinking 
>> about this problem and there are well established patch managers out 
>> there. In particular I'm thinking of what is on savannah.gnu.org, 
>> e.g.: http://savannah.gnu.org/patch/?group=inetutils
> 
> 
> I was talking to Alex, and he has persuaded me now that bugzilla is a 
> good solution after all! The problems I had with it were primarily due 
> to there not being a good mapping between bug states and patch states.
> 
> But it turns out that the Bugzilla folks have now thought of that. The 
> primary way to sort this out is using flags, like:
> 
> http://bugzilla.mozilla.org/flag-help.html
> 
> With flags, the mozilla folks sensibly use bugzilla for patch review.

I should also point out that you can define as many flags as you want as 
well as associate them with different components, etc, as well as bugs 
and attachments.  So it is really up to you to decide what you want the 
process to be.


> Alex also pointed out that with Bugzilla, it means that all patches are 
> in one place - both patches that we say close bugs, and new patches. 
> This means people looking for patches only need to search one place.
> 
> The only thing is that we can't just add flags to bugzilla.redhat.com... 
> so I suggest we go ahead and make a decision about moving to 
> http://bugs.ecos.sourceware.org/
> 
> Does it look okay by everyone? If so, we can shut down the old bugzilla, 
> move all the existing bugs over, and update the web pages to point to 
> bugs.ecos.sourceware.org.

I have no problem with this.

> 
> Then once we're running with that and happy that it works, we can start 
> looking at what's needed to get patches in there, primarily involving 
> documenting patch submission procedure.
> 
> One thing I'd still want cleared up is how we keep track of what's 
> actually being checked in, i.e. when a patch would transition between 
> "approved" and "committed" states. I don't know if Alex has any ideas on 
> that.

I would have thought something like flag "review+" with associated bug 
state CLOSED would imply that it was applied and committed.  The 
bug/patch state would be RESOLVED (since the feature/enhancement was 
added by a patch), so after a patch goes through "request review" 
(review?) followed by "review approved" (review+) the next state would 
be "CLOSED".

Alternatively since a flag status is simply a single character (Mozilla 
folks used '?','-','+' and NULL) you can also add a new flag state like 
'=' to mean committed (review=).

As you have control of the flag feature, you do not even have to call 
the flag "review" and you can add as many flags as you want.  For 
example, Mozilla use "superreview".  To add flags (follow the "flags" 
link at the bottom of the "query" page - this is available only to 
maintainers - to add/edit/delete flags etc).

Up to you really to decide - you have the power.  Unlike 
bugzilla.redhat.com (well you try to get the sources for the Red Hat 
version of bugzilla then ;-), this really is open source, and you know 
what you always say... ;-)

BTW, the table description for flags is:
+-------------------+--------------+------+-----+---------------------+
| Field             | Type         | Null | Key | Default             |
+-------------------+--------------+------+-----+---------------------+
| id                | mediumint(9) |      | PRI | 0                   | 
     | type_id           | smallint(6)  |      |     | 0 
    | | status            | char(1)      |      |     | 
     | | bug_id            | mediumint(9) |      | MUL | 0 
      | | attach_id         | mediumint(9) | YES  |     | NULL 
       | | creation_date     | datetime     |      |     | 0000-00-00 
00:00:00 | | modification_date | datetime     | YES  |     | NULL 
          | | setter_id         | mediumint(9) | YES  | MUL | NULL 
           |     | requestee_id      | mediumint(9) | YES  | MUL | NULL 
                | 
+-------------------+--------------+------+-----+---------------------+

Like I said, the power is yours...
-- Alex


> 
> Jifl

Re: Patch policy

[Jonathan Larmour]

Gary Thomas wrote:
> ** Disclaimer: I'm sure that I'm as guilty as anyone
> 
> There seems to be a gap [i.e. failing] in the response to
> patches from outsiders.  Sometimes they are handled quite
> quickly, sometimes never.  I think we need to establish
> some policies on how to handle these efficiently.

The problem is setting time aside for the large ones. It can take a few 
hours to thoroughly review a large contrib like, say, the new openRISC 
port, even when there are few problems.

If it's any consolation, after 2.0 it's one of my priorities to deal with 
the patch backlog... it's _somewhat_ been put on hold as "net time" for 
now would be better put into 2.0, and FYI we're playing with some release 
candidates here on various hosts so we're getting pretty close on that.

I know it's eCosCentric's view that a proportion of my time will become 
dedicated to net stuff primarily for things like patches.

> At the very least, we should try and assign a patch to
> a maintainer within some short period of time and then it's
> that person's responsibility to take care of it - whatever
> the outcome.  As is, I see things come in that I'm comfortable
> with that sometimes I take up, sometimes I leave by.  In the
> latter case, I simply assume that someone else will handle
> it.  I think this is the failing.

FWIW I've been assuming the final buck passes to me, so unless anyone else 
volunteers it's my problem. I do have every unapplied patch sitting here 
(just in a big pile, but still), but I do have the ability to go back and 
do it. And I still intend to, despite the age of some of the patches now!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Re: Patch policy

[Gary Thomas]

On Tue, 2003-05-06 at 09:00, Jonathan Larmour wrote:
> Gary Thomas wrote:
> > ** Disclaimer: I'm sure that I'm as guilty as anyone
> > 
> > There seems to be a gap [i.e. failing] in the response to
> > patches from outsiders.  Sometimes they are handled quite
> > quickly, sometimes never.  I think we need to establish
> > some policies on how to handle these efficiently.
> 
> The problem is setting time aside for the large ones. It can take a few 
> hours to thoroughly review a large contrib like, say, the new openRISC 
> port, even when there are few problems.
> 
> If it's any consolation, after 2.0 it's one of my priorities to deal with 
> the patch backlog... it's _somewhat_ been put on hold as "net time" for 
> now would be better put into 2.0, and FYI we're playing with some release 
> candidates here on various hosts so we're getting pretty close on that.
> 
> I know it's eCosCentric's view that a proportion of my time will become 
> dedicated to net stuff primarily for things like patches.
> 
> > At the very least, we should try and assign a patch to
> > a maintainer within some short period of time and then it's
> > that person's responsibility to take care of it - whatever
> > the outcome.  As is, I see things come in that I'm comfortable
> > with that sometimes I take up, sometimes I leave by.  In the
> > latter case, I simply assume that someone else will handle
> > it.  I think this is the failing.
> 
> FWIW I've been assuming the final buck passes to me, so unless anyone else 
> volunteers it's my problem. I do have every unapplied patch sitting here 
> (just in a big pile, but still), but I do have the ability to go back and 
> do it. And I still intend to, despite the age of some of the patches now!

Fair enough - I just wanted to see what we can do to formalize this.
I'm more than glad to work on some of these patches, but what I see
right now is that sometimes things get stalled - or at least seem to.

I would not want for everything to fall on your shoulders, certainly
if it makes sense to share the load :-)  Whatever we can do to improve
this, especially in the punter's eyes, will be a good thing.

I'm looking at Savannah now, just for my own edification.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates