[sakai2-tcc] 2.9.1-all tag available

Sat Feb 16 05:22:18 PST 2013

On 16/02/2013, at 11:24 AM, Matthew Jones <matthew at longsight.com> wrote:

> On Jenkins you can have tools build the dependent projects, but you can't set that up at all to release, or have it work with the Jenkins release plugin in any way that I've seen.
> 

Yeah I'm not saying that process should be used for the release, just for continuous builds so that they can be isolated to build just the projects that they need.

> You really think that someone should be using the 2.9.1-all tag or any tag's there-in? Which group of users? 

The 2.9.1-all tag just aggregates all of the tagged versions of source that are part of 2.9.1, and includes the source for indies, so yeah, lots of people will use it. Note that the 2.9.1-tag is nothing special, its mainly the 2.9.1 release. There was a fair bit of interest on the other thread too. 

> Developers should ideally be developing on trunk so they can get their patches back in. If their school is on 2.9 they should be testing them on 2.9.x so they can get them into the next version of 2.9. It doesn't do the community any good to have them working on 2.9.1. 

Sure, but I would argue that most people classed as developers are actually local implementors, maybe customising the software for their local needs. As a previous local implementor you'd appreciate that its often difficult to balance the need for local immediate fixes with getting them back into the community. Or often they are just fixes that people want to merge in.

I would bet a lot of beer that a lot of people download the tags and base their installations on them. In last year's community poll, 41 of 99 respondents did just that. And a further 26 build via a custom local build or SCA build. Plus we have quite a few using msub that take copies of official tags and go from there. And others not using msub - I can name a dozen installs that don't use msub but use the official tags as a base for their installs.

> Deployers should just be using the binary .tar.gz as-is and not modifying it. If they do need to modify it modify it, they'll need to set a custom version anyway, and they'll probably want it off the .x branch so they can more easily pull in the latest updates when we merge fixes. Otherwise they'll be doing a lot more of their own branch management.

 IMO we should get rid of the source and binary downloads (as I did for 2.8.3) and just keep the demo for people to evaluate, for the latest versions only. If they want to do anything else, get the source. Simplifies everyones lives.

