FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-18-2012, 04:22 PM
Nathan Zachary
 
Default glibc-2.16 moving to ~arch

On Sat, 18 Aug 2012 12:00:17 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> *yawn* such a drama queen.
>
> i never said "i am going to do this everyone else be damned". i did
> say "i will probably do this soon". but that is why i posted to
> gentoo-dev in the first place -- to get feedback from others.
>
> gnutls breakage: not relevant. you're causing that breakage by not
> adding a simple patch that most every other package has merged.
> conflating the issue to a major ABI bump is also irrelevant.
>
> boost breakage: if 1.50 is going to be unmasked soon, i can wait for
> that.
>
> general breakage: we can't sit around waiting for all packages to get
> fixed. if people aren't going to fix packages after being given
> notice, then they get tree cleaned. not a big deal.
> -mike

You both (Mike and Diego) make good and valid points regarding the
unmasking of glibc-2.16 and its impact on other packages (and,
subsequently, users). However, the personal attacks against one another
add nothing to the discussion. Resorting to ad hominem relegates the
discourse to a less-than-helpful state for everyone involved. Please
try to focus on the points raised by other developers and users, so
that the end result is something that benefits the community and
distribution as a whole.

Cheers,
Nathan Zachary
 
Old 08-19-2012, 08:41 AM
Luca Barbato
 
Default glibc-2.16 moving to ~arch

On 8/18/12 5:31 AM, Mike Frysinger wrote:

i'll probably land it later this weekend/monday.


Would be nice having a list of bugs open so people might have a look and
see if there is something big left.


boost and gnutls seem big enough already to spend some time to get those
fixed before unleashing the beast.


lu
 
Old 08-20-2012, 03:07 AM
Mike Frysinger
 
Default glibc-2.16 moving to ~arch

On Sunday 19 August 2012 04:41:17 Luca Barbato wrote:
> On 8/18/12 5:31 AM, Mike Frysinger wrote:
> > i'll probably land it later this weekend/monday.
>
> Would be nice having a list of bugs open so people might have a look and
> see if there is something big left.

we've been making trackers for the glibc upgrades:
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16

> boost and gnutls seem big enough already to spend some time to get those
> fixed before unleashing the beast.

gnutls is not valid and i will not wait for it. boost i'll give the
maintainer time to resolve as the patch to boost-1.49 can be made to work, but
it's not that great, and there are already plans on moving boost-1.50 to
unstable which is all i need.
-mike
 
Old 08-20-2012, 03:13 AM
Diego Elio Pettenò
 
Default glibc-2.16 moving to ~arch

On 19/08/2012 20:07, Mike Frysinger wrote:
> gnutls is not valid and i will not wait for it. boost i'll give the
> maintainer time to resolve as the patch to boost-1.49 can be made to work, but
> it's not that great, and there are already plans on moving boost-1.50 to
> unstable which is all i need.

The same applies to GnuTLS 3, you know Â*— would be nice if you fixed the
games, and the other packages you maintain, that break with it.

For reference these are the other two trackers:

http://bugs.gentoo.org/alias/gnutls-3
http://bugs.gentoo.org/alias/boost-1.50

FWIW GnuTLS 3.1 is perfectly fine to go into ~arch IMHO as I've been
using it for a while and most of the bugs are only present on gnutls USE
flag turned on (and not for all SSL support).

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-20-2012, 11:09 AM
Rich Freeman
 
Default glibc-2.16 moving to ~arch

On Sun, Aug 19, 2012 at 11:07 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sunday 19 August 2012 04:41:17 Luca Barbato wrote:
>> On 8/18/12 5:31 AM, Mike Frysinger wrote:
>> > i'll probably land it later this weekend/monday.
>>
>> Would be nice having a list of bugs open so people might have a look and
>> see if there is something big left.
>
> we've been making trackers for the glibc upgrades:
> https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16

While trackers are of course the right way to handle this, it is
generally best to announce timelines more than two days in advance.

You're certainly not the only case of this problem - I've noticed a
tendency to post a tracker for some issue, watch nothing happen for
six months, and then see an announcement that the change is being
pushed through in a few days.

Changes with a big impact should be announced on the lists well before
they are made.

Also, while users running unstable systems are naturally going to be
at risk for unforeseen issues, this isn't an unforeseen issue. When
we know a problem exists, we generally should fix it before we commit
it. If some uncommon package breaks I think we can live with that,
but gnutls doesn't fall into that category.

I'm not really interested in the blame game either. This isn't your
problem, or the gnutls maintainer's problem - this is Gentoo's
problem, and I hope we don't make it our user's problem for failure to
work together.

Rich
 
Old 08-20-2012, 02:14 PM
Alec Warner
 
Default glibc-2.16 moving to ~arch

