10:12 a.m.
Hi,
Another more political issue in Fedora Core and Extras interaction that
probably needs to be addressed/discussed, probably closely related to
Michael Tiemanns "drafts":
Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of
releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and
leave them as "known bugs" for the current FC-release.
In the end, this results into bugs remaining unaddressed in older
releases (e.g. FC1), while they are fixed in upstream releases (e.g.
FC2).
In some cases such "known bugs" have an impact on Fedora Extras (Bug
fixed in FC2, present in FC1).
Some examples:
* In some cases such "known bugs" prevent Fedora Extras to supply
packages for downstream releases, because the officially released
packages the Fedora Extras packages are based on are broken.
E.g. "missing shared libs in ghostview"
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175
break gsview for FC1
https://bugzilla.fedora.us/show_bug.cgi?id=1940
and "nonfunctional freeglut stub" in FC1
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107228
renders it almost impossible to ship any glut based package for FC1 in
general.
* Sometimes such "known bugs" require Fedora Extras packagers to apply
work-arounds to be able to support downstream distributions.
E.g. the bison.rpm from FC1 lacks a dependency on m4:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108655
which causes packagers to resort to either resort to build-require
"bison m4" or "byacc" instead of "bison".
Question: How shall this kind of problems be dealt with?
IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED
RAWHIDE" when ever reasonable/applicable and to officially upgrade the
package instead.
Alternatively, it could also be worth to consider handing over such a
package to "Fedora Extra" for "interim band-aid packages".
Note: I am not talking about RH to provide general "upstream" updates,
nor I am talking about "Fedora Legacy" or "Fedora Alternaives".
I am only referring to cases where RH's current update policy
blocks/handicaps/limits usability of a release, because someone had
decided a bug fix would not be relevant for public release.
Ralf
10:23 a.m.
E.g. the bison.rpm from FC1 lacks a dependency on m4:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108655
which causes packagers to resort to either resort to build-require
"bison m4" or "byacc" instead of "bison".
Your buildsystem should always require m4 until our source base is cleaned
up to support this fine-grained level of requirements. Until now it is not.
IMO, it would be best if RH/FC would prefer not to close bugs as
"CLOSED
RAWHIDE" when ever reasonable/applicable and to officially upgrade the
package instead.
Alternatively, it could also be worth to consider handing over such a
package to "Fedora Extra" for "interim band-aid packages".
Note: I am not talking about RH to provide general "upstream" updates,
nor I am talking about "Fedora Legacy" or "Fedora Alternaives".
I am only referring to cases where RH's current update policy
blocks/handicaps/limits usability of a release, because someone had
decided a bug fix would not be relevant for public release.
If the problems are not critical enough to create an update, we fix them
in a development cycle and they go into the next release. I am against
leaving bugzillas open for such items, as this is just growing the number
of open bugs.
In general we already deal with the same issues where many packages have
dependencies to other packages and that is clearly visible if you look
at our development stream.
So if the problems don't warrant an update, I think the only solution is
to add workarounds into the other packages. In the case of buildrequires
I think it would be bad to create additional rpms instead of adding m4
to the list of essential rpm packages.
greetings,
Florian La Roche
10:26 a.m.
On Tue, Aug 03, 2004 at 05:23:48PM +0200, Florian La Roche wrote:
> which causes packagers to resort to either resort to
build-require
> "bison m4" or "byacc" instead of "bison".
Your buildsystem should always require m4 until our source base is cleaned
up to support this fine-grained level of requirements. Until now it is not.
I've applied a few buildreq fixes from Steve Grubb, hopefully I'll get his
next set soon and can carry on merging them.
So if the problems don't warrant an update, I think the only
solution is
to add workarounds into the other packages. In the case of buildrequires
I think it would be bad to create additional rpms instead of adding m4
to the list of essential rpm packages.
Or reopen/file a new bug when it does become important.
11:03 a.m.
On Tue, 2004-08-03 at 17:26, Alan Cox wrote:
Or reopen/file a new bug when it does become important.
bugzilla.redhat.com doesn't allow external (non-redhat.com) reporters to
reopen such PRs.
All one could do is to comment on a PR and politely ask the package
maintainer to look into a the PR again, hoping he will listen :-/
Ralf
1:10 p.m.
On Tue, 03 Aug 2004 18:03:15 +0200, Ralf Corsepius wrote:
On Tue, 2004-08-03 at 17:26, Alan Cox wrote:
> Or reopen/file a new bug when it does become important.
Who decides when it becomes important? Not seldomly, a single bug
reporter considers an issue as major bug. For instance, I don't consider
missing dependencies (e.g. fam-devel missing dependency on
libselinux-devel) a must-fix bug which should result in an immediate
update release. It's nice and helpful to get an update for such bugs,
though, especially when building a single extra package for multiple
target platforms (with CVS and automated builds you would laugh about
issues like that).
bugzilla.redhat.com doesn't allow external (non-redhat.com)
reporters to
reopen such PRs.
I believe there are external people who can do that. But reopening a
report doesn't force the developer to change his mind. If there's
disagreement about whether to release an update, you would only step on
his feet and increase the amount of bugzilla spam. There ought to be
other ways how to discuss and resolve issues, and someone from a higher
instance of Fedora technical leadership people should be involved and
make sure the Fedora Project doesn't suck in this area.
All one could do is to comment on a PR and politely ask the package
maintainer to look into a the PR again, hoping he will listen :-/
True. With a close(r) relationship between Fedora Extras and Fedora Core,
it should not happen that easy-to-fix bugs in Fedora Core don't result in
an update when extra packages need it. Or vice versa (when Core updates
are not coordinated with Extras and break extra packages).
11:13 p.m.
On Tue, 2004-08-03 at 20:10, Michael Schwendt wrote:
On Tue, 03 Aug 2004 18:03:15 +0200, Ralf Corsepius wrote:
> On Tue, 2004-08-03 at 17:26, Alan Cox wrote:
>
> > Or reopen/file a new bug when it does become important.
Who decides when it becomes important? Not seldomly, a single bug
reporter considers an issue as major bug. For instance, I don't consider
missing dependencies (e.g. fam-devel missing dependency on
libselinux-devel) a must-fix bug which should result in an immediate
update release. It's nice and helpful to get an update for such bugs,
though, especially when building a single extra package for multiple
target platforms (with CVS and automated builds you would laugh about
issues like that).
Fully agreed, this is a problem longing for a solution.
In general, I would expect "persons who trip such bugs" tending to ask
for immediate update ("I absolutely need a fix now") and "RH
packagers"
to play it low or avoid fixing such bugs ("EOL; no time; RHEL has
priority").
Therefore, I could envision that in case of disagreement, such decisions
should neither be taken by the RH/FC packager nor by the FE person, but
should be delegated to a neutral, (mediation, arbitration)
jury/committee, instead.
> All one could do is to comment on a PR and politely ask the
package
> maintainer to look into a the PR again, hoping he will listen :-/
True. With a close(r) relationship between Fedora Extras and Fedora Core,
it should not happen that easy-to-fix bugs in Fedora Core don't result in
an update when extra packages need it. Or vice versa (when Core updates
are not coordinated with Extras and break extra packages).
ACK. It means putting
contributors into the role of a suppliant
depending on the grace of an individual.
Not necessarily encouraging to contributors and not necessarily an
indication for "equal rights".
Ralf
1:11 p.m.
Hi,
On Tue, 2004-08-03 at 17:03, Ralf Corsepius wrote:
On Tue, 2004-08-03 at 17:26, Alan Cox wrote:
> Or reopen/file a new bug when it does become important.
bugzilla.redhat.com doesn't allow external (non-redhat.com) reporters to
reopen such PRs.
All one could do is to comment on a PR and politely ask the package
maintainer to look into a the PR again, hoping he will listen :-/
If you really feel strongly that the fix needs to be backported, then
do re-open then bug. Just don't do it for every little tiny bug or
people will get annoyed.
If you're right, and the fix really should be released in an update the
maintainer will listen to you, especially if he/she happens to have a
tiny bit of time to spare :-) e.g
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120652
Hopefully, when we have a real process for external developers it'll
only be a matter of a developer saying "I think this should be
backported, okay if I go ahead?" and the developer at least doing a good
chunk of the work rather than stuff like this blocking on the amount of
time a given developer has available.
Cheers,
Mark.
1:17 p.m.
Hopefully, when we have a real process for external developers
it'll
only be a matter of a developer saying "I think this should be
backported, okay if I go ahead?" and the developer at least doing a good
chunk of the work rather than stuff like this blocking on the amount of
time a given developer has available.
except that for fedora the goal is(was) to ship newer versions instead
of doing complex backports, right ?
Which makes it even less work to be honest.
(ok there are exceptions, the gray area probably is releasing a 2.6
kernel for FC1)
12:52 p.m.
> which causes packagers to resort to either resort to
build-require
> "bison m4" or "byacc" instead of "bison".
This is a bug in the old bison package and it should have been re-issued as an
update IMHO. Under no case should m4 be added to a buildrequires unless that
package actually uses m4. Otherwise you muddy the real requirements for a
package.
> Your buildsystem should always require m4 until our source base
is cleaned
> up to support this fine-grained level of requirements. Until now it is not.
I disagree with this. Very few packages actually use m4. Because you have people
that need bugs fixed when no updates are provided, its pretty common for people
running an old RH system to get the latest package and build it on their system.
Therefore, the baseline has to be enforced by rpmbuild. m4 is not required by
rpmbuild.
Another thing, you have to be careful not to add too many programs to the
baseline development requirements. Otherwise you lose the tracability of what
contributes to each package. Suppose one day that a bad version of m4 was
released and m4 was a common requirement. You would not be able to trace all the
packages that might be affected.
I've applied a few buildreq fixes from Steve Grubb, hopefully
I'll get his
next set soon and can carry on merging them.
Yes, next batch is being sent. I have the full & exact buildrequires for about
220 packages. My buildsystem borrows some ideas from LFS. It can bootstrap build
a distribution from a host system like a stripped RH9. When I started this
project back in March, my buildsystem showed FC only needed 6 passes to get all
the packages build. There were many missing dependencies and circular
dependencies. It did not build to completion. I started correcting everything.
Now, my buildsystem shows 19 passes to get all packages built. It consistently
builds now.
You can look at the build dependency diagram (not the runtime dependencies) from
here: http://www.web-insights.net/dep.ps.gz I recommend KGhostview, but any ps
viewer should do. Simple packages are at the top, packages that depend on many
prerequisites are at the bottom.
Speaking of runtime dependencies. I was researching a security related bug the
other day and ran across a neat feature of bash. --rpm-requires will print out
the external programs called by a sh script. I started comparing the runtime
requirements of shell scripts versus what is stated.
For example, /sbin/grub-install. The grub package states bash & texinfo. I get
coreutils, diffutils, grep, and sed just for that one file! It would be nice if
rpmbuild scanned for shell scripts, capture the info, resolve the files to a
package, and add the packages to the runtime requirements. Its really simple.
http://www.web-insights.net/sh2rpms if you want the bash script.
-Steve Grubb
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
4:54 p.m.
On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote:
For example, /sbin/grub-install. The grub package states bash &
texinfo. I get coreutils, diffutils, grep, and sed just for that one
file! It would be nice if rpmbuild scanned for shell scripts,
capture the info, resolve the files to a package, and add the
packages to the runtime requirements. Its really simple.
http://www.web-insights.net/sh2rpms if you want the bash script.
We patch our bash package to have an --rpm-requires option to provide
just this functionality (but it isn't used).
Tim.
*/
11:23 p.m.
On Tue, Aug 03, 2004 at 10:54:12PM +0100, Tim Waugh wrote:
On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote:
> For example, /sbin/grub-install. The grub package states bash &
> texinfo. I get coreutils, diffutils, grep, and sed just for that one
> file! It would be nice if rpmbuild scanned for shell scripts,
> capture the info, resolve the files to a package, and add the
> packages to the runtime requirements. Its really simple.
> http://www.web-insights.net/sh2rpms if you want the bash script.
We patch our bash package to have an --rpm-requires option to provide
just this functionality (but it isn't used).
Nice, I didn't know this was there. What would the implications of running
this as a per interpreter find-requires at build time on shell scripts?
Paul
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
1:14 a.m.
On Wed, 4 Aug 2004, Paul Nasrat wrote:
On Tue, Aug 03, 2004 at 10:54:12PM +0100, Tim Waugh wrote:
> On Tue, Aug 03, 2004 at 10:52:37AM -0700, Steve G wrote:
>
> > For example, /sbin/grub-install. The grub package states bash &
> > texinfo. I get coreutils, diffutils, grep, and sed just for that one
> > file! It would be nice if rpmbuild scanned for shell scripts,
> > capture the info, resolve the files to a package, and add the
> > packages to the runtime requirements. Its really simple.
> > http://www.web-insights.net/sh2rpms if you want the bash script.
>
> We patch our bash package to have an --rpm-requires option to provide
> just this functionality (but it isn't used).
Nice, I didn't know this was there. What would the implications of running
this as a per interpreter find-requires at build time on shell scripts?
It's nice but only as an aid to a packager, it has too many problems to be
usable in automated manner. For example try it on the little script
below... Dunno how hard it would be to fix.
---
#!/bin/sh
dostuff()
{
echo "stuff..."
}
$grep="grep"
echo `ls`
$grep /etc/modules.conf alias && $echo
dostuff
---
- Panu -
9:49 a.m.
New subject: bash rpm-requires
Hi,
It's nice but only as an aid to a packager, it has too many
problems to be
usable in automated manner. For example try it on the little script
below... Dunno how hard it would be to fix.
Right. Your script shows 2 of 3 problems that I see.
1) It doesn't expand variables when they are used as a command. The downside to
this is that some commands are missed. The fallback is that you depend on the
maintainer to have stated the requirements correctly. So in reality, nothing is
gained or lost.
2) It can't tell that a function call is internal. This can be a problem. If the
function name is the same as a real command, it will resolve to a wrong
requirement.
But it has another problem that I see...
3) It has problems with a script that does an unconditional exec. For example,
many tk scripts start off a shell script and do an exec of wish. From that point
forward, everything in the script is tk/tcl. This could be handled in the sh2rpms
script by prescanning and seeing if a known interpreter is reported. If so,
reduce the requirements to that interpreter.
In terms of usability, though, I think it is still usable. I would encourage the
Red Hat team to continue this patch and refine it. Because of this patch, I have
also written scripts that scan shell scripts (that admins are likely to run) for
incomplete paths. e.g. grep instead of /bin/grep.
Another interesting bash feature that maintainers might want to know about is the
-n option, which does a syntax check of a script. I've written a script that
searches the hard drive for shell scripts and uses -n on them. It falls victim to
the same problem as #3 above, but can handle the problem by further examination
of the file in question. On my RH9 system, this script shows that there are
problems in:
/usr/lib/rpm/check-prereqs
/usr/bin/pcdindex
/usr/bin/cvsversion
/usr/bin/kde-build
Try them yourself. It would be interesting to have rpmbuild run 'sh -n' against
all packaged shell scripts, weed out interpreter calls like wish or guile, and
report them to stderr...but don't break the build.
Hope this spurs some creativity...
-Steve Grubb
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
10:10 a.m.
New subject: bash rpm-requires
On Wed, Aug 04, 2004 at 07:49:04AM -0700, Steve G wrote:
In terms of usability, though, I think it is still usable. I would
encourage the Red Hat team to continue this patch and refine
it. Because of this patch, I have also written scripts that scan
shell scripts (that admins are likely to run) for incomplete
paths. e.g. grep instead of /bin/grep.
I think it was only really intended for scanning %post/%postun-type
scriptlets, which are generally very easy to parse. I think at one
point there was even a hook in rpm to make use of it -- whether that
is still around but disabled, or gone altogether, I don't know.
Tim.
*/
12:02 p.m.
New subject: bash rpm-requires
I think it was only really intended for scanning %post/%postun-type
scriptlets, which are generally very easy to parse.
I can think of several ways to use that facility besides just those scriptlets.
If the ability to resolve internal function calls vs external executables was
solid, we could easily augment rpmbuild.
I have updated sh2rpms so that it works around problem #3 I mentioned before. If
it finds a known interpreter, it simply makes the interpreter its requirement.
You can get the updated copy from:
http://www.web-insights.net/sh2rpms
I also uploaded the script that searches for shell script problems. It has been
corrected to handle interpreters by skipping over those files. Give it a try like
so:
./find_sh4errors /usr/bin
Download from here:
http://www.web-insights.net/find_sh4errors
It could also easily be included into rpmbuild where you pass it the build root
directory. Happy bug hunting...
I think at one point there was even a hook in rpm to make use of it --
whether
that is still around but disabled, or gone altogether, I don't know.
I thought it was just a matter of clipping into a macro. I haven't taken that
step yet, but I thought it was easy to do from various things I've read.
-Steve Grubb
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
12:22 p.m.
New subject: bash rpm-requires
On Wed, 4 Aug 2004 10:02:06 -0700 (PDT), Steve G <linux_4ever(a)yahoo.com> wrote:
./sh2rpms /etc/X11/xinit/xinitrc
netscape cannot be resolved
Now the question is do you really want rpmbuild to automatically pull in
requirements on executables that are used solely in if [ ] shell logic?
I really don't think the --rpm-requires parsing is robust enough to
automate this
for all possible completely valid shellscript logic that a script on
the system would need to employ. This is surely a useful tool to some
extent to review for QA and bugreporting.
But I don't think i would trust it to automate building requires.
-jef"find_sh4errors reports /etc/X11/init/ as fine by the way"spaleta
12:43 p.m.
New subject: bash rpm-requires
Now the question is do you really want rpmbuild to automatically pull
in
requirements on executables that are used solely in if [ ] shell logic?
The requirements should be augmented, not replaced by. Using your example on my
RH9 machine:
./sh2rpms /etc/X11/xinit/xinitrc 2>/dev/null
grep-2.5.1-7.8
XFree86-4.3.0-2.90.55
XFree86-tools-4.3.0-2.90.55
Ok, there's 3 packages named. The package in question is:
rpm -qf /etc/X11/xinit/xinitrc
xinitrc-3.32-1
So lets see what the requirements are:
rpmquery --requires xinitrc-3.32-1
/bin/bash
/bin/bash
/bin/sh
/bin/sh
XFree86
config(xinitrc) = 3.32-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
switchdesk >= 3.7
Looks like we have found 2 additional/supplemental requirements not stated.
I really don't think the --rpm-requires parsing is robust enough
to
automate this for all possible completely valid shellscript logic that
a script on the system would need to employ.
I think I said that. Problem #2 needs tightening up to truely trust it.
This is surely a useful tool to some extent to review for QA and
bugreporting.
Right. In the absence of being able to automate it, I hope some people use it to
better document the runtime requirements.
-Steve Grubb
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
1:44 p.m.
New subject: bash rpm-requires
On Wed, 4 Aug 2004 10:43:23 -0700 (PDT), Steve G <linux_4ever(a)yahoo.com> wrote:
>Now the question is do you really want rpmbuild to automatically
pull in
>requirements on executables that are used solely in if [ ] shell logic?
The requirements should be augmented, not replaced by. Using your example on my
RH9 machine:
Cough..err um... who cares about what the rh9 machine is giving.
Run it against the fc3test1 with develop tree updates or fc2 and you get the
netscape showing up, when it should not be. Is this a fault of the patch to bash
or the fault of sh2rpms incorrectly seeing netscape inside the if [ -x
] check as being a hard requirement, i've no idea, either way no so
good.
But lets take a look at those extra deps you say exist.
do they really exists as hard deps? Or are that executables buried inside
if statement logic. Once you are dealing with if statements can you
know algorithmicly if
executables called inside those statements are really required? and
non executable files whose existance is queried really required? And
your script didnt notice the call to sed at all resulting in a true
from the if that grep is used in. Script logic parsing gets
complicated pretty fast, im not sure how accurate this tool is.
I can see it giving a lot of false positive regarding any executable
used in an optional if clauses. Netscape and xterm would be the
examples here for fc2 and fc3t1 systems i used. AND it seems it gives
false negatives regarding calls buried in complicated quoted arguments
or command pipes like sed in the xinitrc example in fc2 and fc3t1.
The false positives arent so much of a problem, but i would be
concerned about people relying heavily on this tool assuming it
catches all actual requires without any false negatives.
The question is, if this tool gives both false positives and false
negatives, is this tool really worth using? If i have to read through
xinitrc to catch the call to sed anyways, using a --rpm-requires
doesn't save me anytime. If anything if I use this tool, i will be
tempted to believe it and not do the full read-through, that's not
helpful.
Why doesnt exec fvwm2 or exec twm get seen but netscape's call does
on my fc2 and fc3t1 systems? That's disturbing. If its not rebust
enough to understand executables as arguments to builtin functions or
even created functions like what we see in initscripts thats a huge
problem, its doing nothing more than finding the easiest requires to
find by reading.
-jef"is it worth actually filing a bug report about sed being a hard
requirement for xinitrc?"spaleta
1:08 p.m.
On Tue, 03 Aug 2004 17:12:10 +0200, Ralf Corsepius wrote:
Some examples:
* In some cases such "known bugs" prevent Fedora Extras to supply
packages for downstream releases, because the officially released
packages the Fedora Extras packages are based on are broken.
E.g. "missing shared libs in ghostview"
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175
break gsview for FC1
https://bugzilla.fedora.us/show_bug.cgi?id=1940
Though, in this case the extra package should not have been released for
FC1. The explicit dependency on a shared library soname should not have
passed QA for FC1.
IMO, it would be best if RH/FC would prefer not to close bugs as
"CLOSED
RAWHIDE" when ever reasonable/applicable and to officially upgrade the
package instead.
Alternatively, it could also be worth to consider handing over such a
package to "Fedora Extra" for "interim band-aid packages".
No. That would make it a Fedora Core bug-fix update and would not be an
extra package. Updates to Fedora Core must not be released in Fedora
Extras.
12:51 a.m.
On Tue, 2004-08-03 at 20:08, Michael Schwendt wrote:
On Tue, 03 Aug 2004 17:12:10 +0200, Ralf Corsepius wrote:
> Some examples:
>
> * In some cases such "known bugs" prevent Fedora Extras to supply
> packages for downstream releases, because the officially released
> packages the Fedora Extras packages are based on are broken.
>
> E.g. "missing shared libs in ghostview"
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88175
> break gsview for FC1
> https://bugzilla.fedora.us/show_bug.cgi?id=1940
Though, in this case the extra package should not have been released for
FC1. The explicit dependency on a shared library soname should not have
passed QA for FC1.
ACK, in this case, FE's QA has failed.
Nevertheless, it has revealed a known problem ("CLOSED RAWHIDE") in
FC1's ghostscript, on which the RH packager formerly had decided that it
were not important enough to the public to justify a public update.
IMO, both are separate problems:
* The former is a failure that should not have happened, however such
failures are inevitable and for sure will happen again. Here, FE is
challenged to improve it's QA.
* The latter is a different kind of problem:
- Individual perception of the "importance on a bug" is subjective.
- "Importance of a bug" is subject to change over time.
Before FE, there basically were 2 parties: RH + individual users.
RH could afford to close bugs "CLOSED RAWHIDE" when a bug did not affect
the "masses", while individual users having been affected by such a bug
could individually pickup "unofficial fixes" from upstream/rawhide.
With FE, the situation has changed: There now are 3 parties: RH/FC + FE
+ individual users.
1) One can argue that FE is just another arbitrary "individual user".
OK, no problem at all. Then FE has to be allowed to apply the
work-around individual users had to apply before FE: Replace packages
from FC by packages from upstream/rawhide.
=> FE's policy has to be changed
2) FE is a privileged "3rd party" closely interacting with RH/FC.
In this case FE has to be enabled to influence decisions having been
taken by RH/FC.
=> RH/FC has to implement formal means for FE to do so.
Another approach would be FE to ignore such problems and not to try
working around such bugs.
=> FE can not provide any packages that are affected by such bugs.
> IMO, it would be best if RH/FC would prefer not to close bugs as
"CLOSED
> RAWHIDE" when ever reasonable/applicable and to officially upgrade the
> package instead.
> Alternatively, it could also be worth to consider handing over such a
> package to "Fedora Extra" for "interim band-aid packages".
No. That would make it a Fedora Core bug-fix update and would not be an
extra package. Updates to Fedora Core must not be released in Fedora
Extras.
That's fedora.us's current policy. I feel excluding changes in FE's
policy at this point in time would be a mistake (cf. above).
Having read Michael Tiemann's draft and struggling with "CLOSED RAWHIDE"
bugs as a contributor to FE (and as an "ordinary user"), I see a need
for changes in both FC's and FE's policies.
Ralf
3:43 p.m.
On Tue, 3 Aug 2004, Ralf Corsepius wrote:
Sometimes, RH developers close PRs as "CLOSED RAWHIDE"
instead of
releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and
leave them as "known bugs" for the current FC-release.
Ralf,
It's a good issue that has come up before. Users sometimes want to stick
with their installed releases while still getting fixes for the bugs
important to them.
The problem all comes down to limited resources and priorities. There are
only so many hours in the day, and given the goals of the Fedora Core
distribution (which include being on the leading edge of open source
technology), it is generally more important to spend those hours improving
the development tree than backporting fixes for old releases.
There are probably ways that things can be improved without hurting future
development, so by all means stick with the issue! You're already on your
way to finding out what the constraints are and where the solution may be.
Best,
-- Elliot
The daring is in the doing
http://people.redhat.com/sopwith/
5:23 a.m.
On Tue, 2004-08-03 at 22:43, Elliot Lee wrote:
On Tue, 3 Aug 2004, Ralf Corsepius wrote:
> Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of
> releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and
> leave them as "known bugs" for the current FC-release.
Ralf,
It's a good issue that has come up before. Users sometimes want to stick
with their installed releases while still getting fixes for the bugs
important to them.
Exactly. It's exactly what I do. Though I've set up
testing machines
with FC2, I will be sticking with FC1 on "production machines" for the
foreseeable future.
The problem all comes down to limited resources and priorities.
There
are
only so many hours in the day, and given the goals of the Fedora Core
distribution (which include being on the leading edge of open source
technology), it is generally more important to spend those hours improving
the development tree than backporting fixes for old releases.
You're probably
aware that the objectives of individual contributors to
FE don't necessarily match with those of RH/FC.
This implies
* FE can only work if RH/FC's interests sufficiently intersect with
those of contributors.
* FE and RH/FC interaction can only work if both parties are willing to
compromise and are willing to allocate resources.
There are probably ways that things can be improved without hurting
future
development, so by all means stick with the issue! You're already on your
way to finding out what the constraints are and where the solution may be.
As I
already tried to outline, I can image several technical approaches:
1) In exceptional/special cases, Fedora.us/FE should be permitted to
replace packages from FC if they break other FE packages or are unusable
in general.
2) RH/FC commits their packagers to listen to FE's package update
demands and to benevolently consider to release bug-fix updates once
such a demand pops up.
3) Don't change anything. In this case, FE should not release packages
that trip bugs which can not be worked around without very little
effort.
Though others might find 3) acceptable, I am opposed to it, because it
is little helpful to users and contributors, and, in cases where
work-arounds are possible, it means playing with symptoms and spoiling
upstream development with hacks.
Technically, I don't see much difference between 1) and 2):
* Both require coordination and mutual attention between RH/FC and FE/FE
contributors.
* 1) would require less resources on RH/FC's side (It's a form of
outsourcing to the net).
* In singular cases 1) could make FE packages unusable for RHEL. If
that's an objective of RH, 1) is no alternative from RH's point of view.
* 2) would be less risky, because a RH packager can be presumed to be
more familiar with a package than an external contributor/volunteer.
* 2) would require RH to be _willing_ to allocate resources.
In an ideal world, 1) and 2) could be implemented as exchange of a
little communication. However, I don't expect this to work in all cases.
Worse, I'd expect both approaches to cause "bad blood" between both
groups in cases of disagreement.
Therefore, I fear it will be inevitable to implement formal procedures
for "update requests". Technically, "update requests" probably could
be
implemented via bugzilla triggering a machinery inside of RH.
To solve "conflicting cases", a jury/committee/tribunal could be
implemented.
Another topic that has not been discussed in this thread yet, is the
impact of a distribution's life time on such "update requests".
"Fedora Legacy", you might answer now, but ... I never understood how
this is supposed to work.
Ralf
6:26 a.m.
On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote:
1) In exceptional/special cases, Fedora.us/FE should be permitted to
replace packages from FC if they break other FE packages or are unusable
in general.
Which effectively would fork FC maintenance. Not good. Users running FC
would get different Core packages than users of FE. Different packages
which may or may not result in different run-time behaviour, for
instance, or break compilation of dependences. You cannot define what
those "exceptional/special cases" are before you run into them. It would
result in a case by case decision finding process. Also keep in mind
that FC's bug-fix update policy is to prefer upstream version upgrades
over backports. And if a bug in FC can be fixed and the community or
[extras] developer community would benefit from a fix, there ought to be
a bug fix release in the obvious place: FC Updates and nowhere else.
2) RH/FC commits their packagers to listen to FE's package
update
demands and to benevolently consider to release bug-fix updates once
such a demand pops up.
Most likely also with contributors preparing and testing the fix. And
remember, we're discussing general bug fixes, not attempts at massive
version upgrades which would turn a stable FC release into FC Development.
The interesting bit is when a fix is available in Rawhide, who takes
responsibility for pushing the fix as an update to an old FC version?
This is where community QA must kick in and do the necessary regression
testing, too.
7:36 a.m.
On Wed, 2004-08-04 at 13:26, Michael Schwendt wrote:
On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius wrote:
> 1) In exceptional/special cases, Fedora.us/FE should be permitted to
> replace packages from FC if they break other FE packages or are unusable
> in general.
Which effectively would fork FC maintenance.
It would not. FE would pickup packages
from rawhide ("CLOSED RAWHIDE")
rsp. repackage them. Of cause N-V-R need to be carefully adjusted to not
break upstream upgrades.
Not good. Users running FC
would get different Core packages than users of FE.
Yes, but this is supposed to
not having any effect.
Core users will be using the broken package, which is supposed not to
have severe impacts on them (Otherwise RH/FC should have updated them),
while FE users will get "fixed packages".
Different packages
which may or may not result in different run-time behaviour, for
instance, or break compilation of dependences. You cannot define what
those "exceptional/special cases" are before you run into them.
Exactly.
I am talking about case-by-case decisions "on demand" and not
about "card blanche"'ing FE to repackage rawhide packages as part of FE.
It would
result in a case by case decision finding process. Also keep in mind
that FC's bug-fix update policy is to prefer upstream version upgrades
over backports.
User want functionality and want packages, they don't care about FC's
policies nor RH/FC's objectives.
It's simply as that: Users having to experience that packages are not
buildable for older releases and FE therefore not being able to provide
them because RH/FC and FE are not able to implement a fix, despite a fix
is known, gives a pretty poor picture about FC/FE and RH.
And if a bug in FC can be fixed and the community or
[extras] developer community would benefit from a fix, there ought to be
a bug fix release in the obvious place: FC Updates and nowhere else.
> 2) RH/FC commits their packagers to listen to FE's package update
> demands and to benevolently consider to release bug-fix updates once
> such a demand pops up.
Most likely also with contributors preparing and testing the fix.
You seem to be missing one essential point:
The cases I am referring to, already have been fixed by _RH developers_,
therefore I am presuming they already performed at lease some testing,
rsp. these changes are so small that the risk can be estimated.
If not, these bugs should not have been "CLOSED RAWHIDE".
And
remember, we're discussing general bug fixes, not attempts at massive
version upgrades which would turn a stable FC release into FC Development.
Right, I
am only referring to "CLOSED RAWHIDE" bugs that are supposed to
have been fixed at some point in time between 2 official releases and
which have an actual impact on FE.
The interesting bit is when a fix is available in Rawhide, who takes
responsibility for pushing the fix as an update to an old FC version?
This is where community QA must kick in and do the necessary regression
testing, too.
Cf. above.
Ralf
BTW: With FC1 soon reaching its EOL, we might soon have the situation
that packages might get fixed as part of Legacy after FC1's EOL, while
there is no way to fix such bugs during FC1's life-time.
Bizarre, isn't it?
8:39 a.m.
New subject: Fedora Legacy (was: Re: Fedora Extras vs. CLOSED RAWHIDE)
On Wed, 04 Aug 2004 14:36:47 +0200, Ralf Corsepius wrote:
BTW: With FC1 soon reaching its EOL, we might soon have the
situation
that packages might get fixed as part of Legacy after FC1's EOL, while
there is no way to fix such bugs during FC1's life-time.
Bizarre, isn't it?
You assume that Fedora Legacy actually will do more than just security
fixes. For that to become reality, much (!) more community commitment
would be necessary [*]. And agreement on fixing something which has been
broken for many months.
Also an interesting topic, when FC1 is passed on to Fedora Legacy, extra
packages start to depend on Fedora Legacy updates. When Fedora Extras (or
fedora.us) phase out support for legacy distributions has not been decided
on yet either. There's a tendency that package maintainers prefer moving
forward rather than maintaining packages for FC1 when FC3 is current.
--
[*] Plus infrastructural changes, such as a bugzilla system with ACLs,
Vendorsec access for a privileged security team, and a more efficient
package submission and release process which results in timely updates.
8:39 a.m.
On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius <rc040203(a)freenet.de> wrote:
As I already tried to outline, I can image several technical
approaches:
1) In exceptional/special cases, Fedora.us/FE should be permitted to
replace packages from FC if they break other FE packages or are unusable
in general.
I'm confused... if a package is already in FE how can a lack of an FC
update break it?
Any package published in FE should be building against the active FC
release(s) to even get published. So I'm trying real hard to see how
a lack of an update in FC is going to break already published FE
packages. And generally unusable packages that have no dependent
packages should be thrown out of Core completely to save space in
Core.
But i think everyone will agree that everyone will disagree about what
'generally useless' means in general.
Now if you want to talk fixing an FC package to make it easier to get
a new FE package published... i counter with maybe the only real way
forward is for FE maintainers to be tracking the development branch as
much as possible for new FE packages, instead of shoehorning the
packages to work with an active FC release.
2) RH/FC commits their packagers to listen to FE's package update
demands and to benevolently consider to release bug-fix updates once
such a demand pops up.
And what happens when FE package1 demands an FC update.. and that FC
update breaks the hacks in FE package2, package3 and packagee5? Do we
have the different FE package mantainers duke it out? This issue will
always be grey. Certainly a if an FE package needs new update to fix a
security issue, working that out would be important.
But anything else, is grey. I for one would be not so happy to see
60megs of updates to download on my desktop system just for
buildrequires bugfixes.
3) Don't change anything. In this case, FE should not release
packages
that trip bugs which can not be worked around without very little
effort.
I'm totally fine with this. I think long-term I think everything for a
'release' would run smoother if FE packagers were tracking the
development tree as much as possible.
And update to the active FC when needed(and my definition of needed is
very strictly security related) or when painless.
Though others might find 3) acceptable, I am opposed to it, because
it
is little helpful to users and contributors, and, in cases where
work-arounds are possible, it means playing with symptoms and spoiling
upstream development with hacks.
its only spoiling if you consider the current FC release as a living
breathing squirming thing to be toyed with. If you see the current FC
release more like the shedded husk of a cicada
or the molted skin of a snake, then you start thinking its not really
best to focus new efforts there. If FE packagers do their updates
against devel branch, and FE 'releases' are synced with FC 'releases'
we can perhaps avoid making work for ourselves by working against the
timescales and branch tagging of core.
-jef"instant gratification seems to be an expectation with FE"spaleta
5:52 p.m.
On Wed, 4 Aug 2004 09:39:47 -0400, Jeff Spaleta wrote:
On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius
<rc040203(a)freenet.xx> wrote:
> As I already tried to outline, I can image several technical approaches:
>
> 1) In exceptional/special cases, Fedora.us/FE should be permitted to
> replace packages from FC if they break other FE packages or are unusable
> in general.
I'm confused... if a package is already in FE how can a lack of an FC
update break it?
You gave the answer further below. --> It can't. It can only make a new FE
package release impossible. Either because the FE package can't be built
due to insufficient dependencies, or because the FC package contains
problems which [seem to] affect only the FE package. perl-DateManip as an
old example which was fixed with an unofficial update which would not be
possible with a strict policy about what FE is permitted to contain.
There's one exception, however. A FE package included in (or moved into)
FC. If the package release in FC is not upgraded for bug fixes, the FE
packages for older release of the distribution cannot be upgraded
either. Because that would break the upgrade path. One example is k3b,
where fedora.us waited for FC2. ALSA in FC1 is an example, where all of a
sudden, FC2 development didn't move beyond 1.0.3a despite all the problems
with ALSA. To release driver updates and upstream fixes for several bugs
and problems, fedora.us upgraded FC1 ALSA to 1.0.4. Otherwise the ALSA
roll-out for FC1 would have stopped unexpectedly. No further early testing
of ALSA drivers and apps in FC1 would have been possible.
--
And, of course, kernel updates break extra repositories temporarily, too,
as users of add-on kernel modules cannot update their kernel before
updated module packages are available.
9:57 p.m.
On Wed, 2004-08-04 at 15:39, Jeff Spaleta wrote:
On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> As I already tried to outline, I can image several technical approaches:
>
> 1) In exceptional/special cases, Fedora.us/FE should be permitted to
> replace packages from FC if they break other FE packages or are unusable
> in general.
I'm confused... if a package is already in FE how can a lack of an FC
update break it?
I should have formulated more carefully.
There exist packages in Fedora.US/FE, which can be build for FC2, but
fail to build for FC1, because building these packages for FC1 trigger
"known bugs" in FC1, which RH has fixed some time between FC1 and FC2,
but did not consider important enough to justify releasing a package
update.
Any package published in FE should be building against the active FC
release(s) to even get published. So I'm trying real hard to see how
a lack of an update in FC is going to break already published FE
packages.
The problem is: RH/FC not having fixed "known bugs" prevents
Fedora.US/FE from publishing packages for FC1.
What might confuse you is one case (gsview), where Fedora.US/FE already
had released a (broken) package for FC1, which now has to be withdrawn
because it can't be properly rebuild for FC1.
Now if you want to talk fixing an FC package to make it easier to
get
a new FE package published...
I am talking about fixing an FC package to make it possible at all to
get a new FE package for FC < FC(CURRENT) published.
> 2) RH/FC commits their packagers to listen to FE's package
update
> demands and to benevolently consider to release bug-fix updates once
> such a demand pops up.
And what happens when FE package1 demands an FC update.. and that FC
update breaks the hacks in FE package2, package3 and packagee5? Do we
have the different FE package mantainers duke it out? This issue will
always be grey.
Right, this situation can't completely excluded, but if
developers don't
work too careless, the risk is pretty small.
Certainly a if an FE package needs new update to fix a
security issue, working that out would be important.
But anything else, is grey. I for one would be not so happy to see
60megs of updates to download on my desktop system just for
buildrequires bugfixes.
You don't develop on packages for FC1, I presume?
Most cases I am referring to, are cases developers encounter if their
work is based on one the affected packages.
> 3) Don't change anything. In this case, FE should not
release packages
> that trip bugs which can not be worked around without very little
> effort.
I'm totally fine with this.
I am not - It prevents Fedora.US/FE from releasing packages, while other
3rd parties are able to ship them (They replace the RH supplied FC1
packages).
IMO, this substantially weakens Fedora.US/FE and therefore causes damage
the Fedora Project as a whole in longer terms.
Ralf
11:08 p.m.
On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius <rc040203(a)freenet.de> wrote:
The problem is: RH/FC not having fixed "known bugs"
prevents
Fedora.US/FE from publishing packages for FC1.
I'm personally not all that thrilled at having FE packagers target
publishing any new packages in current or old FC releases. I think new
FE publishing should target FC development and FE 'releases' should
freeze out on the same timescales as FC instead of obsessing over
trying to continue to base work on an FC release that is 1 or 2 month
away from being officially EOLd. The more FE packages that get
introduced against the development tree... the less post-release
problems with Core we will have with FE long term. Continuing to add
NEW extras against an FC release is how we break upgrade paths when
Core consumes new functionality in development that was in the past in
extras.
If Core+Extras ends up looking like a rolling release like i use to
see with ximian desktop, I'm going to puke my guts out. I hate the
rolling release model with rpm packages. You sneak in a packaging fix
thats meant to fix something else, don't do enough QA and every user
ends up having to try to do a package rollbacks for several packages.
No thanks. I'll chew my own arm off first.
I am talking about fixing an FC package to make it possible at all
to
get a new FE package for FC < FC(CURRENT) published.
And i think this has to be case by case...its grey. Im going to be
wicked pissed, if I as a user have to download megs of updates just to
fix a packaging error that could have been worked around in the new FE
package by the packagers.
Right, this situation can't completely excluded, but if
developers don't
work too careless, the risk is pretty small.
Thats pure optimizism on your part. If people were happy and shiny and
communicated well we wouldn't have 90% of the griping we have on this
list, and certaintly not this thread. Waving a magic policy wand
deeming that people will change in this regard is extremely wishful
thinking.
You don't develop on packages for FC1, I presume?
FC1 is at best a month away from EOL (though im none too happy that
there hasnt been an actual FIRM date about FC1 EOL but ill save that
for another debate) if anyone is still considering building new
packages against FC1 at this point, its seems a foolhardy goal.
I am not - It prevents Fedora.US/FE from releasing packages, while
other
3rd parties are able to ship them (They replace the RH supplied FC1
packages).
3rd party packagers are NOT going away. This is NOT a competition with
what 3rd party packagers can and can not do. The issues with non-free
and non-US packages that Fedora refuses to ship is a big enough space
to keep 3rd party packagers in business as a popular place for users
to get things. Fedora can't compete with 3rd parties when it comes to
instant user gratification. We shouldn't pretend that it can. What we
are talking about here, corner cases invovling packaging bugs is not
going to make or break the issue of 3rd party repos. I am much more
concerned about long term issues associated with a growing fedora
development model so that community developers are focused on looking
ahead instead of looking backwards.
IMO, this substantially weakens Fedora.US/FE and therefore causes
damage
the Fedora Project as a whole in longer terms.
I think 6 month EOL's for Core make any argument about long term
projhect damage a little thin. Legacy with its current manpower and
infrastructure can't handle legacy issues with FE packages. Michael
has already said that there is reluctance currently for fedora.us
package maintainers to continue to support packages in a legacy
situations. Fedora Core's timescale are extremely aggressive and push
people to move to the next release very quickly. I think the
development model as a whole does better long term, if new Fedora
Extras development focuses continually on the Core development tree,
instead of dragging attention backwards to suppliment Core releases
that have already been frozen out. If new packages can be built
painlessly for Core releases that are still active, great. If not,I
think Fedora Alternatives as defined in the terminology page fills the
corner cases you are concerned about in situations where Core
developers don't want to push an update.
-jef
12:57 a.m.
On Thu, 2004-08-05 at 06:08, Jeff Spaleta wrote:
On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> The problem is: RH/FC not having fixed "known bugs" prevents
> Fedora.US/FE from publishing packages for FC1.
I'm personally not all that thrilled at having FE packagers target
publishing any new packages in current or old FC releases. I think new
FE publishing should target FC development and FE 'releases' should
freeze out on the same timescales as FC instead of obsessing over
trying to continue to base work on an FC release that is 1 or 2 month
away from being officially EOLd.
That's not how Fedora.US works and not how it
should work, IMO.
> I am talking about fixing an FC package to make it possible at
all to
> get a new FE package for FC < FC(CURRENT) published.
And i think this has to be case by case...its grey. Im going to be
wicked pissed, if I as a user have to download megs of updates just to
fix a packaging error that could have been worked around in the new FE
package by the packagers.
Have a look at were the Megs come from you had downloaded
in past
updates for RH/FC: kernels, OpenOffice, kernels, glibc, kernels, gcc,
kernels, php, kernels, sometimes KDE, kernels, sometimes Gnome ...
These by far outweigh "a couple of small selected bug-fix updates".
> Right, this situation can't completely excluded, but if
developers don't
> work too careless, the risk is pretty small.
Thats pure optimizism on your part.
No, realism - Remember, I am taking about
decisions on a case-by-case
basis. Therefore, in most cases the consequences of such updates can be
realistically estimated. In cases the consequences can't be seriously
estimated, such update-requests should be rejected.
If you now have a look at the packages RH/FC *did* update:
The consequences of these updates can hardly be estimated.
> You don't develop on packages for FC1, I presume?
FC1 is at best a month away from EOL (though im none too happy that
there hasnt been an actual FIRM date about FC1 EOL but ill save that
for another debate) if anyone is still considering building new
packages against FC1 at this point, its seems a foolhardy goal.
Face the facts:
People still are using FC1 and will continue to use it.
And if Fedora Legacy should work out (Which I am very hesitant to
believe), people will continue to use FC1 for quite a while.
If Fedora Legacy should not work out and if FC+FE should not improve,
I'd expect people to switch away from Fedora.
> IMO, this substantially weakens Fedora.US/FE and therefore
causes damage
> the Fedora Project as a whole in longer terms.
I think 6 month EOL's for Core make any argument about long term
projhect damage a little thin.
cf. above.
Legacy with its current manpower and infrastructure
IMO, the
main issue is not manpower, but inefficiency, "friction" and
lack of attractiveness.
Get Fedora.US a much simplified infrastructure (Build system, package
submission procedure, more automated QA, reliable servers, etc.), then
run Fedora.US as a "rolling distribution", which takes over "maintenance
of discontinued releases", have it contain attractive packages ...
It's the way all 3rd parties roll their FC-AddOn repositories.
Ralf
--
Registered Linux User #26 http://counter.li.org
11:44 a.m.
On Thu, 05 Aug 2004 07:57:27 +0200, Ralf Corsepius <rc040203(a)freenet.de> wrote:
That's not how Fedora.US works and not how it should work, IMO.
What fedora.us can do/should do as a 3rd party repository outside the
fence line... and what Fedora Extras can do/should do/will do cant be
assumed to be exactly the same thing. If we want tighter integration
that means tighter integration of how things get built and spat out
for consumption. You avoid conflicts in process by adopting a
coherent development strategy. Focusing policy and political efforts
to trickle fixes back down to existing Core releases so a new Extra
packages can get built for these older releases drags efforts to fix
things in development. Only so many manhours in the day and all that.
Its one thing to have a discussion with a package maintainer about
going back and fixing a package, its quite another to have a review
panel contradict a package mantainers decision to not push an update.
And I say, leave these case by case decisions as their judgement call.
I really don't think its wise to set up an arbitration panel with
authority of this sort of thing, set up to second guess every
unpopular update decision that crops up. Anyone who wants that sort
of position in the process, is a policy vulture, and we should avoid
creating positions of authority like that with the expressed purpose
of second-guessing maintainer decisions.
If you can't convince a maintainer to release an update package via
communication on the public lists or in bugzilla via empassioned
logical reasoning or submitted patches, I don't think its worth the
concerned political effort to arbitrate it. Just aim for the
development tree and the future, instead of arbitrating the past.
> Thats pure optimizism on your part.
No, realism - Remember, I am taking about decisions on a case-by-case
basis.
You also suggested building a political structure above the actual
maintainers to force them to do things they have already decided
against or have made it a low priorization in terms of their effort
and time. Let me strongly suggest that building structures like that
that rely on authority to review and contradict decisions that
individual maintainers should be discussing among themselves is a
bad-blood generator. My point is, maintainers of packages are
competent enough to make these decisions as they crop up. You might
not be excited about the fact that their decisions so far have not
been what you wanted, but its the maintainers decision. I have no
problem with continuing to leave the decision to produce a known fix
just to fix build issues for new packages to the discretion of each
package maintainer, without review or mandates from a review board.
You said it yourself interests conflict between packagers. I expect
them to, I expect those interest conflicts to get worse as more people
from the community contribute. And by worse i mean between community
contributors and not between a redhat serf toiling away for the
corporate interests and a community member.
Face the facts: People still are using FC1 and will continue to use
it.
And if Fedora Legacy should work out (Which I am very hesitant to
believe), people will continue to use FC1 for quite a while.
People still use rhl6.2. I'm not denying that people still use FC1.
What I am trying to point out is the development process for Core has
certain timelines already laid down, and those timelines have nothing
to do with how long the userbase finds FC1 useful. Just saying that
people want new packages for their fc1 systems doesn't make it a
worthwhile to prioritize thier creation in the scope of Fedora
development. I am facing facts, the life time of Core is so short and
development so aggressive that if new Fedora Extras packagers focus on
existing Core releases they are going to burn manhours that will be
worth far more in the long run if spent working on issues against the
Core development tree. Only so many hours in the day and all that.
Everyone can agree that having new Extras packages appear against the
Core development tree, and having Extras and Core maintainers working
things out in that tree is of interest to everyone. I want to make
sure the process encourages people working on common interests as a
priority.Fedora is already in deep conflict with the desire of
portions of the userbase with the timelines chosen for FC, and i think
its folly for Fedora Extras development to pander to desire for the
userbase to stretch out the usefulness of pre-existing Core releases.
Here's my take on conflict resolution regarding new FE packages:
New packages built against deps in Core development, trickle them down
to existing releases if painless. If not painless have a discussion
with the core package maintainers about pushing fixes for existing
Core releases. If that discussion doesn't end in a fix... the issue is
dead.. and you use Fedora Alternatives to roll replacement for Core
packages that potentially break the upgrade path for users who want
the new packages.
This process encourages:
*as much new package development against the devel tree
*discussion on a case-by-case basis on how to introduce new packages
for existing
releases of core
*allows for the existance of an alternative set of replacement
packages if the fedora extra maintainer wants to do the work, at the
cost of potentially breaking upgrade paths for users of those new
packages. Users choice, new packages for an older Core release that
break upgrade paths, or they wait and get the new packages that work
with the next Core release.
If Fedora Legacy should not work out and if FC+FE should not improve,
I'd expect people to switch away from Fedora.
Indeed, I personally encourage people to take a serious look at
debian, if they want to have a system where they don't want to have to
do a full operating system upgrade/flush every six months.
It's the way all 3rd parties roll their FC-AddOn repositories.
Third parties are free to do what they want. But I'll tell you
this.... i was an avid ximian desktop fan as a 3rd party 'repository'
in the past. And that experience taught the rolling release model is a
fragile untenable solution for a rpm package based distribution.
I think ive repeated my points atleast 3 times now, so I'll be
refraining from posting anymore on this thread.
-jef"mental wheels spinning and turning out circles of logic"spaleta
12:35 p.m.
On Thu, 5 Aug 2004 12:44:13 -0400, Jeff Spaleta wrote:
Here's my take on conflict resolution regarding new FE packages:
New packages built against deps in Core development, trickle them down
to existing releases if painless. If not painless have a discussion
with the core package maintainers about pushing fixes for existing
Core releases. If that discussion doesn't end in a fix... the issue is
dead.. and you use Fedora Alternatives to roll replacement for Core
packages that potentially break the upgrade path for users who want
the new packages.
Fedora Alternatives doesn't exist yet unless fedora.us agreed on reopening
the "patches" repository (albeit with a different name) which contained
unofficial upgrade packages for Red Hat Linux and Fedora Core and anything
that depends on them.
--
P.S. If memory serves correctly, the description of Fedora Alternatives on
the Fedora Project "Terminology" page has been updated to be more
detailed.
1:25 p.m.
On Thu, 5 Aug 2004 19:35:33 +0200, Michael Schwendt
<fedora(a)wir-sind-cool.org> wrote:
Fedora Alternatives doesn't exist yet unless fedora.us agreed on
reopening
the "patches" repository (albeit with a different name) which contained
unofficial upgrade packages for Red Hat Linux and Fedora Core and anything
that depends on them.
Cough.. technically Fedora Extras doesn't actually exist yet either.
I'm trying to make a distinction between what we have now.. with
fedora.us with a distinctly seperate 3rd party development process
from core, and what we are suppose to have inside the Fedora project
officially. If people want to discuss what fedora.us can do or change
in the near term fine, but i thought this thread was as aimed at
mythical Red Hat managed 'Fedora Extras' I see no reason to ignore FA
as a solution to problems with FE. FA is in the master plan, if Red
Hat isn't serious about providing the infrastrcture for FA as well as
FE then remove FA from the skeleton plan and I'll stop pointing to it.
P.S. If memory serves correctly, the description of Fedora
Alternatives on
the Fedora Project "Terminology" page has been updated to be more
detailed.
You mean updated somewhere else and the description on the page isn't
representitive of the latest thinking? I'd call the current definition
on the page...verbose..but not necessarily detailed. Tiemann had
Alternatives in his Collections straw man, but I don't think we can
call Tiemann's drug induced vision of the future the official
delusionary worldview yet.
-jef"no really this is my last post to the thread... i swear"spaleta
2:29 p.m.
On Thu, 5 Aug 2004 14:25:05 -0400, Jeff Spaleta wrote:
> Fedora Alternatives doesn't exist yet unless fedora.us
agreed on reopening
> the "patches" repository (albeit with a different name) which contained
> unofficial upgrade packages for Red Hat Linux and Fedora Core and anything
> that depends on them.
Cough.. technically Fedora Extras doesn't actually exist yet either.
I'm trying to make a distinction between what we have now.. with
fedora.us with a distinctly seperate 3rd party development process
from core, and what we are suppose to have inside the Fedora project
officially. If people want to discuss what fedora.us can do or change
in the near term fine, but i thought this thread was as aimed at
mythical Red Hat managed 'Fedora Extras'
Dead end. The original posting examines what we have now and raises
questions on how such/similar issues will be dealt with in the future.
There's nothing wrong about an opinion poll. The Fedora Project is without
Fedora Extras for almost a year. It is not encouraging when even purely
theoretical discussions don't move us forward. The point of discussions
like this is also to give potential contributors and package maintainers a
perspective of what FE (within the Fedora Project) will be like and what
will be possible with FE. We can continue to run fedora.us as just another
3rd party repository with more strict rules on what will be included,
ignoring the announcement of its merger with the Red Hat Linux
Project. Alternatively, we can adhere to the goals and policies of Fedora
Extras sooner than later, tying it closer to Fedora Core and bridging the
period till Fedora Extras comes alive with its official infrastructure,
technical committee and stuff like that. When FE comes alive, you would
want to avoid discussions like this, because it would drive away community
members who would realize that running just another 3rd party repository
gives them much more flexibility and power.
I see no reason to ignore FA
as a solution to problems with FE. FA is in the master plan, if Red
Hat isn't serious about providing the infrastrcture for FA as well as
FE then remove FA from the skeleton plan and I'll stop pointing to it.
The description of FA forms not more than a fuzzy picture in my mind.
What about you? I'm certain, FA won't aim at becoming a dumping ground for
version fanatics, who want to avoid staying close to Fedora Core
Development, but who want to run leading edge software in a stable Fedora
Core release and upgrade core components to satisfy their requirements. It
would be very strange to see bug-fix upgrades of core components in FA
instead of the FC Test Updates channel. That would imply you would need to
switch to a FA collection completely (remember that FE cannot depend on
FA) if you needed or wanted a fix for a bug in FC. I've thought FA will be
for replacement packages, which provide similar, additional, or
alternative functionality of what FC can do (I spare myself many obvious
examples), or which are built with an alternative feature set or
conflicting package contents. Seeing a FA collection of (alternative?;) FC
updates would be something strange and unexpected.
1:52 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 2004-08-05 at 00:08, Jeff Spaleta wrote:
On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> The problem is: RH/FC not having fixed "known bugs" prevents
> Fedora.US/FE from publishing packages for FC1.
I'm personally not all that thrilled at having FE packagers target
publishing any new packages in current or old FC releases. I think new
FE publishing should target FC development and FE 'releases' should
freeze out on the same timescales as FC instead of obsessing over
trying to continue to base work on an FC release that is 1 or 2 month
away from being officially EOLd. The more FE packages that get
introduced against the development tree... the less post-release
problems with Core we will have with FE long term. Continuing to add
NEW extras against an FC release is how we break upgrade paths when
Core consumes new functionality in development that was in the past in
extras.
If Core+Extras ends up looking like a rolling release like i use to
see with ximian desktop, I'm going to puke my guts out. I hate the
rolling release model with rpm packages. You sneak in a packaging fix
thats meant to fix something else, don't do enough QA and every user
ends up having to try to do a package rollbacks for several packages.
No thanks. I'll chew my own arm off first.
I agree that Core shouldn't be a rolling release, but I think Extras is
currently very much a Rolling Release. And it's best if it stays that
way. As a spare time packager, I can't be constantly updating my system
so I can release a package at the same time as a new Core is released.
As a user, I want to find a package that's as close to upstream at the
time I'm looking, not one that was released when the distro came out.
BTW -- My problem with Ximian Desktop as a rolling release was that it
was too interdependent. One bad library takes ten other packages with
it. With the current policy (That Ralf is saying is too strict) of not
allowing Extras to replace Core, I think rolling releases for Extras
makes sense. If massive interdependencies end up in Extras I think they
should be moved to Core (from Michael Tiemann's strawman:
* preference for packages that maximize scope of Fedora Extras
* preference for packages that satisfy most dependencies)
[My main reason for believing KDE should stay in Core as I don't use it
myself.]
> You don't develop on packages for FC1, I presume?
FC1 is at best a month away from EOL (though im none too happy that
there hasnt been an actual FIRM date about FC1 EOL but ill save that
for another debate) if anyone is still considering building new
packages against FC1 at this point, its seems a foolhardy goal.
FC1 might be near EOL, but it's still widely used. With such quick
EOL'ing, there will always be a large number of systems that are EOL but
still in use. I can't upgrade my wife's machine until October, for
instance, because she has a class that's wrapping up and I don't want to
disrupt it's stability until it's over. I don't think EOL of Core is
such a good measure of whether to continue trying to build Extras
packages for it.
Further, every FC system is a potential contributer to the project.
Someone shouldn't be excluded from contributing just because their
platform is an EOL product. Instead we should be deciding how we will
support these contributers with the goal of creating knowledgable,
trained packager who will be well versed in how to help development when
they do upgrade to a current release.
> IMO, this substantially weakens Fedora.US/FE and therefore
causes damage
> the Fedora Project as a whole in longer terms.
I think 6 month EOL's for Core make any argument about long term
projhect damage a little thin. Legacy with its current manpower and
infrastructure can't handle legacy issues with FE packages. Michael
has already said that there is reluctance currently for fedora.us
package maintainers to continue to support packages in a legacy
situations. Fedora Core's timescale are extremely aggressive and push
people to move to the next release very quickly. I think the
development model as a whole does better long term, if new Fedora
Extras development focuses continually on the Core development tree,
instead of dragging attention backwards to suppliment Core releases
that have already been frozen out. If new packages can be built
painlessly for Core releases that are still active, great.
For those developers who have the time and resources to update their
machines to the latest rawhide/test releases, I think you have a good
point about having developers look forwards instead of back.
For the volunteers who want a stably running system that they can
package foobar for and then submit to Extras because they want to give
back to the community, I don't see this is an option. For the same type
of volunteers who want to do QA of packages when the developers are only
looking towards test/rawhide, this is also an unnecessary raising of the
bar.
-Toshio
--
_______S________U________B________L________I________M________E_______
t o s h i o + t i k i - l o u n g e . c o m
GA->ME 1999
3:33 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 05 Aug 2004 14:52:17 -0400, Toshio <toshio(a)tiki-lounge.com> wrote:
I agree that Core shouldn't be a rolling release, but I think
Extras is
currently very much a Rolling Release. And it's best if it stays that
way.
I think you are wrong. I think having synced time releases of Extras
as a priority
makes a lot of issues go away. Issues that i think are vastly more
important than your desire as an end-user to get the lastest one or
two applications without having to flush your whole OS. I'd rather
work towards making it less painful to do whole Fedora Core upgrades
then to build a Fedora development process that encourages people to
focus attention to older Core releases.
Having synced Extras and Core releases.. as a priority allows for a
MUCH easier generation of other 'collections' besides Core. Read
Tiemann's strawman proposal.
I very interested in making sure the development process of Fedora
makes it easy for people to make and continue to maintain a Fedora
livecd or a Rule based mediaset or other installable 'collections' by
picking and choosing among Fedora Extras and Fedora Core packages to
bundle together as a new installable collection. If Extras is not
synced against Core releases, any sort of community maintained
'collection' is going to be burdened to deal with the different
timesscales associated with Core and Extras package development. So
that we can FINALLY get past these crappy 'whats in Core' debates and
just let Core be an arbitrary set of packages with NO inherent
distinction in the development process. Every package treated equally
in development process itself, then distilled into collections..one
collection being named Core.
The other issue synced Extras to Core will greatly help with is doing
installs and upgrades painlessly from computers without broadband,
from media sets. This is a serious issue for a lot of people, and
having point release media sets of Core+Extras as a priority that
people can use with anaconda is an absolute necessity if we want to
actually consider Fedora Extras as part of Fedora and not just another
3rd party repository. I don't want Fedora Extras to be just like it
is now...i want it to be INTEGRATED into the development process.
I want to see FC5 and FE5 come out on media sets, and have anaconda
understand how to deal with FE5 media when installing FC5 from media.
I want to see FC5.1 and FE5.1 update media sets 3 months later which
include supplimental updates and new packages as well via bittorrent.
I want to get to the point where we can seriously talk about moving
things out of Core into Extras or out of Extras into Core..without
upgrade path problems. This is only going to happen if we make
development Extras targert Core development as a PRIORITY. I want to
get to the point where Red Hat feels comfortable enough to allow some
of the RHEL cruft to drift over to Extras to make room for community
contributed things that are less RHEL relevant into Core. I don't see
that happening if Extras is continued to be treated with its own
timetables and development paths.
The keyword here is.. PRIORITY. If some Extras maintainers want to
keep rolling packages every day for FC releases to keep close to
upstream... great... more power to those individuals, if they have
they time to continue to roll updates great. BUT there is a HUGE
difference between giving invidivuals the space to do that...and
demanding ALL the packagers, community or red hat, to deal with that
sort of churn. The development tree is where integration issues
between Core packages are primarily worked out... i see no reason why
integration issues between Extras and Core package should NOT be
worked out in the same way. An integrated Extras needs to be
proactively developed and get interaction problems solved with Core
developers while Core developers are focused on the development tree.
We are talking about corner cases here, where there is some sort of
build problem associated with a bug or packaging error in an already
released FC release that would prevent the successful building of
suppliment FE packages for released Cores.
I don't want to drag to focus of development backwards as a matter of
policy. If maintainers can work the issues out for themselves and
every packager invovled with the maintaince issues can come to
agreement..great. If not, no biggie, work out the integration issues
in the development and make sure the next FC-N/FC-N package sets have
it all ironed out.
As a spare time packager, I can't be constantly updating my
system
so I can release a package at the same time as a new Core is released.
If the Fedora infrastructure that is put in place for community to use
can't address your concern about continually updating your own system,
then we are doomed regardless.
As a user, I want to find a package that's as close to upstream
at the
time I'm looking, not one that was released when the distro came out.
Instant gratification seems to be a constant demand... and an odd one.
If you want as close to upstream as possible really... update from the
development tree for
ALL the packages from the kernel right on up the stack. If its okay
to eat close to upstream Extras, you should be okay eating close to
upstream Core as well. The distinction between what is in Core and
what is in Extras needs to be come less distinct from a development
process point of view or we aren't going to make any progress on
really expanding the potential of Fedora in new directions.
FC1 might be near EOL, but it's still widely used. With such
quick
EOL'ing, there will always be a large number of systems that are EOL but
still in use. I can't upgrade my wife's machine until October, for
instance, because she has a class that's wrapping up and I don't want to
disrupt it's stability until it's over. I don't think EOL of Core is
such a good measure of whether to continue trying to build Extras
packages for it.
as a PRIORITY is what i said... if YOU as an invidual packager want to
build for FC1 great, after you have the package synced with Core
development. But if your new builds dont work becuase of a problem
with a dependancy in Core or in Extras, i don't think its appropriate
to demand that the Core or Extras packager get the necessary fix out
the door. Their personal priorities might be different than yours and
I don't think its necessarily appropriate to have them make your
interests their priority with their efforts. I think its fair to
demand everyone to make the development tree the priority for package
integration work, and any integration issues in already released Cores
is discretionary. Luckily most Core developers can be bribed with
either alcohol or a KK doughnut, so i think I have a pretty good shot
and talking my way through any corner case discussions to my benefit.
For those developers who have the time and resources to update their
machines to the latest rawhide/test releases, I think you have a good
point about having developers look forwards instead of back.
For the volunteers who want a stably running system that they can
package foobar for and then submit to Extras because they want to give
back to the community, I don't see this is an option. For the same type
of volunteers who want to do QA of packages when the developers are only
looking towards test/rawhide, this is also an unnecessary raising of the
bar.
If contributing packages to Fedora means actually running the
development tree...then we are doomed. I would hope that whatever
build infrastructure drops from the heavens for contributors to use
will not demand that all contributors be running a full fedora
development tree...nor any Fedora release at all on the systems where
they craft packages. But that being said. I don't think its enough
for people to submit a package just because it seems to sort of work
on the version of Fedora they are running. I think we must demand
more. We need maintainers, not fly-by-night chuck-it-over-the-fence
one-off packagers. People who submit packages must commit to long term
care and feeding of the package across multiple releases of Core...and
that means targetting the development tree as a priority and then
worry about existing Core releases.
-jef"bah upstream released a new version 2 hours ago...why doesnt
fedora have a new package yet...2 whole hours wasted..thats 2 hours of
gentoo compiling up in smoke"spaleta
8:16 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 2004-08-05 at 16:33, Jeff Spaleta wrote:
On Thu, 05 Aug 2004 14:52:17 -0400, Toshio
<toshio(a)tiki-lounge.com> wrote:
> I agree that Core shouldn't be a rolling release, but I think Extras is
> currently very much a Rolling Release. And it's best if it stays that
> way.
I think you are wrong. I think having synced time releases of Extras
as a priority
makes a lot of issues go away. Issues that i think are vastly more
important than your desire as an end-user to get the lastest one or
two applications without having to flush your whole OS. I'd rather
work towards making it less painful to do whole Fedora Core upgrades
then to build a Fedora development process that encourages people to
focus attention to older Core releases.
My priority is to get the most people contributing and learning what
makes good packaging. To my way of thinking, the best way to do that is
to let people package the latest one or two applications without having
to flush the whole OS. And then (the hard part) get them to stick with
them as others critique and add their knowledge of what would make those
packages better.
Having synced Extras and Core releases.. as a priority allows for a
MUCH easier generation of other 'collections' besides Core. Read
Tiemann's strawman proposal.
I've just reread the proposal and see that I was misreading it the first
time through. Fedora Extras, as the "maximal universe of packages
that:[list of requirements concerning content]" is something I agree
with. The following explanatory paragraph that says that it will be
size limited "(based on how many packages can be integration tested
within some reasonable time before and/or after the related Fedora Core
release is frozen and released)." Is the part I skipped. I think it's
a mistake to require the maximal universe of packages to be synced to
the devel tree for reasons I state later in this reply. Although I do
think it's a goal worthy of being done at the collection level.
I very interested in making sure the development process of Fedora
makes it easy for people to make and continue to maintain a Fedora
livecd or a Rule based mediaset or other installable 'collections' by
picking and choosing among Fedora Extras and Fedora Core packages to
bundle together as a new installable collection. If Extras is not
synced against Core releases, any sort of community maintained
'collection' is going to be burdened to deal with the different
timesscales associated with Core and Extras package development.
I think the syncing of packages is the least of your worries. Creating
livecd and Rule based mediasets through cherry-picking Extras strikes me
as close to impossible even with ordained syncing. This is where I
think collections have to pick up the slack rather than a global Extras
policy. Collections maintainers will have to approach packagers and
tell them they want to use the package in the collection and what the
needs of the collection are (Can you merge this change, what release
date we're targeting, etc). In return, the packagers would specify what
their needs are (I can't actively sync against the new Core, so someone
else will have to do testing and fixing in that environment, I'm also a
member of this Collection and they need to make sure that this optional
feature is always enabled.)
So
that we can FINALLY get past these crappy 'whats in Core' debates and
just let Core be an arbitrary set of packages with NO inherent
distinction in the development process. Every package treated equally
in development process itself, then distilled into collections..one
collection being named Core.
I can see that as one end product. But I wouldn't hold that it was
achievable until Red Hat's vision is stated to coincide with it.
The other issue synced Extras to Core will greatly help with is
doing
installs and upgrades painlessly from computers without broadband,
from media sets. This is a serious issue for a lot of people, and
having point release media sets of Core+Extras as a priority that
people can use with anaconda is an absolute necessity if we want to
actually consider Fedora Extras as part of Fedora and not just another
3rd party repository. I don't want Fedora Extras to be just like it
is now...i want it to be INTEGRATED into the development process.
I want to see FC5 and FE5 come out on media sets, and have anaconda
understand how to deal with FE5 media when installing FC5 from media.
I want to see FC5.1 and FE5.1 update media sets 3 months later which
include supplimental updates and new packages as well via bittorrent.
Very true. And once again, I think it needs to be handled at the
collections level. With people who want to maintain collections not
just selecting packages but working with package maintainers to
integrate packages in features and time-frame.
I want to get to the point where we can seriously talk about moving
things out of Core into Extras or out of Extras into Core..without
upgrade path problems. This is only going to happen if we make
development Extras targert Core development as a PRIORITY. I want to
get to the point where Red Hat feels comfortable enough to allow some
of the RHEL cruft to drift over to Extras to make room for community
contributed things that are less RHEL relevant into Core. I don't see
that happening if Extras is continued to be treated with its own
timetables and development paths.
I don't see it either for Extras (in my view
of Extras that is.) But I
do see it happening with a collection of a subset of Extras where
contributers have agreed that their priority is to target the Core
development schedule.
The keyword here is.. PRIORITY. If some Extras maintainers want to
keep rolling packages every day for FC releases to keep close to
upstream... great... more power to those individuals, if they have
they time to continue to roll updates great. BUT there is a HUGE
difference between giving invidivuals the space to do that...and
demanding ALL the packagers, community or red hat, to deal with that
sort of churn. The development tree is where integration issues
between Core packages are primarily worked out... i see no reason why
integration issues between Extras and Core package should NOT be
worked out in the same way. An integrated Extras needs to be
proactively developed and get interaction problems solved with Core
developers while Core developers are focused on the development tree.
We are talking about corner cases here, where there is some sort of
build problem associated with a bug or packaging error in an already
released FC release that would prevent the successful building of
suppliment FE packages for released Cores.
I don't want to drag to focus of development backwards as a matter of
policy. If maintainers can work the issues out for themselves and
every packager invovled with the maintaince issues can come to
agreement..great. If not, no biggie, work out the integration issues
in the development and make sure the next FC-N/FC-N package sets have
it all ironed out.
Sure. I can agree with the idea that integration belongs in the
devel
tree so it doesn't pull things backward. I can also agree with Ralf
that at times there's too much focus on the next release and not enough
on having things buildable on a stable release. I don't have a solution
for reconciling that part so I won't argue either point.
>As a spare time packager, I can't be constantly updating my
system
> so I can release a package at the same time as a new Core is released.
If the Fedora infrastructure that is put in place for community to use
can't address your concern about continually updating your own system,
then we are doomed regardless.
See my statements in the last two blocks for why I think targeting devel
makes this mandatory.
> As a user, I want to find a package that's as close to
upstream at the
> time I'm looking, not one that was released when the distro came out.
Instant gratification seems to be a constant demand... and an odd one.
If you want as close to upstream as possible really... update from the
development tree for
ALL the packages from the kernel right on up the stack. If its okay
to eat close to upstream Extras, you should be okay eating close to
upstream Core as well. The distinction between what is in Core and
what is in Extras needs to be come less distinct from a development
process point of view or we aren't going to make any progress on
really expanding the potential of Fedora in new directions.
Ironically, that's actually pretty close to my thoughts on what belongs
in Core vs Extras: How much harm does instant gratification get you?
Kernel, most libraries, rpm, build/language toolchains are Core because
upgrading them inappropriately will break things. Useful programs that
have tons of dependencies belong there too. Extras should be largely...
extra. If I live at the bleeding edge and it breaks, my system won't
fall apart, just that one package. (This also implies that bleeding
edge software that requires Core library updates are a no-no... which is
already Fedora Extras policy...)
Additionally, I think instant gratification is a factor that should be
used to bring new packagers into the fold.
> FC1 might be near EOL, but it's still widely used. With
such quick
> EOL'ing, there will always be a large number of systems that are EOL but
> still in use. I can't upgrade my wife's machine until October, for
> instance, because she has a class that's wrapping up and I don't want to
> disrupt it's stability until it's over. I don't think EOL of Core is
> such a good measure of whether to continue trying to build Extras
> packages for it.
as a PRIORITY is what i said...
sure. Priority I can understand...
if YOU as an invidual packager want to
build for FC1 great, after you have the package synced with Core
development.
... but I don't think a requirement to sync with Core development
is
reasonable. Forcing people to use unstable software so they can
contribute isn't why I'm packaging.
But if your new builds dont work becuase of a problem
with a dependancy in Core or in Extras, i don't think its appropriate
to demand that the Core or Extras packager get the necessary fix out
the door. Their personal priorities might be different than yours and
I don't think its necessarily appropriate to have them make your
interests their priority with their efforts. I think its fair to
demand everyone to make the development tree the priority for package
integration work, and any integration issues in already released Cores
is discretionary. Luckily most Core developers can be bribed with
either alcohol or a KK doughnut, so i think I have a pretty good shot
and talking my way through any corner case discussions to my benefit.
Right. As I said, I don't have anything constructive to add on either
side of the priority of backports front so I'm staying out of that.
> For those developers who have the time and resources to update their
> machines to the latest rawhide/test releases, I think you have a good
> point about having developers look forwards instead of back.
>
> For the volunteers who want a stably running system that they can
> package foobar for and then submit to Extras because they want to give
> back to the community, I don't see this is an option. For the same type
> of volunteers who want to do QA of packages when the developers are only
> looking towards test/rawhide, this is also an unnecessary raising of the
> bar.
If contributing packages to Fedora means actually running the
development tree...then we are doomed. I would hope that whatever
build infrastructure drops from the heavens for contributors to use
will not demand that all contributors be running a full fedora
development tree...nor any Fedora release at all on the systems where
they craft packages.
Right. But it's not just build infrastructure. It's also running and
testing the package. If it builds in the devel tree but is only tested
on a GenToo box, do we really want to clear it for inclusion? More
reasonably, there are going to be times when a package is created on a
FC-release-X box, QA'd by others on FC-release-X boxes, and the build
fails on RawHide is that grounds to exclude it?
But that being said. I don't think its enough
for people to submit a package just because it seems to sort of work
on the version of Fedora they are running. I think we must demand
more. We need maintainers, not fly-by-night chuck-it-over-the-fence
one-off packagers. People who submit packages must commit to long term
care and feeding of the package across multiple releases of Core...and
that means targetting the development tree as a priority and then
worry about existing Core releases.
I agree with the care and feeding of the package part. That's how
packagers will learn to become better. I don't necessarily agree with
targeting the devel tree. If we want to lower the bar so new packagers
can get involved, we need to make it so they can experiment with
building and testing on their system which will probably be a Core
release tree, not the devel tree. OTOH, having someone say, "This
didn't build on the latest test release, here's a patch to fix it."
would be good. On the gripping hand, what happens when someone doesn't
step forward with patches? What happens when the patches make the
package incompatible with the release the packager is running? Then
they've invested a lot of effort to create a package that isn't
maintainable by them.
-Toshio
--
_______S________U________B________L________I________M________E_______
t o s h i o + t i k i - l o u n g e . c o m
GA->ME 1999
10:04 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 05 Aug 2004 21:16:25 -0400, Toshio <toshio(a)tiki-lounge.com> wrote:
My priority is to get the most people contributing and learning what
makes good packaging. To my way of thinking, the best way to do that is
to let people package the latest one or two applications without having
to flush the whole OS. And then (the hard part) get them to stick with
them as others critique and add their knowledge of what would make those
packages better.
A fair point. Everything has trade-offs. I could live with new
packagers being encouraged to build against the latest Core release
for a window of time with an intent to sync development with help. But
I think for example encourging new contributors to target FC1 right
now is a dimishing returns situation even on the mentoring front.
Contributing is part access and part responsibility, I think that at a
minimum its appropriate to require new contributors to be targeting
new packages against the newest available Core release instead of the
oldest available as a compromise between making the process accessible
and making sure packagers are committed to taking responsibility. If
you can't be bothered to run the latests release, thats going to lead
to significant problems to your ability to maintain a Fedora package,
Although I do think it's a goal worthy of being done at the
collection level.
I still think you have a different interpretation of Tiemann's
strawman than I do. Hopefully
Tiemann finds time to read these rantings before he redrafts to clarity what
'at the collections level' means in your sentence. I'll refrain from
further twisting Tiemann's proposal for my own agenda until his
promised update next week.
I think the syncing of packages is the least of your worries.
Creating
livecd and Rule based mediasets through cherry-picking Extras strikes me
as close to impossible even with ordained syncing.
Cough... have you see the work Dirk Westfal is doing with his custom
rpm based livecd creation templates?
http://www.linux4all.de/livecd/barebone/index.htm
I should let Dirk comment on the difficult livecd issues are as he views them.
And i should let Marco comment on the difficult rule issues are as he
views them.
What limited personal communication i've had with both of them makes
me think getting Extras synced with Core helps them. My assessment of
the situation could of course be wrong, so it would be nice for them
to at least give a brief "Jef is on crack" response if I'm offbase
here.
Ironically, that's actually pretty close to my thoughts on what
belongs
in Core vs Extras: How much harm does instant gratification get you?
If its not co-ordinated with appropriate action tied to the devel
tree.. it potentially gets you a broken update path from Core release
to Core release.
.... but I don't think a requirement to sync with Core
development is
reasonable. Forcing people to use unstable software so they can
contribute isn't why I'm packaging.
Trade-offs, personal interests played off against larger interests of
the project you are contributing to. I want a balance between the two.
I'm not saying that people can't build new stuff for FC1 right now,
but I want their desire for instant gratification balanced against the
larger projects need for continued maintainence of that package for
FC2 and FC3 development that is currently on-going.
More
reasonably, there are going to be times when a package is created on a
FC-release-X box, QA'd by others on FC-release-X boxes, and the build
fails on RawHide is that grounds to exclude it?
I want people to committed to making a good faith effort to work on
issues in the development tree. I have no illusions what-so-ever that
all issues with Extras packages are going to be resolvable in a timely
manager inside development. I fear for the sanity of anyone who takes
of the challenge to maintain wine as an extra, thats going to be a
constant pain. I just want a commitment to make the effort. So no i
don't think failing to build in rawhide is a reason to exclude a
specific package from existing releases. But if the packager isn't
working to resolve the problems with the package in the development
tree... that needs to have some consequences.
-jef
12:55 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, Aug 05, 2004 at 11:04:39PM -0400, Jeff Spaleta wrote:
On Thu, 05 Aug 2004 21:16:25 -0400, Toshio
<toshio(a)tiki-lounge.com> wrote:
> My priority is to get the most people contributing and learning what
> makes good packaging. To my way of thinking, the best way to do that is
> to let people package the latest one or two applications without having
> to flush the whole OS. And then (the hard part) get them to stick with
> them as others critique and add their knowledge of what would make those
> packages better.
A fair point. Everything has trade-offs. I could live with new
packagers being encouraged to build against the latest Core release
for a window of time with an intent to sync development with help. But
I think for example encourging new contributors to target FC1 right
now is a dimishing returns situation even on the mentoring front.
Contributing is part access and part responsibility, I think that at a
minimum its appropriate to require new contributors to be targeting
new packages against the newest available Core release instead of the
oldest available as a compromise between making the process accessible
and making sure packagers are committed to taking responsibility. If
you can't be bothered to run the latests release, thats going to lead
to significant problems to your ability to maintain a Fedora package,
I'll buy that. There does have to be some commonality for mentoring to work
so requiring a recent stable Core is valid. And willingness to sync with
devel if someone's extending the help is part of the process of working as
a member of a community project.
> Although I do think it's a goal worthy of being done at the
collection level.
I still think you have a different interpretation of Tiemann's
strawman than I do. Hopefully
Tiemann finds time to read these rantings before he redrafts to clarity what
'at the collections level' means in your sentence. I'll refrain from
further twisting Tiemann's proposal for my own agenda until his
promised update next week.
I think you've got the correct interpretation (now that I've re-read it.)
I'm suggesting an alternative to part of his proposal as I think there needs
to be a space for both styles of work.
> I think the syncing of packages is the least of your worries.
Creating
> livecd and Rule based mediasets through cherry-picking Extras strikes me
> as close to impossible even with ordained syncing.
Cough... have you see the work Dirk Westfal is doing with his custom
rpm based livecd creation templates?
http://www.linux4all.de/livecd/barebone/index.htm
I should let Dirk comment on the difficult livecd issues are as he views them.
And i should let Marco comment on the difficult rule issues are as he
views them.
What limited personal communication i've had with both of them makes
me think getting Extras synced with Core helps them. My assessment of
the situation could of course be wrong, so it would be nice for them
to at least give a brief "Jef is on crack" response if I'm offbase
here.
Haven't looked. I'll take a look. The present state of the art may be
better than I think. Also note that I don't doubt that syncing with devel
will help do this, I just think it's the easiest of the problems to solve.
> Ironically, that's actually pretty close to my thoughts on
what belongs
> in Core vs Extras: How much harm does instant gratification get you?
If its not co-ordinated with appropriate action tied to the devel
tree.. it potentially gets you a broken update path from Core release
to Core release.
That coordination should be happenning whether it's synced to the devel
tree or not, yes? Are we saying this is going to be easier to achieve when
it's the Extras maintainer who's supposed to be tracking Core rather than
the Core developer who's supposed to be tracking Extras?
> .... but I don't think a requirement to sync with Core
development is
> reasonable. Forcing people to use unstable software so they can
> contribute isn't why I'm packaging.
Trade-offs, personal interests played off against larger interests of
the project you are contributing to. I want a balance between the two.
I'm not saying that people can't build new stuff for FC1 right now,
but I want their desire for instant gratification balanced against the
larger projects need for continued maintainence of that package for
FC2 and FC3 development that is currently on-going.
Yep. And I can see a need to keep moving maintenence forward.
I personally wouldn't find a requirement to build against the latest stable
release onerous. I don't know if it's a good idea or not for the project's
health, though. Maybe Fedora Legacy could take the contributions for older
releases and if we find there's more people who package for Legacy than for
recent FC we'll know we're doing something wrong.
> More
> reasonably, there are going to be times when a package is created on a
> FC-release-X box, QA'd by others on FC-release-X boxes, and the build
> fails on RawHide is that grounds to exclude it?
I want people to committed to making a good faith effort to work on
issues in the development tree. I have no illusions what-so-ever that
all issues with Extras packages are going to be resolvable in a timely
manager inside development. I fear for the sanity of anyone who takes
of the challenge to maintain wine as an extra, thats going to be a
constant pain. I just want a commitment to make the effort. So no i
don't think failing to build in rawhide is a reason to exclude a
specific package from existing releases. But if the packager isn't
working to resolve the problems with the package in the development
tree... that needs to have some consequences.
I agree with your goals here. My only idea for enforcement is to leave
behind packagers who won't work to integrate fixes that enable development
builds. A package which targets only FC1 is a different package from one
that targets only FC2/FC-devel/etc after all.
-Toshio
1:21 a.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 2004-08-05 at 22:33, Jeff Spaleta wrote:
On Thu, 05 Aug 2004 14:52:17 -0400, Toshio
<toshio(a)tiki-lounge.com> wrote:
> I agree that Core shouldn't be a rolling release, but I think Extras is
> currently very much a Rolling Release. And it's best if it stays that
> way.
I think you are wrong. I think having synced time releases of Extras
as a priority makes a lot of issues go away.
You are missing one point:
Contributors (like me) are a subset of the general user community. They
are working _with_ stable releases (FC1 and FC2), they are not working
_on_ the _next_ release of the system itself (FC3).
I.e. they develop and test contributions with current releases, hoping
"they will survive mass rebuilds for next release".
What you say means: Raise entry conditions for contributions to being "a
FC developer and beta-tester". That would exclude *huge* parts of the
user community (comprising me).
Having synced Extras and Core releases..
That's what
"mass rebuilds" and beta testing should do.
Fedora.US/Fe should rebuild every package in "Extras for FC(CURRENT)"
and notify the packagers if something goes wrong. Then release
everything that completed successfully into "Fedora Extras for
FC(Testing)".
I very interested in making sure the development process of Fedora
makes it easy for people to make and continue to maintain a Fedora
livecd or a Rule based mediaset or other installable 'collections' by
picking and choosing among Fedora Extras and Fedora Core packages to
bundle together as a new installable collection. If Extras is not
synced against Core releases, any sort of community maintained
'collection' is going to be burdened to deal with the different
timesscales associated with Core and Extras package development. So
that we can FINALLY get past these crappy 'whats in Core' debates and
just let Core be an arbitrary set of packages with NO inherent
distinction in the development process. Every package treated equally
in development process itself, then distilled into collections..one
collection being named Core.
You will not like what I am going to write now, but
IMO, this
distribution model (fixed released on CDs) has outlived itself.
Linux has become fat, distributions are becoming larger (IIRC, SuSE
currently has 7 or 8 CDs of binaries), so CDs as distribution media have
become questionable. More severe, shorter EOLs and faster update cycles
question shipping distributions on physical media as a whole.
So to me, all these "Core on how many CDs" discussions are moot, and
recall memories about times when people had complained about linux
distros "having exceeded XX floppies"
I.e. to me the essential criteria to distinguish "Core" from
"Extras"
are/should be along the lines of "maintained/controlled by Red
Hat/volunteers", "Intersects with RHEL" etc.
Ralf
6:18 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote:
I agree that Core shouldn't be a rolling release, but I think
Extras is
currently very much a Rolling Release.
Partially. Some packages are updated more frequently than others,
sometimes due to their experimental status and inclusion in the
testing/unstable trees. Some are updated when the packager thinks a new
upstream release contains interesting feature additions or important bug
fixes. Some packagers monitor upstream development closely and skip some
releases which would cause regression or upgrade problems. But the current
extra packages are provided in online repositories, so it doesn't really
matter if package foo is upgraded from 1.0.0 to 1.0.2 two months after the
release of FC2 or if a minor enhancement is added as 1.0.0-2 shortly after
it was implemented. The users of these online repositories benefit from
such updates.
In particular, all this is due to the current development model and
infrastructure. At fedora.us there's no "development" repository.
There's
no repository which follows Rawhide daily and triggers automated
mass-rebuilds of extra packages. Updates make it into the
stable/testing/unstable tree directly. With the release of FC2, one could
stop doing upgrades and only push updates into testing/unstable, which
would cause major confusion due to the chosen repository names.
Btw, there's no requirement that maintenance of FE package for FC1 is done
by the same person than development of the package for next release of FC.
And it's best if it stays that
way. As a spare time packager, I can't be constantly updating my system
so I can release a package at the same time as a new Core is released.
That will likely be necessary, unfortunately, in particular so complete
collections of FC and FE could be provided on CD/DVD for all those who
prefer not downloading large ISO images. Unless releases of FE are to be
scheduled some time after a release of FC, which wouldn't work as good
IMHO, because if FC/FE compatibility problems turned up at such a late
point, they would be more difficult to fix with FC updates, and it might
result in stop-ship problems with some FE packages.
As a user, I want to find a package that's as close to upstream
at the
time I'm looking, not one that was released when the distro came out.
I'm surprised to hear that. Many upstream projects move you to the
bleeding edge. Why would you want extra packages to be more bleeding than
Core packages. You could also follow FC Development to get closer to
upstream releases of Core packages.
9:02 p.m.
New subject: EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)
On Thu, 2004-08-05 at 19:18, Michael Schwendt wrote:
On Thu, 05 Aug 2004 14:52:17 -0400, Toshio wrote:
> I agree that Core shouldn't be a rolling release, but I think Extras is
> currently very much a Rolling Release.
Partially. Some packages are updated more frequently than others,
sometimes due to their experimental status and inclusion in the
testing/unstable trees. Some are updated when the packager thinks a new
upstream release contains interesting feature additions or important bug
fixes. Some packagers monitor upstream development closely and skip some
releases which would cause regression or upgrade problems. But the current
extra packages are provided in online repositories, so it doesn't really
matter if package foo is upgraded from 1.0.0 to 1.0.2 two months after the
release of FC2 or if a minor enhancement is added as 1.0.0-2 shortly after
it was implemented. The users of these online repositories benefit from
such updates.
True. I would expect that in an ISO image world, the people putting
together collections would be responsible for communicating with
packagers that they want to include something in a collection and what
the requirements of that would be.
The main problem I anticipate is when a collection needs to do a freeze
prior to release and the package maintainer wants to continue to update
the package. But would that really be a problem if the freeze were only
three weeks (like Core)?
In particular, all this is due to the current development model and
infrastructure. At fedora.us there's no "development" repository.
There's
no repository which follows Rawhide daily and triggers automated
mass-rebuilds of extra packages. Updates make it into the
stable/testing/unstable tree directly. With the release of FC2, one could
stop doing upgrades and only push updates into testing/unstable, which
would cause major confusion due to the chosen repository names.
Uhm... that last part confuses me :-)
Btw, there's no requirement that maintenance of FE package for
FC1 is done
by the same person than development of the package for next release of FC
7247
days inactive
7250
days old
41 comments
13 participants
participants (13)
-
Alan Cox -
Arjan van de Ven -
Elliot Lee -
Florian La Roche -
Jef Spaleta -
Mark McLoughlin -
Michael Schwendt -
Panu Matilainen -
Paul Nasrat -
Ralf Corsepius -
Steve G -
Tim Waugh -
Toshio Kuratomi