[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] 2.0 releases going into mirage-dev



On 3 Nov 2014, at 18:28, Amir Chaudhry <amc79@xxxxxxxxx> wrote:
> 
> 
> On 3 Nov 2014, at 15:15, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
>> I've started tagging all the libraries currently in mirage-dev and have 
>> uploaded releases of most of them to https://github.com/mirage/mirage-dev. 
> 
> Hooray!
> 
>> Next steps:
>> - add constraints on packages that would conflict (mostly cohttp) in the 
>> main opam repo
>> 
>> - figure out why this ocaml-dns downgrade happens only on 4.02: 
>> https://travis-ci.org/mirage/ocaml-dns/jobs/39791629#L265
>> 
>> Interesting question is what we do with mirage-dev now.  Should we instruct 
>> people to remove it?  It's actually more useful it seems to have remotes for 
>> a specific purpose (mirage/mirage-2-release) so that once they're done, they 
>> just contain archives.
>> 
>> If we bump mirage/mirage-dev to the git versions again, then users will 
>> always get the bleeding edge…
> 
> 
> I admit I don't fully understand what you're asking but I'll pretend that I 
> do. :)
> 
> I'd instruct people to remove mirage-dev unless they're happy to be on the 
> bleeding edge (I'd be one of those that removes it).
> 
> I think we need to maintain clearer separation between mainstream releases in 
> the default opam repo (which should happen frequently) and making bleeding 
> edge versions available to devs in a convenient way (which may occasionally 
> be broken).  Anything in between gets complicated to understand.
> 
> My reasoning is that we should avoid having instructions that tell largely 
> new users to add opam remotes, which also encourages us to make sure we're 
> releasing often in the main opam repo. It's too easy to add lots of things 
> into our own remote(s) thus forcing newcomers to join us on the cutting edge 
> (and suffering the concomitant blood loss).
> 
> I'm not sure what the right way forward is, especially given the pace of 
> development and number of libs, but I hope you can see what I'm trying to get 
> at -- also, let me know if I misunderstood the question.

I'm inclined to agree with you -- only those interested in the git branches 
should have to add mirage/mirage-dev.

-anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.