5:05 a.m.
I give up...
(to resume: moto4lin doesn't work well with +2 drives, but SVN version does)
This is what I got on bugzilla:
"I'm sorry, but this is still an upstream issue. The fact that the upstream
author has a patch that fixes this problem but is not releasing it in an
official release does not make this a packaging issues, IMHO.
It is my position that bugs like this need to be fixed by an upstream
release,
particularly in cases like this. Because upstream fixes help all
distributions,
and Fedora, effectively, forking it does not.
I don't believe it is Fedora's place to be tracking svn. Does the upstream
maintainer have a good reason for not having a real release that fixes this?
If someone from fedora-devel thinks this should be tracking SVN, they should
re-open this and take assignment on the bug."
Thanks anyway.
--
.:: www.preguntaslinux.org :: moderador ::.
5:52 a.m.
dragonauta x writes:
I give up...
(to resume: moto4lin doesn't work well with +2 drives, but SVN version does)
This is what I got on bugzilla:
"I'm sorry, but this is still an upstream issue. The fact that the upstream
author has a patch that fixes this problem but is not releasing it in an
official release does not make this a packaging issues, IMHO.
It is my position that bugs like this need to be fixed by an upstream
release,
particularly in cases like this. Because upstream fixes help all
distributions,
and Fedora, effectively, forking it does not.
I don't believe it is Fedora's place to be tracking svn. Does the upstream
maintainer have a good reason for not having a real release that fixes this?
If someone from fedora-devel thinks this should be tracking SVN, they should
re-open this and take assignment on the bug."
Thanks anyway.
I don't get it. Where's the problem? Upstream refuses to produce an
update?
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
9:10 a.m.
On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote:
I don't get it. Where's the problem? Upstream refuses to
produce an
update?
Upstream seems reluctant to release new versions, the last one is from
March 2005. I can't tell if they refuse to do it or simply haven't been
asked, though. IMO, the Fedora package maintainer should at least
investigate if backporting the fix is feasible.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
10:23 a.m.
On Fri, 2007-12-28 at 16:10 +0100, Nils Philippsen wrote:
On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote:
> I don't get it. Where's the problem? Upstream refuses to produce an
> update?
Upstream seems reluctant to release new versions, the last one is from
March 2005.
A failure to release an update in almost 3 years is usually the result
of one of three things:
1) The software is finally stable and doesn't need frequent updates.
2) The maintainer has no faith in the software in general.
3) The maintainer doesn't actually want (or is pathologically unable) to
maintain the software.
Since the first obviously isn't true, one of the latter two must be. In
my mind both of those cases are valid reasons for eventually orphaning
the package if the situation doesn't improve.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
3:16 p.m.
On Fri, 2007-12-28 at 16:10 +0100, Nils Philippsen wrote:
> On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote:
>
> > I don't get it. Where's the problem? Upstream refuses to produce an
> > update?
>
> Upstream seems reluctant to release new versions, the last one is from
> March 2005.
A failure to release an update in almost 3 years is usually the result
of one of three things:
1) The software is finally stable and doesn't need frequent updates.
2) The maintainer has no faith in the software in general.
3) The maintainer doesn't actually want (or is pathologically unable) to
maintain the software.
Since the first obviously isn't true, one of the latter two must be. In
my mind both of those cases are valid reasons for eventually orphaning
the package if the situation doesn't improve.
I for one see no reason why a well-tested SVN version can't be packaged.
See gnubg. The stable release is defined as a particular SVN version, not
a particular tarball. Some upstreams, like xmoto's for example, will
provide you the SVN version numbers to allow you to take two check outs
and create your own patches. I did this for xmoto 0.3.3, so we could fix
a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of
functionality.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
3:38 p.m.
Dnia 2007-12-28, o godz. 15:16:03 "Jon Ciesla" <limb(a)jcomserv.net>
napisał(a):
Some upstreams, like xmoto's for example, will
provide you the SVN version numbers to allow you to take two check outs
and create your own patches. I did this for xmoto 0.3.3, so we could fix
a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of
functionality.
Now imagine you have 100 bugs, there's never going to be 0.3.4
and 0.4 or 1.0
is going to come out in 2011. Even with an upstream giving you commit numbers,
you'll end up either:
- having 100 patches, half of them not SVN patches (but merged from a few
dependant commits),
- really forking and releasing your own tarball (not a packager's business),
- releasing a snapshot and dealing with its new bugs, which could end up
causing more trouble for the users and you.
With one simple (one small patch published by upstream) bug and active
upstream development of a "stable" branch, there's no problem. Moto4lin
could
be different, however. If its maintainers don't want to deal with patching it
or releasing snapshots, they do it for a reason.
Lam
3:45 p.m.
Dnia 2007-12-28, o godz. 15:16:03 "Jon Ciesla"
<limb(a)jcomserv.net>
napisaÅ(a):
> Some upstreams, like xmoto's for example, will
> provide you the SVN version numbers to allow you to take two check outs
> and create your own patches. I did this for xmoto 0.3.3, so we could
> fix
> a bug fixed in 0.3.4 before 0.3.4 came out. Bought us several weeks of
> functionality.
Now imagine you have 100 bugs, there's never going to be 0.3.4 and 0.4 or
1.0
is going to come out in 2011. Even with an upstream giving you commit
numbers,
you'll end up either:
- having 100 patches, half of them not SVN patches (but merged from a few
dependant commits),
- really forking and releasing your own tarball (not a packager's
business),
- releasing a snapshot and dealing with its new bugs, which could end up
causing more trouble for the users and you.
With one simple (one small patch published by upstream) bug and active
upstream development of a "stable" branch, there's no problem. Moto4lin
could
be different, however. If its maintainers don't want to deal with patching
it
or releasing snapshots, they do it for a reason.
Agreed, with this case it was two showstopper bugs, and they were still
working on a few new features for the next release, so it made sense. It
may or may not work here, but it's worth looking into. Even with
dependant commits, svn diff x:y could be a big help.
Lam
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
novus ordo absurdum
11:17 a.m.
On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote:
dragonauta x writes:
> I give up...
> (to resume: moto4lin doesn't work well with +2 drives, but SVN version does)
> This is what I got on bugzilla:
> "I'm sorry, but this is still an upstream issue. The fact that the
upstream
> author has a patch that fixes this problem but is not releasing it in an
> official release does not make this a packaging issues, IMHO.
>
> It is my position that bugs like this need to be fixed by an upstream
> release,
> particularly in cases like this. Because upstream fixes help all
> distributions,
> and Fedora, effectively, forking it does not.
>
> I don't believe it is Fedora's place to be tracking svn. Does the
upstream
> maintainer have a good reason for not having a real release that fixes this?
>
> If someone from fedora-devel thinks this should be tracking SVN, they should
> re-open this and take assignment on the bug."
>
> Thanks anyway.
I don't get it. Where's the problem? Upstream refuses to produce an
update?
Please don't oversimplify the issue. Just because upstream refuses, for
whatever reason, to come up with a release doesn't mean packagers should
refuse to package up a copy from VCS, particularly if it's been made
reproducible. Upstream has their own agenda and packagers carry a bigger
responsibility to the PACKAGE'S USERS. If the packager doesn't want to
do the extra work, then say so, and hopefully a comaintainer will
package it. But don't refuse it on principle.
The fact remains that there is a fix and upstream isn't making it
difficult at all to package. So why drag one's feet? If this were a
trivial patch (cosmetic), I'd understand the reluctance. But bugs which
break normal functionality I consider pretty up there.
--
Richi Plana
12:19 p.m.
Richi Plana writes:
On Fri, 2007-12-28 at 11:52 +0000, Andrew Haley wrote:
> dragonauta x writes:
> > I give up...
> > (to resume: moto4lin doesn't work well with +2 drives,
but SVN
> > version does)
> > This is what I got on bugzilla:
> > "I'm sorry, but this is still an upstream issue.
The fact
> > that the upstream author has a patch that fixes this problem
> > but is not releasing it in an official release does not make
> > this a packaging issues, IMHO.
> >
> > It is my position that bugs like this need to be fixed by an
> > upstream release, particularly in cases like this. Because
> > upstream fixes help all distributions, and Fedora,
> > effectively, forking it does not.
> >
> > I don't believe it is Fedora's place to be tracking svn. Does
> > the upstream maintainer have a good reason for not having a
> > real release that fixes this?
> >
> > If someone from fedora-devel thinks this should be tracking
> > SVN, they should re-open this and take assignment on the bug."
> >
> > Thanks anyway.
>
> I don't get it. Where's the problem? Upstream refuses to
> produce an update?
Please don't oversimplify the issue. Just because upstream refuses, for
whatever reason, to come up with a release doesn't mean packagers should
refuse to package up a copy from VCS, particularly if it's been made
reproducible.
I dunno. That sounds like a very good reason to me. Otherwise Fedora
would have to maintain a fork, which really isn't a good plan. It
isn't the job of a Fedora packager to maintain a fork.
If it's really so important to get this fixed, it needs to be fixed
across all distros. If there hasn't been a release for three years,
the package needs to be orphaned or someone who cares needs to start
maintaining a fork that can become the new upstream.
Upstream has their own agenda and packagers carry a bigger
responsibility to the PACKAGE'S USERS. If the packager doesn't want
to do the extra work, then say so, and hopefully a comaintainer
will package it. But don't refuse it on principle.
The fact remains that there is a fix and upstream isn't making
it
difficult at all to package. So why drag one's feet? If this were a
trivial patch (cosmetic), I'd understand the reluctance. But bugs
which break normal functionality I consider pretty up there.
I think we need to know why upstream is not packaging this fix in an
official release.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
12:34 p.m.
On Fri, 2007-12-28 at 18:19 +0000, Andrew Haley wrote:
I think we need to know why upstream is not packaging this fix in an
official release.
And I think it's probably the package maintainers job to find this
out ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
12:43 p.m.
Andrew Haley wrote:
> Please don't oversimplify the issue. Just because upstream
refuses, for
> whatever reason, to come up with a release doesn't mean packagers should
> refuse to package up a copy from VCS, particularly if it's been made
> reproducible.
I dunno. That sounds like a very good reason to me. Otherwise Fedora
would have to maintain a fork, which really isn't a good plan. It
isn't the job of a Fedora packager to maintain a fork.
If it's really so important to get this fixed, it needs to be fixed
across all distros. If there hasn't been a release for three years,
the package needs to be orphaned or someone who cares needs to start
maintaining a fork that can become the new upstream.
Why would upstream's existing sourceforge svn trunk be considered a new
fork?
--
Les Mikesell
lesmikesell(a)gmail.com
4:51 p.m.
dragonauta x <dragonauta.x <at> gmail.com> writes:
This is what I got on bugzilla:"I'm sorry, but this is still
an upstream
issue. The fact that the upstream author has a patch that fixes this problem
but is not releasing it in anofficial release does not make this a packaging
issues, IMHO.
IMHO it does. Maintainers: In a situation like this, if there's a patch from
upstream, please apply it!
If upstream only provides the fix in the form of a commit to SVN trunk, first
try applying the diff from SVN to the release, sometimes it just works. If it
doesn't apply, you have 3 options:
1. Try asking upstream (nicely) for a backport which applies to the stable
release. Keep in mind though that the upstream author(s) might be very busy and
do(es) not necessarily have the time to do backports.
2. Backport the patch yourself. This is often fairly easy.
3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real
release for ages, this may well be the best option, however be careful, as the
snapshot may also include regressions. It is usually a good idea to run the
idea by upstream first, as for one they are likely to know about any
regressions in the snapshots, and secondly, unfortunately some uncooperative
upstreams may also get upset and hostile if you package snapshots (whereas
others will even ask you to do just that, also depending on the state the code
in SVN is in, thus the importance of asking).
If you have a ready-to-apply patch or if you use options 1 or 2, please don't
patch the source tarball directly, use Patch0 (or Patch1, ...). If you use
option 3, make your SVN checkout the new Source0.
It is my position that bugs like this need to be fixed by an
upstream
release, particularly in cases like this. Because upstream fixes help all
distributions,and Fedora, effectively, forking it does not.
First of all: It isn't "forking" to backport a patch which is already in the
upstream SVN trunk. It's even less "forking" to package something straight
from
the SVN trunk.
Secondly: Other distros will eventually get the fix because it's already in SVN
trunk, so it will be in the next release. And if they want it first, they can
backport it, just as you can.
Notwithstanding all the above: It would of course be better for all distros,
including Fedora, if there was a new stable release with the fix. However, as I
said above, upstream may be too busy to do backports, and unwilling to release
from the current state of the SVN trunk for reasons unrelated to the fix
(regressions etc.). So sometimes, backporting is really the only option.
I don't believe it is Fedora's place to be tracking svn.
Then backport the fix.
If it doesn't apply to the stable version and you can't get it to apply, let us
see the BZ report and the fix and I'm sure one of us will be able to help you.
Does the upstream maintainer have a good reason for not having a real
release
that fixes this?
You have to ask this question to upstream themselves. :-)
Kevin Kofler
12:59 a.m.
Kevin Kofler wrote:
dragonauta x <dragonauta.x <at> gmail.com> writes:
> This is what I got on bugzilla:"I'm sorry, but this is still an upstream
> issue. The fact that the upstream author has a patch that fixes this problem
> but is not releasing it in anofficial release does not make this a packaging
> issues, IMHO.
IMHO it does. Maintainers: In a situation like this, if there's a patch from
upstream, please apply it!
If upstream only provides the fix in the form of a commit to SVN trunk, first
try applying the diff from SVN to the release, sometimes it just works. If it
doesn't apply, you have 3 options:
1. Try asking upstream (nicely) for a backport which applies to the stable
release. Keep in mind though that the upstream author(s) might be very busy and
do(es) not necessarily have the time to do backports.
2. Backport the patch yourself. This is often fairly easy.
3. Upgrade to a SVN snapshot wholesale. If upstream hasn't done any real
release for ages, this may well be the best option, however be careful, as the
snapshot may also include regressions. It is usually a good idea to run the
idea by upstream first, as for one they are likely to know about any
regressions in the snapshots, and secondly, unfortunately some uncooperative
upstreams may also get upset and hostile if you package snapshots (whereas
others will even ask you to do just that, also depending on the state the code
in SVN is in, thus the importance of asking).
If you have a ready-to-apply patch or if you use options 1 or 2, please don't
patch the source tarball directly, use Patch0 (or Patch1, ...). If you use
option 3, make your SVN checkout the new Source0.
You forgot 4) Ask on this list if there is anyone who is willing to
backport upstream's fix for you.
> It is my position that bugs like this need to be fixed by an
upstream
> release, particularly in cases like this. Because upstream fixes help all
> distributions,and Fedora, effectively, forking it does not.
First of all: It isn't "forking" to backport a patch which is already in
the
upstream SVN trunk. It's even less "forking" to package something straight
from
the SVN trunk.
Secondly: Other distros will eventually get the fix because it's already in SVN
trunk, so it will be in the next release. And if they want it first, they can
backport it, just as you can.
Notwithstanding all the above: It would of course be better for all distros,
including Fedora, if there was a new stable release with the fix. However, as I
said above, upstream may be too busy to do backports, and unwilling to release
from the current state of the SVN trunk for reasons unrelated to the fix
(regressions etc.). So sometimes, backporting is really the only option.
> I don't believe it is Fedora's place to be tracking svn.
Then backport the fix.
If it doesn't apply to the stable version and you can't get it to apply, let us
see the BZ report and the fix and I'm sure one of us will be able to help you.
Ah yes, thats what I meant with option 4.
Regards,
Hans
5989
days inactive
5990
days old
12 comments
10 participants
participants (10)
-
Andrew Haley -
dragonauta x -
Hans de Goede -
Ignacio Vazquez-Abrams -
Jon Ciesla -
Kevin Kofler -
Les Mikesell -
Leszek Matok -
Nils Philippsen -
Richi Plana