* Patch policy @ 2003-05-06 12:59 Gary Thomas 2003-05-06 13:17 ` Mark Salter ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Gary Thomas @ 2003-05-06 12:59 UTC (permalink / raw) To: eCos Maintainers ** 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 12:59 Patch policy Gary Thomas @ 2003-05-06 13:17 ` Mark Salter 2003-05-06 13:26 ` Andrew Lunn 2003-05-06 15:00 ` Jonathan Larmour 2 siblings, 0 replies; 20+ messages in thread From: Mark Salter @ 2003-05-06 13:17 UTC (permalink / raw) To: gary; +Cc: ecos-maintainers > ** 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 12:59 Patch policy Gary Thomas 2003-05-06 13:17 ` Mark Salter @ 2003-05-06 13:26 ` Andrew Lunn 2003-05-06 13:34 ` Gary Thomas 2003-05-06 14:46 ` Jonathan Larmour 2003-05-06 15:00 ` Jonathan Larmour 2 siblings, 2 replies; 20+ messages in thread From: Andrew Lunn @ 2003-05-06 13:26 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Maintainers > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 13:26 ` Andrew Lunn @ 2003-05-06 13:34 ` Gary Thomas 2003-05-06 13:40 ` Andrew Lunn 2003-05-06 14:46 ` Jonathan Larmour 1 sibling, 1 reply; 20+ messages in thread From: Gary Thomas @ 2003-05-06 13:34 UTC (permalink / raw) To: Andrew Lunn; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 13:34 ` Gary Thomas @ 2003-05-06 13:40 ` Andrew Lunn 2003-05-06 13:44 ` Gary Thomas 2003-05-06 14:51 ` Jonathan Larmour 0 siblings, 2 replies; 20+ messages in thread From: Andrew Lunn @ 2003-05-06 13:40 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Maintainers > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 13:40 ` Andrew Lunn @ 2003-05-06 13:44 ` Gary Thomas 2003-05-06 14:51 ` Jonathan Larmour 1 sibling, 0 replies; 20+ messages in thread From: Gary Thomas @ 2003-05-06 13:44 UTC (permalink / raw) To: Andrew Lunn; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 13:40 ` Andrew Lunn 2003-05-06 13:44 ` Gary Thomas @ 2003-05-06 14:51 ` Jonathan Larmour 1 sibling, 0 replies; 20+ messages in thread From: Jonathan Larmour @ 2003-05-06 14:51 UTC (permalink / raw) To: Andrew Lunn; +Cc: Gary Thomas, eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 13:26 ` Andrew Lunn 2003-05-06 13:34 ` Gary Thomas @ 2003-05-06 14:46 ` Jonathan Larmour 2003-05-07 20:30 ` Jonathan Larmour 1 sibling, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2003-05-06 14:46 UTC (permalink / raw) To: Andrew Lunn; +Cc: Gary Thomas, eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 14:46 ` Jonathan Larmour @ 2003-05-07 20:30 ` Jonathan Larmour 2003-05-07 21:54 ` Gary Thomas 2003-05-07 23:27 ` Alex Schuilenburg 0 siblings, 2 replies; 20+ messages in thread From: Jonathan Larmour @ 2003-05-07 20:30 UTC (permalink / raw) To: eCos Maintainers; +Cc: 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. 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 20:30 ` Jonathan Larmour @ 2003-05-07 21:54 ` Gary Thomas 2003-05-07 22:48 ` Alex Schuilenburg 2003-05-07 23:02 ` Jonathan Larmour 2003-05-07 23:27 ` Alex Schuilenburg 1 sibling, 2 replies; 20+ messages in thread From: Gary Thomas @ 2003-05-07 21:54 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers, Alex Schuilenburg 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 21:54 ` Gary Thomas @ 2003-05-07 22:48 ` Alex Schuilenburg 2003-05-07 23:02 ` Jonathan Larmour 1 sibling, 0 replies; 20+ messages in thread From: Alex Schuilenburg @ 2003-05-07 22:48 UTC (permalink / raw) To: Gary Thomas; +Cc: Jonathan Larmour, eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 21:54 ` Gary Thomas 2003-05-07 22:48 ` Alex Schuilenburg @ 2003-05-07 23:02 ` Jonathan Larmour 2003-05-07 23:39 ` Alex Schuilenburg 1 sibling, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2003-05-07 23:02 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Maintainers, Alex Schuilenburg 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 23:02 ` Jonathan Larmour @ 2003-05-07 23:39 ` Alex Schuilenburg 2003-05-07 23:55 ` Jonathan Larmour 0 siblings, 1 reply; 20+ messages in thread From: Alex Schuilenburg @ 2003-05-07 23:39 UTC (permalink / raw) To: Jonathan Larmour; +Cc: Gary Thomas, eCos Maintainers, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 23:39 ` Alex Schuilenburg @ 2003-05-07 23:55 ` Jonathan Larmour 2003-05-08 0:18 ` Alex Schuilenburg 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2003-05-07 23:55 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 23:55 ` Jonathan Larmour @ 2003-05-08 0:18 ` Alex Schuilenburg 2003-05-08 3:16 ` Jonathan Larmour 0 siblings, 1 reply; 20+ messages in thread From: Alex Schuilenburg @ 2003-05-08 0:18 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers, 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-08 0:18 ` Alex Schuilenburg @ 2003-05-08 3:16 ` Jonathan Larmour 2003-05-08 9:45 ` Alex Schuilenburg 0 siblings, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2003-05-08 3:16 UTC (permalink / raw) To: Alex Schuilenburg; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-08 3:16 ` Jonathan Larmour @ 2003-05-08 9:45 ` Alex Schuilenburg 0 siblings, 0 replies; 20+ messages in thread From: Alex Schuilenburg @ 2003-05-08 9:45 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-07 20:30 ` Jonathan Larmour 2003-05-07 21:54 ` Gary Thomas @ 2003-05-07 23:27 ` Alex Schuilenburg 1 sibling, 0 replies; 20+ messages in thread From: Alex Schuilenburg @ 2003-05-07 23:27 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 12:59 Patch policy Gary Thomas 2003-05-06 13:17 ` Mark Salter 2003-05-06 13:26 ` Andrew Lunn @ 2003-05-06 15:00 ` Jonathan Larmour 2003-05-06 15:06 ` Gary Thomas 2 siblings, 1 reply; 20+ messages in thread From: Jonathan Larmour @ 2003-05-06 15:00 UTC (permalink / raw) To: Gary Thomas; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Patch policy 2003-05-06 15:00 ` Jonathan Larmour @ 2003-05-06 15:06 ` Gary Thomas 0 siblings, 0 replies; 20+ messages in thread From: Gary Thomas @ 2003-05-06 15:06 UTC (permalink / raw) To: Jonathan Larmour; +Cc: eCos Maintainers 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-05-08 9:45 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-06 12:59 Patch policy Gary Thomas 2003-05-06 13:17 ` Mark Salter 2003-05-06 13:26 ` Andrew Lunn 2003-05-06 13:34 ` Gary Thomas 2003-05-06 13:40 ` Andrew Lunn 2003-05-06 13:44 ` Gary Thomas 2003-05-06 14:51 ` Jonathan Larmour 2003-05-06 14:46 ` Jonathan Larmour 2003-05-07 20:30 ` Jonathan Larmour 2003-05-07 21:54 ` Gary Thomas 2003-05-07 22:48 ` Alex Schuilenburg 2003-05-07 23:02 ` Jonathan Larmour 2003-05-07 23:39 ` Alex Schuilenburg 2003-05-07 23:55 ` Jonathan Larmour 2003-05-08 0:18 ` Alex Schuilenburg 2003-05-08 3:16 ` Jonathan Larmour 2003-05-08 9:45 ` Alex Schuilenburg 2003-05-07 23:27 ` Alex Schuilenburg 2003-05-06 15:00 ` Jonathan Larmour 2003-05-06 15:06 ` Gary Thomas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).