X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20150915140853.16535.qmail@stuge.se>
Date: Tue, 15 Sep 2015 16:08:53 +0200
From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: "Peter Stuge \(peter AT stuge DOT se\) \[via geda-user AT delorie DOT com\]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] Happy birthday
Mail-Followup-To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
References: <55F7EE7F DOT 101 AT unige DOT ch> <20150915115059 DOT 5939 DOT qmail AT stuge DOT se> <55F81EDD DOT 70603 AT jump-ing DOT de> <55F7EE7F DOT 101 AT unige DOT ch> <20150915115059 DOT 5939 DOT qmail AT stuge DOT se> <alpine DOT DEB DOT 2 DOT 00 DOT 1509151410560 DOT 6924 AT igor2priv>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55F81EDD.70603@jump-ing.de> <alpine.DEB.2.00.1509151410560.6924@igor2priv>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

gedau AT igor2 DOT repo DOT hu wrote:
> how do I know it's not some WIP/experimental stuff at the moment I pull?

Distributions can add value by staying informed about what happens
upstream, by being involved upstream, so that their users don't have to.

That's my philosophy for open source. I also think it's why almost
all distributions don't provide what I want - so I just make my own.


> Or is it guaranteed (more or less) that a specific branch is always
> stable after each push/merge/whatever?

No, as a consumer you can't afford to make any such assumptions. The
irony is that you also can't make such assumptions about releases,
because they typically aren't prepared all that much more carefully
than the current master.


> Should the distribution's package manager upload 15 new packages a 
> day if the upstream VCS changed 15 times that day?

I think that depends mostly on how flexible the distribution's
infrastructure for packaging is. Sometimes that would be fine.
Other times once a day or once a week or once a month would be
better.


> Releases can solve this: when upstream rolls a new release, at least
> the developers/maintainers of the upstream think that version of the
> stuff is stable.

No they don't. There's no big difference between a release and master.

> This is a signal from upstream to users and distributions.

But users and distributions are responsible for not trusting it,
because there can always be regressions. Open source only works if
you accept the responsibility to always solve your own problems, but
then it can work super awesomely!


Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
> > Is there a place where developers announce that a specific VCS version
> > is stable
> 
> They can't, because if developers aware of a regression they simply
> don't commit to master. Accordingly, master is always the most "stable"
> release available.

Unfortunately "stable" is very subjective, and even then, there isn't
always agreement that master is supposed to always be stable.

I could tell a long tale about an open source project that was hijacked
by persons who did not value such stability, but instead valued high
frequency of commits, with less regard for commit contents, but I
don't want to go into that here.

The point is that consumers should take more responsibility and know
what they consume, and that distributions can add huge value here,
but ever since my experience in that project it is absolutely clear
to me that most if not all distributions are first and foremost
populist and involvement with and knowledge about upstream is quite
far down the list. Even the large distributions are more than happy
to apply a "we'll do whatever most others do" reasoning, seemingly
unaware that their actions make them responsible for those who might
follow.

It's all very dysfunctional.


//Peter