> 
> Perhaps it has some value to some SCA like rSmart or iRubric that wants to take this static version, apply just *their* patches and release it as-is (or reversion everything and release it like rSmart does with their crazy 2.8.9 version or whatever they're on)

Or any institution that wants to use an official version and merge in a few cosmetic fixes here and there, but know that the underlying code is tested and stable.

> 
> Anyway, what I would do for (say the 2.9.2 or at least the RC's which I didn't do for the 2.9.1 rc's) is make the externals and put in the revision flags.
> For instance . . .
> kernel		-r118058	https://source.sakaiproject.org/svn/kernel/branches/kernel-1.3.x
> . . . etc

Thats the same as making a tag. Except more volatile since the branch will no doubt declare snapshot dependencies, so -1 for that as its less stable.

> 
> I believe that the way we (you?) set up the parents with the relativePath, it means it will check for local modifications before going out to look for newer stuff in the repository. If not I'll just locally change the versions of everything using the versions plugin or an xslt. Something to think about anyway. . . This should give everyone what they want, as long as nobody is actually using assemblies. ;) (I don't know if we ask that question)

Clearly there is still a major issue with the release process for 2.9 and how things are structured. The 2.8.3 release was remarkably straightforward and issue free. Perhaps we are relying on Jenkins to do too much. The release process should be easy - follow a checklist and be done with it. If its not that way then we need to remove the crap thats in the way and get back to basics. At this point in time I'd be +100 for removing all indies and just distributing a full source checkout. Then it can be tagged in one hit and you have a release. Done. 
Project teams can still release off cycle via tags and deployers can upgrade to that tag if they choose. At least then we could get releases out more often.

> 
> 
> On Fri, Feb 15, 2013 at 4:49 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> The built Apis for all tools are already released to the repository as part of the release process. So that takes care of the first and third point. 
> 
> The other one is Jenkins but that probably not as huge an issue as you think, as you can have tools built their dependent projects, so yeah it will build extra but not all. 
> 
> I am starting to see less value in the indies as well, especially now that tool development  has slowed right down. I don't think we should do anything to remove the indie nature( ie their assembly etc) just yet, but moving back to full source checkouts is probably what we need to do in the short term.
> 
> I disagree that the all tag isn't useful, a lot of people want to use it. And they probably base custom builds from it, so it's more of a convenience than anything. 
> 
> I do take copies of tags into msub and modify them with the same version number so that I don't have to adjust other projects, and there is nothing wrong with that. 
> 
> Cheers
> Steve
> 
> Gesendent von meinem iPhone
> 
> On 16/02/2013, at 5:21, Matthew Jones <matthew at longsight.com> wrote:
> 
>> Thanks for bringing this up Chuck,
>> 
>> After releasing 2.9 11 times since b03, I've been increasingly unhappy with it. Though I'm not sure if serious disruptions are better for a minor release (2.9.2) or waiting until the next big one (2.10, or possibly 3.0 [or 4.0 if we say 3.0 was an unfinished experiment]) It's not super difficult anymore, but there's a lot that can go wrong, and the things that can go wrong may not be obvious for weeks or months later, causing a lot of lost developer time, something we have limited amounts of. I believe that the bundling up the released indies into this release adds no value to developers, deployers, basically anybody. I can't see any audience that really gains from this knowing what they're getting besides maybe upper management who think that static compiling from tagged releases on static numbers provide some kind of assurance over failures? Anytime you compile something with maven the artifacts will be new, different and unpredictable. 
>> 
>> The static numbered tags are meant to not be changed, yet people will download this 2.9.1-all, add local patches and re-compile and use their own versions. (Often without changing the versions) This is what the SNAPSHOT is for, active development and modification. The maven versions plugin helps with a lot of this as well with the versions:lock-snapshots and other pseudo-release goals.
>> 
>> Here's the value I see out of the *indies*
>> - The API's from all of the indies are useful to have released in the repository. 
>>   - Released API's mean that Jenkins can build an indie as soon as it's modified and notify individual committers as soon as something breaks. Otherwise it would have to build everything (which can take up to an hour) and not often know what change broke the build. 
>>   - Released API's also mean that contrib projects that use Sakai services can build without having to build the entire core. You can just download the contrib projects and mvn install sakai:deploy. This is pretty great. 
>> 
>> - There is little value from the assemblies and core-deploy
>>   - You can't use a new assembly in an older version (For example a 2.9 assembly in 2.8). This was tried recently with Sitestats and because FormattedText changed in kernel-util in 2.9 it failed when deployed into a 2.8 instance. So you'd have to recompile a new sitestats for 2.8 and for 2.9 if you want the newer sitestats, not just use the deploy (Or just provide a sitestats bound against an old version of Sakai, which might also work)
>>   - To actually use core-deploy and deploy something you need maven and often java anyway, so you don't save anything other than downloading the source. Often the source can be smaller than the binary anyway, not really saving much on bandwidth costs
>>   - This increases the time for the buildled these are bundled up, even if they're really not even used.
>> 
>> So here's what I think could happen or 2.9.2, but it would require some work.
>> 
>> - Figure out a way to just release all of the API's. Either as a profile hack in maven or as a file system hack with symlinks. (Haven't figured this out yet)
>>   - This isn't even a huge deal if API's don't change after 2.9.1, since all of the 2.9.1 one's are already released.
>> - Get rid of core-deploy (is not in the -all build anyway) and also get rid of the assemblies (because they're not needed)
>> - Don't release anything independent, release everything together as a monolithic release (Skip the release plugin)
>>   - To do this properly, master (which references api dependencies) would need to point to the 2.9.1 versions of the apis, and all of the indies would have to have their versions updated to *something*. Perhaps the versions plugin could lock down these versions. What it's called doesn't seem relevant as this version is mostly for QA purposes anyway and we can just map it internally (for instance it would probably be something like 2.9-20131117.213112-16). Maybe the maven versions plugin could still be used to update and not commit as well.
>> 
>> This is all what people seem to want anyway?
>> 
>> 
>> 
>> On Fri, Feb 15, 2013 at 8:28 AM, Charles Severance <csev at umich.edu> wrote:
>> Thanks from all of us :)
>> 
>> Hey (this is to everyone) - is there *any* reason not to make the 2.9.2 tag - just the "all" variant and then also make a "2.9.2-partia" if folks really want a subset of the code when they check out?
>> 
>> We might as well gently trend in that direction IMHO.
>> 
>> Just thinking out loud - feel free to disagree.
>> 
>> /Chuck
>> 
>> On Feb 15, 2013, at 8:24 AM, Steve Swinsburg wrote:
>> 
>> > Hi all,
>> >
>> > As discussed, I've created a 2.9.1-all tag:
>> > https://source.sakaiproject.org/svn/sakai/tags/sakai-2.9.1-all/
>> >
>> > Work tracked here for future reference:
>> > https://jira.sakaiproject.org/browse/SAK-23234
>> >
>> > I'll ping the dev list in a sec to respond to the other thread.
>> >
>> > cheers,
>> > Steve
>> >
>> > _______________________________________________
>> > sakai2-tcc mailing list
>> > sakai2-tcc at collab.sakaiproject.org
>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130217/16619ef3/attachment.html 