pkgsrc-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc/www/firefox
> > - no definition of "important packages like this"
>
> if you disagree that firefox is an important package, then I don't
> know what I can do to find common ground.
Common ground? Such expectation won't work.
Firefox, probably yes.
But what about emacs, qemu, thunderbird, git?
How can developers know his individual packages are important or not
in pkgsrc-pmc views?
> > - firefox adopts the fast release cycle and the release date had been
> > scheduled so sometimes it couldn't happen before freeze
>
> indeed, and it's good to get things like that in. But maybe we shouldn't
> put all of our eggs in one basket - do we have room for a firefox and a
> firefox-stable package? or a firefox-newest, or firefox-devel?
Then you should require approvals for all packages.
> > - firefox 24 includes many security fixes
>
> which is good, yes
Some developers say security fixes are enough reason to update.
Why not for firefox?
> > - no security fixes will be provided for the older versions and
> > most users want a new and fixed version rather than
> > obsolete one with known security problems
>
> what's firefox's expectations from their userbase about updating?
Probably firefox guys have better answers.
> > - ryoon@ is almost the only active developer working on www/firefox
>
> Yes, which is why, when you said above about discouraging people, I
> got worried. I certainly hope I haven't really done that?
Unfortunately there are at least two other developers
who said your message was sounding discouraging.
> > > I see the leaf/non-leaf part is guidance, not a hard
> > > and fast rule.
> >
> > Then you should provide written rules.
> > (probably pkgsrc also needs package Tier-ing like NetBSD ports)
>
> I know the joyent people have up to date information about downloaded
> binary packages, and we should be able to get the same from Minix3 too.
> The pkgsurvey results are around for anyone to analyse if they want, too.
>
> But I believe that anything beyond that is a matter for personal taste,
> use case, work requirements, developer history, even matters of previous
> dealings with authors, etc.
Just define 'which leaf packages you want approval in advance.'
Without it your claim won't make sense.
---
Izumi Tsutsui
Home |
Main Index |
Thread Index |
Old Index