On Tue, Sep 20, 2011 at 10:21:52AM -0400, Matthias Clasen wrote:
> We've set our freezes as if we expect all major development to be done
> at that point, but we've aligned our schedules in a way that guarantees
> that (at least for GNOME) major development is still happening at the
> time of branching.
That does seem like pretty fair criticism. We should probably discuss
this for the F17 timeframe.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:
> That said, a reasonable QA would cherry-pick such "solution
> candidates" from *-testing and integrate them. Simply flooding
> maintainers "with complaint mails" about broken deps, maintainers
> believe to already have fixed doesn't help anybody. Neither the
> testers (who can't test because of these broken deps), nor the
> maintainers (who believe to have done everything possible), nor the
> users (who will end up with low-quality distros).
What the maintainers could have done is not upload a package that breaks
binary compatibility into a distribution that's attempting to stabalise
for release. Really. Don't do that.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 09/20/2011 04:37 PM, Matthew Garrett wrote:
> On Tue, Sep 20, 2011 at 04:35:16PM +0200, Ralf Corsepius wrote:
>
>> That said, a reasonable QA would cherry-pick such "solution
>> candidates" from *-testing and integrate them. Simply flooding
>> maintainers "with complaint mails" about broken deps, maintainers
>> believe to already have fixed doesn't help anybody. Neither the
>> testers (who can't test because of these broken deps), nor the
>> maintainers (who believe to have done everything possible), nor the
>> users (who will end up with low-quality distros).
>
> What the maintainers could have done is not upload a package that breaks
> binary compatibility into a distribution that's attempting to stabalise
> for release.
That's a way too simplistic view - It's simply that other processes
(upstream release cycles, upstream release processes, package
maintainer's time slots, etc.) are not in sync with Fedora's cycles and
that Fedora's wanna-be QA's delay slots are severely adding to the
already existing problems.
> Really. Don't do that.
Really, your vision is impractical and non-applicable.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
> >What the maintainers could have done is not upload a package that breaks
> >binary compatibility into a distribution that's attempting to stabalise
> >for release.
>
> That's a way too simplistic view - It's simply that other processes
> (upstream release cycles, upstream release processes, package
> maintainer's time slots, etc.) are not in sync with Fedora's cycles
> and that Fedora's wanna-be QA's delay slots are severely adding to
> the already existing problems.
You're not obliged to upload the latest upstream. It's very practical to
simply not do so.
--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
>> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
>> >What the maintainers could have done is not upload a package that breaks
>> >binary compatibility into a distribution that's attempting to stabalise
>> >for release.
>>
>> That's a way too simplistic view - It's simply that other processes
>> (upstream release cycles, upstream release processes, package
>> maintainer's time slots, etc.) are not in sync with Fedora's cycles
>> and that Fedora's wanna-be QA's delay slots are severely adding to
>> the already existing problems.
>
> You're not obliged to upload the latest upstream. It's very practical to
> simply not do so.
So when _is_ a good time to do binary-incompatible changes to libraries?
* It's not after beta freeze, because they are unwanted at that time
* It's not 14 days before beta freeze, because they won't get out of
updates-testing in time
* It's not 14 days + 3 (4?) weeks before beta freeze - even if the
library gets out of updates-testing in time, its users may not be
rebuilt because the maintainer is on vacation.
* What if there are two layers of users that need to be rebuilt?
The delays just pile one upon another...
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2011-09-20 at 16:06 +0200, Nicolas Chauvet wrote:
> 2011/9/20 Nils Philippsen <nils@redhat.com>:
> > On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote:
> >> What's wrong with all that broken deps? Is this just a missing rebuild
> >> against opencv and other libs or what's the reason for all this
> >> "mess". I mean the release of F16 is not that far away and the amount
> >> of broken deps is quite big imho.
> >> I would be glad helping out if this is due to some orphaned packages.
> >
> > Some of these seem to be a case of "new library version was built and
> > pushed as an update without the rebuilds of dependent components". It
> > seems to be unclear who is responsible for the dependents to be rebuilt
> > and included in the same update as the library being updated. Currently
> > I only see mails of maintainers who plan updating the library, but the
> > rest of it pretty much depends on the maintainers of the depending
> > components rebuilding them quickly enough, and the original maintainer
> > to include them in the F-16 branched update.
> I'm the maintainer of opencv here.
>
> quick answear: I have no right to submit a bodhi update for packages I
> do not own. Given that I'm no in the provenpackager group.
> So as I cannot expect every single maintainers to respond in time, the
> consequence is that I depend on a provenpackager to do the whole task
> of "administrative rebuilt of dependent packages".
> Unfortunately it became a way more complicated task with the collapse
> of two bodhi tickets and others unexpected behaviour.
I wasn't picking on you, or anyone for what it's worth. It's just a
situation I've seen often enough so that I think it deserves some kind
of a solution, at least for the majority of cases where this shouldn't
be too much of a hassle.
With "responsible" I didn't mean that this person needs to do all of the
work either. Ordinary (non-proven-)packagers need to be part of the
picture.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2011/9/20 Miloslav Trmač <mitr@volny.cz>:
> On Tue, Sep 20, 2011 at 4:57 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> On Tue, Sep 20, 2011 at 04:52:28PM +0200, Ralf Corsepius wrote:
>>> On 09/20/2011 04:37 PM, Matthew Garrett wrote:
>>> >What the maintainers could have done is not upload a package that breaks
>>> >binary compatibility into a distribution that's attempting to stabalise
>>> >for release.
>>>
>>> That's a way too simplistic view - It's simply that other processes
>>> (upstream release cycles, upstream release processes, package
>>> maintainer's time slots, etc.) are not in sync with Fedora's cycles
>>> and that Fedora's wanna-be QA's delay slots are severely adding to
>>> the already existing problems.
>>
>> You're not obliged to upload the latest upstream. It's very practical to
>> simply not do so.
>
> So when _is_ a good time to do binary-incompatible changes to libraries?
>
> * It's not after beta freeze, because they are unwanted at that time
>
> * It's not 14 days before beta freeze, because they won't get out of
> updates-testing in time
>
> * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
> library gets out of updates-testing in time, its users may not be
> rebuilt because the maintainer is on vacation.
>
> * What if there are two layers of users that need to be rebuilt?
>
> The delays just pile one upon another...
You can update rawhide at any time and accomplish that work without
delays. Then it shows up in the next Fedora version.
josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> * It's not 14 days + 3 (4?) weeks before beta freeze - even if the
> library gets out of updates-testing in time, its users may not be
> rebuilt because the maintainer is on vacation.
You could have an earthquake, too.
If you're having problems rebuilding packages downstream from you, get a
provenpackager's help. I've done a few dozen such rebuilds for soname
changes over the course of F16 alone.
Of course, the accounts system _still_ doesn't have groups, five years
later, so provenpackager is the big hammer we have. We could get groups
any day now, that'd be just fine.
- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2011-09-20 at 16:07 +0200, Ralf Corsepius wrote:
> On 09/20/2011 03:47 PM, Bruno Wolff III wrote:
> > On Tue, Sep 20, 2011 at 15:01:06 +0200,
> > Nils Philippsen<nils@redhat.com> wrote:
> >>
> >> I'd like to see a discussion about how we can ensure -- within
> >> reasonable limits -- that e.g. bumping a library's SONAME is followed by
> >> dependent components being rebuilt and included with the providing
> >> component in one update.
> >
> > This should be easier to do now with the (relatively) new way to set up
> > build overrides.
>
> These are hardly applicable, if several maintainers are involved or if
> non-trivial technical difficulties arise.
Well, easy build overrides are helping getting the technical side done
without involving rel-eng. Several maintainers being involved and
non-trivial technical difficulties are exactly the topics that need to
be sorted out, but they don't have a thing to do with who sets up the
build overrides.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote:
> Of course, the accounts system _still_ doesn't have groups, five years
> later, so provenpackager is the big hammer we have. We could get groups
> any day now, that'd be just fine.
Do you mean "groups of groups", like in "provenpackager-kde",
"provenpackager-gnome", and "provenpackager" means all of these?
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