On Mon, Aug 20, 2012 at 1:09 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Sun, Aug 19, 2012 at 11:07 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Sunday 19 August 2012 04:41:17 Luca Barbato wrote:
>>> On 8/18/12 5:31 AM, Mike Frysinger wrote:
>>> > i'll probably land it later this weekend/monday.
>>>
>>> Would be nice having a list of bugs open so people might have a look and
>>> see if there is something big left.
>>
>> we've been making trackers for the glibc upgrades:
>> https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.16
>
> While trackers are of course the right way to handle this, it is
> generally best to announce timelines more than two days in advance.
>
> You're certainly not the only case of this problem - I've noticed a
> tendency to post a tracker for some issue, watch nothing happen for
> six months, and then see an announcement that the change is being
> pushed through in a few days.
>
> Changes with a big impact should be announced on the lists well before
> they are made.
>
> Also, while users running unstable systems are naturally going to be
> at risk for unforeseen issues, this isn't an unforeseen issue. When
> we know a problem exists, we generally should fix it before we commit
> it. If some uncommon package breaks I think we can live with that,
> but gnutls doesn't fall into that category.
>
> I'm not really interested in the blame game either. This isn't your
> problem, or the gnutls maintainer's problem - this is Gentoo's
> problem, and I hope we don't make it our user's problem for failure to
> work together.

I think part of Mike's point is that time and time again has proven
that the way to a mans heart^H^H^H^H to get things fixed is to break
them. The aforementioned example of a tracker open for months with no
progress is an example of halted progress. If we waited to fix all
known issues prior to launch, then we would never launch. This is very
common in software development. Some features are v2 features, some
bugs are not worth fixing. Some bugs we will fix with a patch
post-launch; I don't see how this is any different.

-A

>
> Rich
>
 
Old 08-20-2012, 02:27 PM
Rich Freeman
 
Default glibc-2.16 moving to ~arch

On Mon, Aug 20, 2012 at 10:14 AM, Alec Warner <antarus@gentoo.org> wrote:
>
> I think part of Mike's point is that time and time again has proven
> that the way to a mans heart^H^H^H^H to get things fixed is to break
> them. The aforementioned example of a tracker open for months with no
> progress is an example of halted progress. If we waited to fix all
> known issues prior to launch, then we would never launch. This is very
> common in software development. Some features are v2 features, some
> bugs are not worth fixing. Some bugs we will fix with a patch
> post-launch; I don't see how this is any different.
>

I agree with your point. I'm fine with setting deadlines and such,
but my main concern is that the first deadline shouldn't be two days
after it is announced.

If the announcement were that we have a tracker and some languishing
bugs, and we'd like to push to get them closed in two weeks I'd feel
differently.

Rich
 
Old 08-20-2012, 02:43 PM
Alec Warner
 
Default glibc-2.16 moving to ~arch

On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Mon, Aug 20, 2012 at 10:14 AM, Alec Warner <antarus@gentoo.org> wrote:
>>
>> I think part of Mike's point is that time and time again has proven
>> that the way to a mans heart^H^H^H^H to get things fixed is to break
>> them. The aforementioned example of a tracker open for months with no
>> progress is an example of halted progress. If we waited to fix all
>> known issues prior to launch, then we would never launch. This is very
>> common in software development. Some features are v2 features, some
>> bugs are not worth fixing. Some bugs we will fix with a patch
>> post-launch; I don't see how this is any different.
>>
>
> I agree with your point. I'm fine with setting deadlines and such,
> but my main concern is that the first deadline shouldn't be two days
> after it is announced.

The tracker has been open since July 4th.

>
> If the announcement were that we have a tracker and some languishing
> bugs, and we'd like to push to get them closed in two weeks I'd feel
> differently.

I can't really say Mike is the shining example of how we should
communicate; but then again, neither am I

-A

>
> Rich
>
 
Old 08-20-2012, 02:54 PM
Rich Freeman
 
Default glibc-2.16 moving to ~arch

On Mon, Aug 20, 2012 at 10:43 AM, Alec Warner <antarus@gentoo.org> wrote:
> On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> I agree with your point. I'm fine with setting deadlines and such,
>> but my main concern is that the first deadline shouldn't be two days
>> after it is announced.
>
> The tracker has been open since July 4th.
>

Yes, and it does not contain any deadlines at all (not even the one
announced on the mailing list).

There are bugs that have been open for years. If suddenly making some
change breaks end-user systems the fact that a bug has been open for
years isn't really justification.

The first mention of "you must do this by this date" was on Friday,
with the deadline being today.

I'm fine with trying to push things through within reason (otherwise
nothing gets done). However, the key part is "within reason." If
that bug had a deadline announced two weeks ago I'd be less concerned.

Rich
 
Old 08-20-2012, 07:30 PM
Mike Frysinger
 
Default glibc-2.16 moving to ~arch

On Monday 20 August 2012 10:54:03 Rich Freeman wrote:
> On Mon, Aug 20, 2012 at 10:43 AM, Alec Warner <antarus@gentoo.org> wrote:
> > On Mon, Aug 20, 2012 at 4:27 PM, Rich Freeman <rich0@gentoo.org> wrote:
> >> I agree with your point. I'm fine with setting deadlines and such,
> >> but my main concern is that the first deadline shouldn't be two days
> >> after it is announced.
> >
> > The tracker has been open since July 4th.
>
> Yes, and it does not contain any deadlines at all (not even the one
> announced on the mailing list).

glibc is on a known release period (~every 6 months). i posted some time ago
that Gentoo will be rolling along as well:
- have a version in the stable pipeline
- have a version in the unstable pipeline
- have a version in the masked pipeline
as versions in the lower pipeline clear out, the next one will be moving into
place. so while exact times haven't been posted (because i don't have them),
glibc versions will continue to be released, so maintainers can't sit on their
bugs. 2.15 has gone stable which means there's now room for 2.16 which has
largely settled down.
-mike
 

Thread Tools




All times are GMT. The time now is 03:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org