www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <rdon...@apache.org>
Subject Re: snapshots policy...?
Date Wed, 14 Sep 2005 20:04:01 GMT
On Tue, 2005-09-13 at 19:55 -0700, Phil Steitz wrote:
> Steve Loughran wrote:
> > On 9/13/05, robert burrell donkin <rdonkin@apache.org> wrote:
> > 
> >>On Mon, 2005-09-12 at 22:59 -0700, Phil Steitz wrote:
> >>
> >>>robert burrell donkin wrote:
> >>>
> >>>>a user requested that a (dated) snapshot of a commons library be
> >>>>uploaded to ibiblio for use by mavenized projects. i've never done this
> >>>>before so i thought i'd give it a go.
> >>>
> >>>I would have objected on commons-dev if I knew the intention was to push
> >>>this out to ibiblio. IMHO, we should *not* be encouraging dependencies
> >>>on non-released jars, nor publishing them to mirrored sites.
> >>
> >>this is an argument which has been going on for a number of years now
> >>and i can see both sides. i used to dislike snapshots (and i still
> >>dislike undated SNAPSHOTs) but i can now see the difficulties for open
> >>source projects that needs features now which might take many months to
> >>appear in a full release.
> > 
> > 
> > Maybe, but does that mean that OSS projects should release stuff based
> > on nightly snapshots of other prokects.
> 
> This is a key point. By design, we (apache) have no control over what 
> users do with our software.  Publishing snapshots invites dependencies 
> on them.

it does invite dependencies but at least is gives us some measure of
control and influence over them. the arguments against releasing with
unreleased dependencies are strong and i think we'd have a good chance
of convincing others of this. 
 
> >>>The "internal use" repository at cvs.apache.org should just be used for
> >>>apache projects that need to use snapshots internally.  External users
> >>>should be encouraged to depend on released versions of commons
> >>>components.
> >>
> >>IMHO there is quite a difference between end users and the case of other
> >>open source projects under active development.
> > 
> > 
> > dependencies propagate.
> > 
> > I got burned last month by a project (muse) that released stuff based
> > on snapshots of other things. Because of that action, it is impossible
> > for me to rebuild their image, because even if their stuff is all
> > labelled in SVN, the libraries they used arent tagged.
> > 
> > Do you think the projects used as snapshots really want to field
> > requests from end users "a nightly build from three months ago is
> > broken", that came about because some other project released using
> > snapshots?

the key is that we don't want to encourage anyone creating releases
against snapshots whether from apache or elsewhere. we have this rule in
the commons and it has been proved a very good discipline.

> This is one of my concerns about commons. We have enough trouble 
> supporting the released stuff by itself. It is a pain to reconstruct 
> source for snapshots (even when tagged), in general there are no release 
> notes, bugs aren't tracked against them, etc.

IMHO this is has more to do with the quality of the execution of the
snapshots than the innate nature of snapshots. it would be good to have
some guidelines describing the limitations and problems with snapshots
together with how to execute in a way that minimizes them.
 
> > Nobody should be releasing apps based on snaphots. Interim snapshots,
> > maybe, but not official point releases. Maybe you can use snapshot
> > stuff in the build process, but even then I'm dubious, because it
> > raises the barrier to development. (I say that, even though I use
> > ant1.7alpha+maven-2.0 tasks snapshot for our sourceforge-hosted
> > project, but only on side bits and then I keep the tasks under our
> > SCM)
> > 
> > 
> >>it seems a little unreasonable (to me) to say that it's fine to upload
> >>for the internal use of apache projects but that it's not alright to
> >>upload jars for the use of other open source projects. 
> 
> I guess I have always seen cvs.apache.org as an "internal" repo in the 
> the following sense. What led to its getting set up, IIRC, was that both 
> the directory and geronimo projects (then both in the incubator) had a 
> large number of components that were being developed with some 
> dependencies among them. An internal repo to share snapshots among 
> apache projects seemed like a good idea and cvs.apache.org/repository 
> was created.  What is "fine" about this is that we (apache) have control 
> over what gets released and we can coordinate changes, etc.  This is how 
> some companies use internal maven repos.
> 
> Once we start pushing these snapshots up to "public" repos, we lose 
> control over when they "go away" and, more importantly, what may get 
> released depending on them.

it isn't unreasonable to ask people to add cvs.apache.org to their list
of repositories. 

but history has proved that if we were to strictly enforce the internal
only rule, then snapshots would find their way onto the public repos
without any apache influence. by providing an apache channel we may be
able to exercise some measure of influence.

> >>it also seems a
> >>little unreasonable to ask another open source project to wait until the
> >>next release (which may well be many months) for a some functionality
> >>they contributed back to the main library.
> 
> They can always step up to help us get a real release out :-)  That's 
> what other apache volunteers often do at commons :-)

release management is the time consuming part and that requires an
apache committer (though a pmc'er is preferred). at the moment, getting
a commons release out (even of code in a good state) probably takes a
month from start to finish. IMHO a lot of this is down to the higher
standards of current releases and this isn't something i'd be happy to
sacrifice...

> > Any project can use the cvs.apache.org repository; I do it in our
> > smartfrog project, the order being
> > 
> > -SCM repository
> > -ibiblio
> > -cvs.apache.org
> > 
> > Just keeping it separate makes it clear things are less stable.
> 
> Another key point, which to me seems a reasonable compromise.

+1
 
> >>IMHO all that this encourages is the proliferation of unofficial forked
> >>versions cut by people outside apache.
> > 
> >  
> > 
> >>IIRC one of the major reasons why apache wanted to move the master
> >>repository back onto apache hardware (from ibiblio) is that we wanted to
> >>regain control over releases. i'm not sure that strictly enforcing the
> >>rule about internal use only would further this policy.
> > 
> > 
> > I'm against internal use only too. But think we need to emphasise that
> > no projects should release stuff using the internals if they can help
> > it. I also think that no apache projects shoudl release stuff that
> > depends on snapshots, which is now the effective policy of the WS PMC
> > (after my muse experience).
> >  
> I agree with the statement about not releasing our own software with 
> snapshot dependencies.  I guess at the end of the day, I would not go so 
> far as shutting off access to cvs.apache.org/repository from outside 
> apache (partly because that would create problems for volunteers), but I 
> think we need to maintain the distinction and warn users that the snaps 
> *will* go away.

IMHO the crucial point is that the cvs.apache.org repository should not
not an internal repository but a temporary one for unstable code. use of
binaries to allow continued development (until the next release) is
reasonable but no other project should rely on it for releases since it
will be removed when the next full release is cut. this would mean that
there would still be pressure to create frequent releases but that it
wouldn't stop ongoing development of code elsewhere. 

does this sound like a reasonable policy?

> We should talk about commons in particular on commons-dev.  I agree that 
> we need to get releases out quicker and I am as much to blame for 
> current state as anyone else.  

your part in pushing the standards of releases higher in the commons is
nothing to be ashamed about.   

IMHO maturity plus fear of loss of reputation implies infrequent
releases. the quality of commons releases is now pretty good and
maintaining that quality takes time and effort. i'm very glad that you
(and others) invest the time required to produce high quality releases.
i'd rather have fewer better releases than a lot of poor ones.

> Maybe moving to the struts - tomcat - 
> httpd release strategy could help us release with greater frequency. 
> The mechanics are getting easier, but we can probably improve that as well.

 i'm a big fan of that release system but IMHO it wouldn't work well for
the commons. 

- robert

Mime
View raw message