Well, it's really sad that you like to dredge up year old context for this
thread to suit your mundane arguments, they have little context with what
I was saying.
> > > > resources on woody right now.
> > >
> > > speak for yourself. not everyone in debian has your priorities. more to
> > > the point, your priorities are not the only valid ones.
> > >
> > > many people can (and ARE!) contribute a lot to woody, without impacting
> > > on frozen in the slightest.
> >
> > Direct impact yes, indirectly though, we are short on needed resources for
> > getting potato release ready.
>
> you miss two important points. the first is that the release is not
> everyone's highest priority. the second is that some people have nothing
> to contribute to frozen/stable, so discouraging (or preventing) them
> from working on unstable is counterproductive.
Once can argue that the reason is because they don't know how they can
help. Everyone within Debian has a stake in frozen, simply by being a
member, and every can help. There is nothing preventing that.
> both of these points are proved by the fact that we have over 500
> developers yet, according to your own words, "we are short on needed
> resources for getting potato release ready". if everyone, or the
> majority...or even a substantial minority, had your priorities then that
> would not be the case.
First of all, you need to check your numbers. Last I checked there were
~350 official developers in the keyring. Right, so this proves my point in
that we should encourage developers to put a priority on frozen and the
next release cycle. And please stop refering to stable. That is not my
main concern here, and I never brought it into this conversation.
> in any case, simply adding more people to the project won't make it
> happen any faster. what WILL make it faster is to fork off the stable
> release as a sub-project of debian, and give the release team absolute
> authority over the release, with the right to make NMUs of any package
> and make any other changes for any reason they see fit. as with any
> other debian initiative, any developer (or user) would be free to work
> on it or not as they please.
How would that help? That is simply a superficial thing. Calling it a
"seperate project" would do nothing to improve the situation. Plus that
creates havoc with changes made to the frozen release that aren't in
unstable. So we get split bug reports and a lot of other crazy things.
> also, the issue is not "man-power", the issue is "man-hours" - i.e.
> how much time any of the people doing the important jobs can devote to
> debian. most of them have full-time jobs or are full-time students and
> are working on debian in their spare time. the really imporant tasks
> can't be sped up by some kind of time-sharing arrangement.
Ok, let's play word games. "Man-hours" is a direct result of "man-power".
Everyone in Debian only has but so many hours than can put into the
project, so increasing each developers time in the project is not an
option. So we encourage developers to spend their time that they have to
projects for the next stable release.
> > > then "fork" the stable release so that those who want to focus on it
> > > exclusively can do so without being distracted by those attracted by
> > > the shiny new toys...and those who want to work on new stuff don't
> > > have to be distracted by the test & freezing cycle. and some people
> > > will happily work on both.
> >
> > Sorry that getting the next stable release out the door is such a
> > distraction. I'll try to see if there is some way we can keep this
> > messy part of Debian out of your way.
>
> it doesn't distract me at all. i mostly ignore it these days as it is of
> little or no relevance to me.
Safe to say, that is a really self-centered attitude. One which I hope
that most developers don't have. Not a very team oriented situation if
everyone felt that way.
> like many others, i am perfectly happy with the real debian (i.e. the
> "live" development version aka "unstable") as it has served my needs
> extremely well on production servers and workstations for 5+ years.
> in other words, empirical evidence over the years has shown that the
> distinction between stable and unstable is not only irrelevant, it is an
> arbitrary falsehood.
>
> this same empirical evidence has also proved that 'stable' is LESS
> stable and reliable and secure than 'unstable'. the few debian boxes
> which i know of that have been compromised were cracked BECAUSE they
> were still running stable and had older versions of various programs
> which had known security holes. the main reason they were still running
> stable is because they didn't have fast, reliable internet connections -
> i.e. if regular snapshot CDs were available, they would have been up to
> date.
>
> i would like to see the real debian become more accessible to the
> general public, and the way to do that is to make frequent snapshot CD
> images.
Another sad situation. Sad because you feel that it is better to forget
the harder situations, and simply deal with the ease of unstable. I'm glad
you find it so easy to shove off the important work and leave your self in
the midst of easier things like uploading to unstable whenever a new
version of your package comes out. Everyone knows how hard it is to help
with RC bugs and documentation, or test installs and file bugs. Who would
want to do all that crap when you can stick with unstable where no one
bothers you and your packages?
> > I don't recall saying anything about forcing. Maybe you mistook
> > "encourage" for "force".
>
> no, i didn't. i simply put your current remarks in context with other
> statements of yours in the past, where you have been an advocate of the
> insane idea that unstable should be closed down between the freeze and
> the release.
I never said that we should force people to work on unstable. My exact
proposal was to not fork unstable at freeze, and instead wait till deep
freeze (not release as you suggest). No one has to work during this time,
they can do nothing if they don't want to help with frozen. So in a way,
it is more like "if you want to work, frozen is the place to do it". With
our current frozen cycle that means you either upload bug fixes (even
minor ones, and a lot of times, new versions justify as a bug fix), or you
don't do anything. The only thing you can't do is upload "new" packages.
Very sad that you wont be able to add another ICQ client to the +4000
packages in the distribution already. Sorry for suggesting that.
>
>
> > Not my issue though, I still think we need to encourage people to work
> > on frozen until it's completely out the door.
>
> fine, keep on with the "encouragements". just keep the "should"s and
> "should not"s in check. they are shrill and irritating.
What? Let's see...People SHOULD work on frozen, people SHOULD work on
getting RC bugs fixed, people SHOULD work on documentation, people SHOULD
test installs...if it is at all possible. Was that shrill and irritating
enough?
> > Package pools are not an end all and frequent snapshots and less
> > frequent stable releases are only doable when we have people working
> > on it.
>
> one person can do a snapshot release in a day or so - that's the
> point...it's an untested snapshot of unstable as it is at that moment in
> time. use at your own risk, just like unstable....and just like 'stable'
> - we don't after all, offer any guarantee for stable.
>
> there's no need to even make new base/install disks for a snapshot
> release - the old ones from the previous stable release will be
> adequate...just install those and then upgrade to the snapshot.
>
> the stable releases will, of course, still take time to test and to
> produce new boot-floppies. however, that time will be reduced because
> some of the testing will already have been done by people using the
> snapshots.
Heh, that's a pretty idealistic view. I think you misunderstand the usage
of package pools. They are meant to give better seperation than out
current "stable", "frozen", "unstable" distribution and allow for tagged
package sets. They are not for "snapshots" like a CVS repository, which
would do nothing to increase stability.
Using snapshots of unstable is no different than using unstable itself,
which is what we have now. Just the usage will be dated.
> > Since you think that encouraging people to work on it is not ok,
>
> do NOT put words in my mouth.
>
> > Any way, package pools wont come till after potato, since it is (and
> > should be) still the first priority right now.
>
> for you and some others, it is the first priority. for other people,
> including myself, it is a vaguely interesting but still irrelevant
> activity performed by those members of the debian project who care
> enough about it to work on it.
Actually, I care about putting out a stable release. You seem to worry
more about your own interests as opposed to the projects'. Please let me
say again, I am really glad that this is not the general attitude from
Debian developers. My concerns, and the concerns of anyone who decides to
put time into Debian, should be the ones stated in our Social Contract:
4. Our Priorities are Our Users and Free Software
We will be guided by the needs of our users and the free-software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environment. We won't object to commercial software
that is intended to run on Debian systems, and we'll allow others to
create value-added distributions containing both Debian and commercial
software, without any fee from us. To support these goals, we will
provide an integrated system of high-quality, 100% free software, with
no legal restrictions that would prevent these kinds of use.
Didn't you have to agree to this to become a developer in the first place?
IMO, getting out a stable distribution meets these goals. Ignoring frozen
does not.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
