Thanks to all for coming. We'll be synchronizing on Tuesday (5/18) via email about the status of sorting out the repos vs. live site patches, etc. so that we can move ahead at our next meeting (5/20, same time, same place). Actions towards the bottom of this email, and of course, in the logs. :)
-robyn
Minutes: http://meetbot.fedoraproject.org/fedora-mktg/2010-05-13/fedora_insight.2010-... Minutes (text): http://meetbot.fedoraproject.org/fedora-mktg/2010-05-13/fedora_insight.2010-... Log: http://meetbot.fedoraproject.org/fedora-mktg/2010-05-13/fedora_insight.2010-...
==================================================== #fedora-mktg: Fedora Insight weekly meeting (f'real) ====================================================
Meeting started by stickster at 18:03:06 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-mktg/2010-05-13/fedora_insight.2010-... .
Meeting summary --------------- * Roll call (stickster, 18:04:37) * LINK: https://fedoraproject.org/wiki/Fedora_Insight#Meeting_agenda (stickster, 18:06:51)
* Go-forward plan (stickster, 18:08:02) * This scheduled meeting was something that our Zikula friends agreed they could make, so we could make concrete plans to develop toward our June 15 milestone. (stickster, 18:12:16) * The Zikula 1.2.2 that I believe we're running has vulnerabilities. Despite the fact that 1.2.3 has bundled library problems, FESCo is OK with using it temporarily while we await the 1.3 release, since upstream is committed to fixing the bundled libs. (stickster, 18:24:26)
* Ticket review (stickster, 18:25:05) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2100 (stickster, 18:25:13) * This ticket is not critical path. It's addressible later. (stickster, 18:26:01) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2104 (stickster, 18:26:14) * warning message at successful login (stickster, 18:26:42) * ACTION: smooge Find out if ke4qqq has built a Zikula 1.2.3 package already (stickster, 18:28:42) * ACTION: rbergeron Close 2104 as fixed (stickster, 18:29:40) * LINK: https://fedorahosted.org/fedora-infrastructure/ticket/2105 (stickster, 18:30:17) * LINK: https://fedorahosted.org/fedora-zikula-theme/ (stickster, 18:33:15) * 2105 is not fixed. The module code appears to be out of sync with what's deployed on publictest6. We need this to be reconciled and proper releases done as we go, so we're not wondering what code is found where. (stickster, 18:35:37) * LINK: http://git.fedorahosted.org/git/?p=fedora-zikula-theme.git;a=summary <-- :-( (stickster, 18:44:34) * ACTION: mateo will get all the diffs between what's in /usr/share/zikula/modules/FASAuth (for example) and what's in the git fedora-zikula repo accounted for and committed as a series (stickster, 18:58:15) * we'll all use the logistics@ list to communicate more effectively. IRC is too easy to lose and forget. (stickster, 18:58:40) * ACTION: stickster clean up [[Insight]] page to make it shorter and more full of useful content (stickster, 19:00:31) * ACTION: smooge look into parallel Zikula instances if we need any additional ones to effectively develop, test, deploy beyond the two we have now on pt6 and stg (stickster, 19:01:06) * ACTION: rbergeron will continue to serve as test monkey :-) (stickster, 19:01:59) * AGREED: We'll email on logistics@ list to see where we are on Tuesday, *before* we get to our Thursday meeting (stickster, 19:04:26)
Meeting ended at 19:05:16 UTC.
Action Items ------------ * smooge Find out if ke4qqq has built a Zikula 1.2.3 package already * rbergeron Close 2104 as fixed * mateo will get all the diffs between what's in /usr/share/zikula/modules/FASAuth (for example) and what's in the git fedora-zikula repo accounted for and committed as a series * stickster clean up [[Insight]] page to make it shorter and more full of useful content * smooge look into parallel Zikula instances if we need any additional ones to effectively develop, test, deploy beyond the two we have now on pt6 and stg * rbergeron will continue to serve as test monkey :-)
Action Items, by person ----------------------- * rbergeron * rbergeron Close 2104 as fixed * rbergeron will continue to serve as test monkey :-) * smooge * smooge Find out if ke4qqq has built a Zikula 1.2.3 package already * smooge look into parallel Zikula instances if we need any additional ones to effectively develop, test, deploy beyond the two we have now on pt6 and stg * stickster * stickster clean up [[Insight]] page to make it shorter and more full of useful content * **UNASSIGNED** * mateo will get all the diffs between what's in /usr/share/zikula/modules/FASAuth (for example) and what's in the git fedora-zikula repo accounted for and committed as a series
People Present (lines said) --------------------------- * stickster (127) * rbergeron (58) * smooge (34) * mateo__ (21) * zodbot (6) * kanarip (2) * gwerra (2) * ricky (2) * anthro-diana (1) * th0br0 (1) * etali (1) * mizmo (1)
On Thu, May 13, 2010 at 12:11:33PM -0700, Robyn Bergeron wrote:
- ACTION: mateo will get all the diffs between what's in /usr/share/zikula/modules/FASAuth (for example) and what's in the git fedora-zikula repo accounted for and committed as a series (stickster, 18:58:15)
Mateo, how is this going?
Were you able to get the changes between pt6.fp.o and stg.fp.o accounted for and committed?
- ACTION: stickster clean up [[Insight]] page to make it shorter and more full of useful content (stickster, 19:00:31)
/me takes his lumps. I haven't got to this yet, but it's on my "short TODO" list.
- AGREED: We'll email on logistics@ list to see where we are on Tuesday, *before* we get to our Thursday meeting (stickster, 19:04:26)
Which is where this mail comes in! :-)
Hi Paul I'm having ISP issues (I guess) when trying to push my changes. http://fpaste.org/3J4T/
There are changes on stg.fp.o too?
The ISP can be the issue... I'm going to talk because I was down since the Sunday's night storm ¬¬ Greetings
On Wed, May 19, 2010 at 02:24:32PM -0300, Mateo TibaPalacios wrote:
Hi Paul I'm having ISP issues (I guess) when trying to push my changes. http://fpaste.org/3J4T/
There are changes on stg.fp.o too?
The ISP can be the issue... I'm going to talk because I was down since the Sunday's night storm ¬¬ Greetings
The error is happening because you did a clone from a git:// address instead of ssh:// (which is authenticated).
To fix this, just edit the .git/config file in your cloned copy, and reset the address from git:// to ssh:// and I believe it should work.
On Wed, May 19, 2010 at 04:39:58PM -0400, Paul W. Frields wrote:
On Wed, May 19, 2010 at 02:24:32PM -0300, Mateo TibaPalacios wrote:
Hi Paul I'm having ISP issues (I guess) when trying to push my changes. http://fpaste.org/3J4T/
There are changes on stg.fp.o too?
The ISP can be the issue... I'm going to talk because I was down since the Sunday's night storm ¬¬ Greetings
The error is happening because you did a clone from a git:// address instead of ssh:// (which is authenticated).
To fix this, just edit the .git/config file in your cloned copy, and reset the address from git:// to ssh:// and I believe it should work.
I don't know whether there are changes on stg.fp.o as well -- but there might be. In the future there shouldn't be. :-) What I'm hoping is that you and Hiemanshu can capture those changes and get them committed to the hosted projects for fedora-zikula and fedora-zikula-theme, so our testing can commence from a known good state.
As we go, we need to be capturing tested changes correctly in git branches so that we are always able to redeploy when needed without losing anything.
Off-topic maybe: What is the policy to using vendor fixes that have not yet been released?
Drak
On 21 May 2010 00:38, Paul W. Frields stickster@gmail.com wrote:
On Wed, May 19, 2010 at 04:39:58PM -0400, Paul W. Frields wrote:
On Wed, May 19, 2010 at 02:24:32PM -0300, Mateo TibaPalacios wrote:
Hi Paul I'm having ISP issues (I guess) when trying to push my changes. http://fpaste.org/3J4T/
There are changes on stg.fp.o too?
The ISP can be the issue... I'm going to talk because I was down since the Sunday's night storm ¬¬ Greetings
The error is happening because you did a clone from a git:// address instead of ssh:// (which is authenticated).
To fix this, just edit the .git/config file in your cloned copy, and reset the address from git:// to ssh:// and I believe it should work.
I don't know whether there are changes on stg.fp.o as well -- but there might be. In the future there shouldn't be. :-) What I'm hoping is that you and Hiemanshu can capture those changes and get them committed to the hosted projects for fedora-zikula and fedora-zikula-theme, so our testing can commence from a known good state.
As we go, we need to be capturing tested changes correctly in git branches so that we are always able to redeploy when needed without losing anything.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ logistics mailing list logistics@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/logistics
On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote:
Off-topic maybe: What is the policy to using vendor fixes that have not yet been released? Drak
Good question, Drak. I think it's acceptable for us to include patches in a RPM that are backported fixes expected to be in the next upstream release. This happens frequently in the kernel, for example, especially where Fedora contributors are providing said patches. The goal is always to reduce those fixes/patches to zero, or as close to zero as possible.
On 21 May 2010 19:51, Paul W. Frields stickster@gmail.com wrote:
On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote:
Off-topic maybe: What is the policy to using vendor fixes that have
not
yet been released? Drak
Good question, Drak. I think it's acceptable for us to include patches in a RPM that are backported fixes expected to be in the next upstream release. This happens frequently in the kernel, for example, especially where Fedora contributors are providing said patches. The goal is always to reduce those fixes/patches to zero, or as close to zero as possible.
What is the procedure for letting you guys know the packaging requirements? Is there something we can add to our continuous integration process? We could build it automatically...
Drak
On Fri, May 21, 2010 at 07:57:52PM +0545, Drak wrote:
On 21 May 2010 19:51, Paul W. Frields <[1]stickster@gmail.com> wrote:
On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote: > Off-topic maybe: What is the policy to using vendor fixes that have not > yet been released? > Drak Good question, Drak. I think it's acceptable for us to include patches in a RPM that are backported fixes expected to be in the next upstream release. This happens frequently in the kernel, for example, especially where Fedora contributors are providing said patches. The goal is always to reduce those fixes/patches to zero, or as close to zero as possible.What is the procedure for letting you guys know the packaging requirements? Is there something we can add to our continuous integration process? We could build it automatically... Drak
Hi Drak,
What packaging requirements are you referring to? I'm not sure I'm clear on what you're asking.
Normally the maintainers of a Fedora package keep tabs on upstream releases, and when there's a new one, or if there's a good reason to patch and rebuild, the maintainer would do that in Fedora. One of our distro requirements is to be fully self-hosting, so builds need to happen in the Fedora build system. However, any upstream developer with a FAS account should be able to anonymously check out our package source tree, trivially fiddle with the spec file to use new sources, and send a "scratch build" request to our system. (A scratch build is basically a test build that will not be published for general use, but is good for temporary testing use.)
Does this help clarify at all?
I was asking how do we let Fedora know if we have applied a vendor patch to our distro that has not yet been released by the vendor in an official version but will be part of their next release (some when). Is there an official way to let you know what the patches are? Possibly just a notice in our readme sighting vendor versions and or revision numbers from their VCS?
Regards,
Drak
On 21 May 2010 21:08, Paul W. Frields stickster@gmail.com wrote:
On Fri, May 21, 2010 at 07:57:52PM +0545, Drak wrote:
On 21 May 2010 19:51, Paul W. Frields <[1]stickster@gmail.com> wrote:
On Fri, May 21, 2010 at 09:36:11AM +0545, Drak wrote: > Off-topic maybe: What is the policy to using vendor fixes thathave
not > yet been released? > Drak Good question, Drak. I think it's acceptable for us to include patches in a RPM that are backported fixes expected to be in thenext
upstream release. This happens frequently in the kernel, forexample,
especially where Fedora contributors are providing said patches.The
goal is always to reduce those fixes/patches to zero, or as close to zero as possible.What is the procedure for letting you guys know the packaging requirements? Is there something we can add to our continuous
integration
process? We could build it automatically... Drak
Hi Drak,
What packaging requirements are you referring to? I'm not sure I'm clear on what you're asking.
Normally the maintainers of a Fedora package keep tabs on upstream releases, and when there's a new one, or if there's a good reason to patch and rebuild, the maintainer would do that in Fedora. One of our distro requirements is to be fully self-hosting, so builds need to happen in the Fedora build system. However, any upstream developer with a FAS account should be able to anonymously check out our package source tree, trivially fiddle with the spec file to use new sources, and send a "scratch build" request to our system. (A scratch build is basically a test build that will not be published for general use, but is good for temporary testing use.)
Does this help clarify at all?
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ logistics mailing list logistics@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/logistics
On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote:
I was asking how do we let Fedora know if we have applied a vendor patch to our distro that has not yet been released by the vendor in an official version but will be part of their next release (some when). Is there an official way to let you know what the patches are? Possibly just a notice in our readme sighting vendor versions and or revision numbers from their VCS?
I'm not sure what all your referencing: * Who is we? * What is our distro? * Who is the vendor? * Who is the you that you're letting know?
Fedora packagers generally add a comment to their spec file which describes a patch. So if they are adding a patch from upstream to backport a feature it might be like this:
# Patch from upstream to add comment capability # https://vcs.upstream.org/project/12345/file.php Source0: zikula-comment.patch
I don't think that's quite what you're asking but maybe it'll get us closer to understanding each other :-)
-Toshio
2010/5/22 Toshio Kuratomi a.badger@gmail.com
On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote:
I was asking how do we let Fedora know if we have applied a vendor patch
to our
distro that has not yet been released by the vendor in an official
version but
will be part of their next release (some when). Is there an official way
to
let you know what the patches are? Possibly just a notice in our readme sighting vendor versions and or revision numbers from their VCS?
I'm not sure what all your referencing:
- Who is we?
- What is our distro?
- Who is the vendor?
- Who is the you that you're letting know?
Ok plain English time :-P When we Zikula need to add a vendor patch for a vendor library we distribute with Zikula, we Zikula need to let you know what the vendor patch is so your packagers know what to patch. How do we let you know what the correct patch is officially. Vendor patch means a patch committed to their VCS but not yet released in an official version.
e.g. Zikula uses Smarty. Smarty fixes something important to us, but hasnt yet released a version that includes that fix. So we checkout revision X from their source control or file y from revision X and patch the version of Smarty we distribute. How do we let you know if we have in fact needed to do this.
This particular example is fictitious but the way, but could very well happen.
Drak
@Paul: Thanks, ssh worked :D
Even when I'm stuck with connection problems (seems like the hard electric storms around here are giving problems to the ISPs), I was able to push some stuff to fedora-zikula (AuthFAS pt6 sync) and fedora-insight-theme (Theme sync plus improvements).
Now I want to know if the designers have some stuff to apply to the theme, to improve the readability of the titles, for instance. I've put some efforts on the CSS with margins/paddings but some simple-design-stuff for headings could be awesome.
I liked a lot the headers of [1], a year old trend, but I guess that fits into the current theme.
P.S. I will check stg.fp.o to see if there's some stuff to sync to AuthFAS
Greetings!
[1] http://cssmania.com/galleries/2009/06/14/jepser-bernardino.php
On Sat, May 22, 2010 at 09:05:16AM +0545, Drak wrote:
2010/5/22 Toshio Kuratomi <[1]a.badger@gmail.com>
On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote: > I was asking how do we let Fedora know if we have applied a vendor patch to our > distro that has not yet been released by the vendor in an official version but > will be part of their next release (some when). Is there an official way to > let you know what the patches are? Possibly just a notice in our readme > sighting vendor versions and or revision numbers from their VCS? > I'm not sure what all your referencing: * Who is we? * What is our distro? * Who is the vendor? * Who is the you that you're letting know?Ok plain English time :-P When we Zikula need to add a vendor patch for a vendor library we distribute with Zikula, we Zikula need to let you know what the vendor patch is so your packagers know what to patch. How do we let you know what the correct patch is officially. Vendor patch means a patch committed to their VCS but not yet released in an official version. e.g. Zikula uses Smarty. Smarty fixes something important to us, but hasnt yet released a version that includes that fix. So we checkout revision X from their source control or file y from revision X and patch the version of Smarty we distribute. How do we let you know if we have in fact needed to do this. This particular example is fictitious but the way, but could very well happen. Drak
OK, thanks for that clarification Drak.
Recall that Fedora doesn't use bundled libraries, in part so that we can scale software maintenance across a wider group of participants. In this case, you'd likely want to notify the maintaners of both Zikula and the Smarty library to notify them of the situation and the specific patch needed.
At that time, my understanding is the Smarty maintainer would want to check the Smarty upstream for intention to release the patch. (You could provide references if desired to make this process faster.) That way we're only using patches that have buy-in from upstream -- which seems likely in the case you describe.
How often would you estimate this happens for Zikula?
On Mon, May 24, 2010 at 09:43:42AM -0400, Paul W. Frields wrote:
On Sat, May 22, 2010 at 09:05:16AM +0545, Drak wrote:
2010/5/22 Toshio Kuratomi <[1]a.badger@gmail.com>
On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote: > I was asking how do we let Fedora know if we have applied a vendor patch to our > distro that has not yet been released by the vendor in an official version but > will be part of their next release (some when). Is there an official way to > let you know what the patches are? Possibly just a notice in our readme > sighting vendor versions and or revision numbers from their VCS? > I'm not sure what all your referencing: * Who is we? * What is our distro? * Who is the vendor? * Who is the you that you're letting know?Ok plain English time :-P When we Zikula need to add a vendor patch for a vendor library we distribute with Zikula, we Zikula need to let you know what the vendor patch is so your packagers know what to patch. How do we let you know what the correct patch is officially. Vendor patch means a patch committed to their VCS but not yet released in an official version. e.g. Zikula uses Smarty. Smarty fixes something important to us, but hasnt yet released a version that includes that fix. So we checkout revision X from their source control or file y from revision X and patch the version of Smarty we distribute. How do we let you know if we have in fact needed to do this. This particular example is fictitious but the way, but could very well happen. Drak
OK, thanks for that clarification Drak.
Recall that Fedora doesn't use bundled libraries, in part so that we can scale software maintenance across a wider group of participants. In this case, you'd likely want to notify the maintaners of both Zikula and the Smarty library to notify them of the situation and the specific patch needed.
At that time, my understanding is the Smarty maintainer would want to check the Smarty upstream for intention to release the patch. (You could provide references if desired to make this process faster.) That way we're only using patches that have buy-in from upstream -- which seems likely in the case you describe.
(And hopefully the smarty packager would add the vendor patch to our smarty package).
For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting him open the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?
-Toshio
2010/5/24 Toshio Kuratomi a.badger@gmail.com
(And hopefully the smarty packager would add the vendor patch to our smarty package).
For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting him open the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?
I think ya'll jumping the gun. I was just asking a 'what-if' question. We simply do not allow forking or patching of vendor libraries, we never have done it - however, there have been a few instances where there was a patch applied upstream and we have included the upstream patch which was due to be released in a future version but not done so yet. I was just asking in view of your strict rules.
Anyway, we have decided to start tracking vendors anyhow in our distro so that maintainers have an easier task overall anyhow. Let me know if there is anything else that would be useful for packagers.
http://code.zikula.org/core/browser/branches/zikula-1.3/src/docs/VENDORS
Ok, so who are our packagers for Zikula - is there a way to find out from a wiki or something?
Drak
I packaged Zikula 1.2.2 that is on the staging server right now.
- Hiemanshu
2010/5/25 Drak drak@zikula.org
2010/5/24 Toshio Kuratomi a.badger@gmail.com
(And hopefully the smarty packager would add the vendor patch to our
smarty package).
For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting him open the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?
I think ya'll jumping the gun. I was just asking a 'what-if' question. We simply do not allow forking or patching of vendor libraries, we never have done it - however, there have been a few instances where there was a patch applied upstream and we have included the upstream patch which was due to be released in a future version but not done so yet. I was just asking in view of your strict rules.
Anyway, we have decided to start tracking vendors anyhow in our distro so that maintainers have an easier task overall anyhow. Let me know if there is anything else that would be useful for packagers.
http://code.zikula.org/core/browser/branches/zikula-1.3/src/docs/VENDORS
Ok, so who are our packagers for Zikula - is there a way to find out from a wiki or something?
Drak
logistics mailing list logistics@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/logistics
On Tue, May 25, 2010 at 12:44:55AM +0545, Drak wrote:
2010/5/24 Toshio Kuratomi <[1]a.badger@gmail.com>
(And hopefully the smarty packager would add the vendor patch to our smarty package). For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting him open the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?I think ya'll jumping the gun. I was just asking a 'what-if' question.
Nope, I think we're all on the same page here. We were giving answers to a hypothetical. I don't think anyone's expecting a bunch of patch requests to come rolling in! :-) But it's good for us to have some idea of whether anything like that might be expected in the future so the maintainers in question are prepared and ready to help.
We simply do not allow forking or patching of vendor libraries, we never have done it - however, there have been a few instances where there was a patch applied upstream and we have included the upstream patch which was due to be released in a future version but not done so yet. I was just asking in view of your strict rules. Anyway, we have decided to start tracking vendors anyhow in our distro so that maintainers have an easier task overall anyhow. Let me know if there is anything else that would be useful for packagers. [2]http://code.zikula.org/core/browser/branches/zikula-1.3/src/docs/VENDORS Ok, so who are our packagers for Zikula - is there a way to find out from a wiki or something? Drak
That's ke4qqq (David Nalley), to whom Toshio referred earlier. He was asking for David's opinion on how he would want to deal with this situation if it happened.
Okay :) Full ACK.
Btw... where is David... he seemed to drop off the air, at least for me. I mailed a half dozen times a while back but maybe I have the wrong mail address...?
Drak
On 25 May 2010 01:59, Paul W. Frields stickster@gmail.com wrote:
On Tue, May 25, 2010 at 12:44:55AM +0545, Drak wrote:
2010/5/24 Toshio Kuratomi <[1]a.badger@gmail.com>
(And hopefully the smarty packager would add the vendor patch to our smarty package). For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting himopen
the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?I think ya'll jumping the gun. I was just asking a 'what-if'
question.
Nope, I think we're all on the same page here. We were giving answers to a hypothetical. I don't think anyone's expecting a bunch of patch requests to come rolling in! :-) But it's good for us to have some idea of whether anything like that might be expected in the future so the maintainers in question are prepared and ready to help.
We simply do not allow forking or patching of vendor libraries, wenever
have done it - however, there have been a few instances where there
was a
patch applied upstream and we have included the upstream patch which
was
due to be released in a future version but not done so yet. I was
just
asking in view of your strict rules. Anyway, we have decided to start tracking vendors anyhow in our distro
so
that maintainers have an easier task overall anyhow. Let me know if
there
is anything else that would be useful for packagers. [2]
http://code.zikula.org/core/browser/branches/zikula-1.3/src/docs/VENDORS
Ok, so who are our packagers for Zikula - is there a way to find out
from
a wiki or something? Drak
That's ke4qqq (David Nalley), to whom Toshio referred earlier. He was asking for David's opinion on how he would want to deal with this situation if it happened.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ logistics mailing list logistics@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/logistics
2010/5/24 Drak drak@zikula.org:
Okay :) Full ACK. Btw... where is David... he seemed to drop off the air, at least for me. I mailed a half dozen times a while back but maybe I have the wrong mail address...? Drak
Hi Drak:
I apologize for my lack of response, the past few months have been quite hectic for me. Had Paul not called this thread to my attention I would likely have missed it as well.
BTW, you can look up any package in our package database here:
https://admin.fedoraproject.org/pkgdb
Here is the zikula specific reference https://admin.fedoraproject.org/pkgdb/acls/name/zikula?
2010/5/24 Toshio Kuratomi a.badger@gmail.com:
On Mon, May 24, 2010 at 09:43:42AM -0400, Paul W. Frields wrote:
On Sat, May 22, 2010 at 09:05:16AM +0545, Drak wrote:
2010/5/22 Toshio Kuratomi <[1]a.badger@gmail.com>
On Sat, May 22, 2010 at 02:03:06AM +0545, Drak wrote: > I was asking how do we let Fedora know if we have applied a vendor patch to our > distro that has not yet been released by the vendor in an official version but > will be part of their next release (some when). Is there an official way to > let you know what the patches are? Possibly just a notice in our readme > sighting vendor versions and or revision numbers from their VCS? > I'm not sure what all your referencing: * Who is we? * What is our distro? * Who is the vendor? * Who is the you that you're letting know?
Ok plain English time :-P When we Zikula need to add a vendor patch for a vendor library we distribute with Zikula, we Zikula need to let you know what the vendor patch is so your packagers know what to patch. How do we let you know what the correct patch is officially. Vendor patch means a patch committed to their VCS but not yet released in an official version. e.g. Zikula uses Smarty. Smarty fixes something important to us, but hasnt yet released a version that includes that fix. So we checkout revision X from their source control or file y from revision X and patch the version of Smarty we distribute. How do we let you know if we have in fact needed to do this. This particular example is fictitious but the way, but could very well happen. Drak
OK, thanks for that clarification Drak.
Recall that Fedora doesn't use bundled libraries, in part so that we can scale software maintenance across a wider group of participants. In this case, you'd likely want to notify the maintaners of both Zikula and the Smarty library to notify them of the situation and the specific patch needed.
At that time, my understanding is the Smarty maintainer would want to check the Smarty upstream for intention to release the patch. (You could provide references if desired to make this process faster.) That way we're only using patches that have buy-in from upstream -- which seems likely in the case you describe.
(And hopefully the smarty packager would add the vendor patch to our smarty package).
For me the best medium for this is bugzilla -- but it could be that communicating the needs to the zikula maintainer and letting him open the bugzilla ticket to the smarty/php/etc maintainers is the best workflow... What does ke4qq think?
-Toshio
+1 for bugzilla. That said, it's not necessarily trivial work, and would require much coordination. I'd personally urge Zikula (and any other software project) to work fervently with upstream to get the patch into a release before releasing if at all possible. (notice that this doesn't mean stopping the development branch). That said, some upstreams are slower than others about releases. But do try and understand the level of work, if 15 bundled libraries require patches, it may mean as many as 15 people may have to check with upstreams, then package, release, and so on. That assumes that the packager wants to, it could be that the packager might choose to only maintain un-patched upstream releases to minimize maintenance burden. All of this can factor in to delay or it being well night impossible for an update to get pushed (as seen with the recent almost 6 month delay for 1.2.x versions delay, and requiring an exception from FESCo)
On 25 May 2010 03:54, David Nalley david@gnsa.us wrote:
+1 for bugzilla. That said, it's not necessarily trivial work, and would require much coordination. I'd personally urge Zikula (and any other software project) to work fervently with upstream to get the patch into a release before releasing if at all possible. (notice that this doesn't mean stopping the development branch). That said, some upstreams are slower than others about releases. But do try and understand the level of work, if 15 bundled libraries require patches, it may mean as many as 15 people may have to check with upstreams, then package, release, and so on. That assumes that the packager wants to, it could be that the packager might choose to only maintain un-patched upstream releases to minimize maintenance burden. All of this can factor in to delay or it being well night impossible for an update to get pushed (as seen with the recent almost 6 month delay for 1.2.x versions delay, and requiring an exception from FESCo)
Hey David,
I dont know why, but I think my direct emails to you must have been getting lost... I mailed you so many times before! Great to see you. Full ACK, you have no disagreement with me on these topics :)
Overall however, what is the state of 1.2.x now because as far as I am concerned we have solved all the issues. I also updated https://fedorahosted.org/fesco/ticket/375
Regards,
2010/5/24 Drak drak@zikula.org:
On 25 May 2010 03:54, David Nalley david@gnsa.us wrote:
+1 for bugzilla. That said, it's not necessarily trivial work, and would require much coordination. I'd personally urge Zikula (and any other software project) to work fervently with upstream to get the patch into a release before releasing if at all possible. (notice that this doesn't mean stopping the development branch). That said, some upstreams are slower than others about releases. But do try and understand the level of work, if 15 bundled libraries require patches, it may mean as many as 15 people may have to check with upstreams, then package, release, and so on. That assumes that the packager wants to, it could be that the packager might choose to only maintain un-patched upstream releases to minimize maintenance burden. All of this can factor in to delay or it being well night impossible for an update to get pushed (as seen with the recent almost 6 month delay for 1.2.x versions delay, and requiring an exception from FESCo)
Hey David, I dont know why, but I think my direct emails to you must have been getting lost... I mailed you so many times before! Great to see you. Full ACK, you have no disagreement with me on these topics :) Overall however, what is the state of 1.2.x now because as far as I am concerned we have solved all the issues. I also updated https://fedorahosted.org/fesco/ticket/375 Regards, Drak
1.2.3 is packaged and has been pushed to the updates-testing repository. I am trying to hold out for some external testing before pushing it to updates, but if it doesn't come soon, may do so anyway.
On 25 May 2010 04:00, David Nalley david.nalley@fedoraproject.org wrote:
2010/5/24 Drak drak@zikula.org: 1.2.3 is packaged and has been pushed to the updates-testing repository. I am trying to hold out for some external testing before pushing it to updates, but if it doesn't come soon, may do so anyway.
Ok, awesome :)
If there is anything that can make life more easy for you guys let me know, for example we could automate the build process in our continuous integration server to auto build out the packages according to Fedora's specification. That way it might be a bit easier for ya'll to audit and vet.
Drak
logistics@lists.fedoraproject.org
-
David Nalley -
David Nalley -
Drak -
Hiemanshu Sharma -
Mateo TibaPalacios -
Paul W. Frields -
Robyn Bergeron -
Toshio Kuratomi